CircleCI Blog

TL;DR: After August 31, 2018, CircleCI 1.0 will no longer be available for Linux and macOS users. You can find guides for transitioning from 1.0 to 2.0 and a full timeline on planned changes here.

We launched CircleCI 2.0 for general availability in July 2017, providing users with increased flexibility, power, and control. Since then, build times on both our Linux and macOS fleets have been dramatically reduced. We’ve been able to handle increasing numbers of users and jobs, while simultaneously decreasing average job time across every language we serve. The addition of Workflows in 2.0 has also made it possible to match your pipeline to your team’s needs.

(This is part four of a four-part series. Read parts one, two, and three here.)

This is it, folks: the final chapter in our epic trek through the history of DevOps! Last time, we talked about how the Agile movement gave rise to the more defensive practices of automated testing and continuous integration. This time, we’ll be discussing the progression of that theme with continuous delivery and continuous deployment.

Admittedly, the introduction of two more “continuous” terms is a bit confusing, especially because the lines between one term and the next are so blurry; it doesn’t help that they are recent developments and could be renamed at any moment.

But fear not! We’re well-equipped to deal with this kind of volatility and will tread carefully. At this point in our saga, “history” is hardly even the right word for what we’re discussing. What we’re really talking are current events, which is very exciting but also much squishier than more concrete subjects like waterfall development or Agile methodology.

Why are Deterministic Builds Important?

Reproducibility and reliability.

The most common thing a customer will say in a support ticket is that their builds are suddenly failing even though “nothing has changed” on their end. This is almost never true.

In this post, I want to talk about deterministic builds. The idea here is to reduce as many changing parts as possible within a build. This means fewer mysterious failing builds, fewer support tickets (for you and us), and perhaps identically reproducing that accidentally deleted binary by simply re-running the build.

Chrome and Punishment: Browser Tests and You

Browser testing is a popular strategy for web application developers to verify their programs from the user’s perspective.

However, automating this process has always been challenging for teams who depend on Continuous Integration (CI). The environment isn’t always suited for testing a JavaScript-heavy web application due to demands on memory and network throughput.

With the release of Headless Chrome, there is hope.

Let’s explore why this is a problem and how Chrome helps to solve it.

The following is a guest post by the team at Open Listings: Kevin Miller, Director of Growth, and Alex Farrill, CTO.

I. The Challenge Prior To CircleCI

At Open Listings, we’re a scrappy and passionate team focused on an ambitious mission: making homebuying simple and affordable. Our product is fairly complex, as it has to address homebuyers’ different needs through each distinct step of the homebuying process. There’s no practical way to support all these use cases without thorough automated testing.

Fortunately, we’ve been serious about automated testing from commit one. We run unit tests in Ruby that test our algorithms for things like dispatching agents to properties, along with how the application interacts with our MongoDB database; Ruby functional tests that test our API responses; end to end integration tests with capybara, phantomjs, and Selenium; and front end javascript tests with Jest that test our React.js code. Our tests run in a Docker container that is as close as possible to the environment we run in production on Amazon AWS.

(This is part three of a four-part series. Read parts one, two, and four here.)

Welcome back, dear reader, to our ongoing journey through the rich history of DevOps! In the last chapter, we discussed the many movements that led to Agile methodology. Towards the end, we foreshadowed how constant validation would play a role in this chapter.

Now that foreshadowing is coming to light! This time, we’ll be discussing two processes near and dear to our hearts: automated testing and continuous integration.

(This is part two of a four-part series. Read parts one, three, and four here.)

Welcome to another chapter in the feature-rich story of DevOps!

Last time, we discussed why the history of software development is important and how waterfall development fit into that narrative. Remember that waterfall development was ironically rather rigid. It lacked the flexibility to adapt to change, a noticeable weakness in a world that is increasingly volatile.

In this chapter, we’re going to explore how (and to what extent) engineers iterated on the waterfall model through Agile Software Development. Instead of trying to control change by locking down phases of development, Agile methodology is about embracing change. Risk is lessened not by devising the perfect plan, but by cutting projects into small chunks and adapting on the fly.

But enough spoilers! Let’s dig around in the roots of Agile philosophy.

Today, we’re happy to have this guest post written by Andrew Taylor, Community Engineer at Pantheon, about their experience migrating to our 2.0 platform. Read on for their tips and takeaways.

Background

I work at Pantheon, a WordPress and Drupal development and hosting platform, where a large part of my role is to help developers take advantage of our platform by creating examples of complex workflows. In February 2016 I started an Advanced WordPress on Pantheon repository with the goal of setting up an enterprise grade WordPress workflow.

The project has source files committed to GitHub, with production versions and dependencies ignored. I needed a way to turn the source code into production code, deploy it to Pantheon and run automated testing. Naturally, I used continuous integration to solve this problem.

I chose CircleCI due to their generous free tier, allowing 1 worker for private projects and 4 workers for open source projects. Since I created a public project this was perfect - I was able to adopt CircleCI for my build, deploy and test steps.

(This is part one of a four-part series. Read parts two, three, and four here.)

Software engineers spend most of their waking hours wading through the mud of their predecessors. Only a few are lucky enough to see green fields before conflict transforms the terrain; the rest are shipped to the front (end). There, they languish in trenches as shells of outages explode around them. Progress is usually glacial, though ground can be covered through heroic sprints.

But veterans do emerge, scarred and battle-hardened. They revel in relating their most daring exploits and bugfixes to new recruits. And just as individuals have learned individual lessons about writing code, our industry has learned collective lessons about software development at scale. It’s not always easy to see these larger trends when you’re on the ground — buried in bugs and focusing fire on features.

Today we announced a $31M Series C by Top Tier Capital Partners alongside Industry Ventures and Heavybit, who join existing investors Scale Venture Partners, Baseline Ventures, Harrison Metal, and DFJ Ventures. There are more details in the release here, but I wanted to share our plans for our new funding, and what you should expect from CircleCI in the future.

When CircleCI launched in 2011, the world was much simpler. Rails monoliths were all the rage, Docker didn’t exist, and the latest iPhone was a 4s. Today, the world is much more complicated. Teams are running thousands of microservices in a single product, building in multiple languages, and supporting it all in the cloud.

It’s clear that our world will only continue to become more complex. We need our tools and systems to not only evolve to meet this need, but to become smarter. The demand on engineering teams show no signs of slowing down: every team is asked how they can build high quality products faster, more securely, and more productively. We believe we can help teams solve these issues, and I want to share a little about our plans for how we will start to tackle this this year.