Taking Code Climate Enterprise from a Docker Image to a Modern Software Product

Grant Miller
 | 
Apr 27, 2018

This is a guest post by Noah Davis, co-founder of Code Climate. Used by over 100,000 projects, and analyzing over 2 billion lines of code daily, Code Climate incorporates fully-configurable test coverage and maintainability data throughout the development workflow, making quality improvement explicit, continous, and ubiquitous.

Code Climate was founded in 2011 as a hosted service with the goal of improving code quality for all engineering teams, so that developers can ship better code, faster. By the spring of 2014, we started to see more demand for an on-premises offering to support customers hosting their own source-code management systems. Thus, Code Climate Enterprise was born.

Our challenge: Nailing deployment while going on-prem

Typically, installation is the first experience our customers have with our product, and it defines their expectations going forward. If application deployment is difficult, it’s reasonable to assume (correctly or not) that the application itself is difficult to use. Furthermore, Code Climate is usually an addition to our customers’ development process, not a replacement. As such, any effort required to install our product is overhead our customers didn’t previously incur.

We knew the success of our enterprise offering would depend in no small part on overcoming these challenges in our deployment experience. So when we set out building Code Climate Enterprise, we were determined to treat that part of it as a primary concern.

Around the same time, we started to make an engineering investment in Docker in order to modernize how we build Code Climate internally and make it easier for users to consume Code Climate Platform. As an extension of these efforts, we also created a monolithic Docker image as our first deployment of Code Climate Enterprise.

In some ways, this achieved our main goal—a simple, Docker-based deployment model. Our plan was to start small and simple because that’s how we approached software and, conveniently, all we could afford with our small engineering team. We wanted to build an MVP and then iterate it to perfection.

However, containerizing an existing application is only a small part of actually delivering it to paying customers. And despite our cognizance that the deployment experience was a big deal, actually building that turned out to be an error-prone procedure that led to a significant amount of hand-holding for our first on-premises customers. On a related note, we were also painfully aware that the time we spent perfecting our deployment tooling was time not spent developing our own core product.

It was manageable, but just barely, and certainly not scalable.

Enter Replicated

A year after launching Code Climate Enterprise—about two-and-half years ago—one of our investors introduced us to a new company, Replicated, focused on helping SaaS providers port their applications on-prem. Replicated solved a number of the problems we faced with Code Climate Enterprise deployment, including automated functions for installation, support, reporting, upgrades and license-management.

Additionally, Replicated is Docker-native and, in fact, expects applications to be packaged as Docker containers. This allowed us to leverage the work we’d already done to containerize our services and to continue down that path.

code climate screenshot

We were able to reimagine our entire analysis pipeline, ultimately moving to our plugin-based analysis—a way to write and run static analysis tools with standardized inputs and outputs. We moved from a single monolithic Docker image to several independent Docker services. Where Replicated comes in here is that we were able to iterate and improve on these services using our existing development processes, and our customers are entirely insulated from those changes until they install the latest updates.

Because we were early Replicated customers, there were initially some features that needed to mature and we ran into some issues that required in-depth technical support. However, the support staff has always been responsive and willing to help, even sharing some Docker expertise as we were getting started.

Today: Rapid releases and happy customers

Working with Replicated has been a big win, in large part because it has allowed us to spend less time building and supporting our enterprise version and more time building actual features. While we used to ship quarterly, we have now settled into a monthly release cycle. Replicated relieves the burden of managing our deployment experience and lets us iterate more quickly on the software that matters most – the software that ships to our end users.

Additionally, the pilot experience for prospective customers is smooth, which is important for closing enterprise deals where every little thing can potentially be a reason to quash a deal.

An added benefit is that shortly after we decided to use Replicated, several other companies in the developer-tool ecosystem—including Travis CI, npm, CircleCI, Waffle.io, Sysdig and, now, HashiCorp—all selected Replicated as the platform through which to ship their on-prem products. Having a standard solution means less work for each of us, and also a more consistent experience for our mutual enterprise customers.

No items found.