Paul Biggar is the founder of CircleCI, the leading continuous integration/continuous delivery platform that enables development and software teams to build, test, and deploy — quickly and consistently — across numerous platforms. Before CircleCI, Paul worked on the Firefox Javascript engine, and completed a PhD in Compilers and Static Analysis. Paul is also co-host of To Be Continuous, a podcast on all things continuous delivery.

We sat down with Paul to talk about what’s driving companies of all sizes to adopt continuous delivery practices, his company CircleCI and what to prioritize when building products for developers.

On the rise of DevOps and continuous delivery…
DevOps is tied to the rise of larger and more complex Web applications. Today, applications are decentralized and served from many machines spread across multiple datacenters from several regions. They are being built as distributed systems which are meaningfully more complex than the single machine/single-user downloadable applications of ten years ago. Because of this scale and complexity, it is no longer possible to manually manage these applications with a handful of sysadmins. So DevOps arose out of the need to automate many of the rote operational processes of provisioning servers, deploying applications, scaling applications, etc. DevOps is really software eating IT ops.

Continuous integration / continuous delivery is an important subset of the overarching DevOps trend that focuses on automating the deployment workflow. It’s all about taking code from a developer’s terminal, testing it and getting into your customers’ hands in a highly repeatable, automated and scalable way.

On continuous integration vs. continuous delivery vs. continuous deployment…
Continuous integration (CI) relates to the test and build function of software development. Every time a developer pushes code, a CI server validates that the code works. Each code check-in is verified by an automated build which runs all your tests and integrates changes into the main repository from where it goes to production into the hands of customers. Ultimately, CI is all about ensuring the code you’re writing works and works well.

Continuous deployment is closely related to CI, and refers to automation of code releases into production of software that passes automated tests.

Continuous delivery is the principle that you’re going to be continuously releasing new code to customers — a couple times a day, 10 times a day, 50 times per day. Continuous integration and continuous deployment are the putting into practice of the continuous delivery principle.

On what’s driving the adoption of CI/CD….
If we really trace the heritage of CI/CD, it was born out for the macro themes of lean and agile which are all about being able to validate, as early as possible, that there’s a need for your product before you spend large amount of resources on development, and then iterating quickly. Both those themes are related to the fact that, at the end of the day, all businesses want to 1) move faster and 2) reduce risk. CI/CD is related to both, and to me continuous delivery is really about reducing risk associated with shipping new software. If you’re shipping something quarterly you’re creating huge amount of risk for your organization, as opposed to shipping something weekly, daily or hourly where you’re able to spread out that risk. You see this with projects like Healthcare.gov where they didn’t implement continuous delivery practices and therefore didn’t have early validation process in place to ensure it wouldn’t be a disaster that ran into the hundreds of millions of dollars.

On starting CircleCI…
Before starting CircleCI, I was working at Mozilla at a time when they went through a transformation from an 18-month release cycle to a six-week release cycle. The improvement that change alone led to in the quality of software we put out was phenomenal. It was that “ah-ha!” moment that made me believe that adoption of continuous delivery was the closest thing to a silver bullet there was in software development. What was striking was that we saw all these gains despite really bad tooling. Our continuous integration server was outdated and constantly crashing; it was maintained by an ops team who singular focus was to keep the servers up and not the experience or productivity of the devs. At the same time there where these trends around GitHub where your source code now lived in the cloud and Heroku where your application now lived in the cloud, but people were still deploying and testing on Jenkins locally.

So I left to start CircleCI because I believed their needed to be a cloud CI/CD solution that was built and operated under the assumption that developers were going to be the core users. Our job was to make sure they could release better code faster.

On what makes CircleCI different …
The major focus for us at CircleCI has been on large teams that are building commercial software. So every waking minute, we ask ourselves what can we provide dev teams working on enterprise-class software that makes their lives easier and their code better. So from Day 0, we had built tools that enable devs to debug complex builds, to be able to monitor and analyze builds, to be able to automatically parallelize long builds, etc. Just recently, we launched a product called CircleCI Insights which shows the analytics on how your build is developing and whether the productivity of your team is getting better or worse based on build times. That’s exactly something that teams need to understand in order to improve their performance. We’re laser-focused on companies that produce a lot of software and do so in large teams, so that’s informed a lot of the product choices we made that make us different from competing solutions.

On what to prioritize when building products for developers…
Developers have lived a dual history in terms of products and services they’ve used. On one hand we’ve seen the emergence of some amazing developer-centric tools — like GitHub and Heroku — that have spread organically. On the other hand, there were and still are a bunch of legacy, enterprise tools that came in through the CIO and forced onto developers. In both cases, we’ve seen developers and entire developer communities react very strongly to both sets of tools, and this reaction is and has been largely emotional. So this tells me that even more important than any functional feature, is that you need to speak to developers with your product, with your marketing, with community. When we talk to developers, we’re very sensitive about the language we use and the experience we deliver. We want to communicate that “we are you” and so we understand who you are. If you can get that messaging right and embody it in everything you, as a company, product or service deliver, you have a chance.

On where to find him…
Obviously check out CircleCI, but also I — along with Edith Harbaugh, founder of LaunchDarkly — host a podcast called To Be Continuous. On it, we discuss the macro view of how to build software and continuous delivery practices. We cover everything from how to find product/market fit, to how to validate product to how to function as a team in a CI/CD workflow as well as the tools and techniques for implementing continuous delivery. Check it out! ains

Memory Leak

Redpoint perspectives on distributed computing, cloud-infrastructure, developer tools, open source and security.

Scott Raney & Lenny Pruss

Written by

Memory Leak

Redpoint perspectives on distributed computing, cloud-infrastructure, developer tools, open source and security.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade