CircleCI Blog

The Perks of Going Distributed

Since our early days, CircleCI has purposely embraced building a global workforce. This simple choice has given us many advantages. First, we have access to the best talent on Planet Earth. The great variety of viewpoints we have access to helps us make better decisions. Equally important: it allows us to continuously deliver value to our customers 24 hours a day. Having team members all over the world brings many advantages for us as a company.

What’s even more valuable, though, is knowing that the flexibility to work remotely confers some pretty great benefits on our global employees as well.

As a Success Engineer, I often see a lot of confusion around using Docker on CircleCI. Before the release of CircleCI 2.0, it was possible to build and test applications without ever having to think about Docker: all our builds ran in LXC containers, configured by our inference engine to include any necessary tools and dependencies in an oftentimes fairly automatic way.

With the release of CircleCI 2.0, however, we’ve placed Docker front-and-center in our build process: any Docker image, public or private (we now support private images hosted on Amazon’s EC2 Container Registry, too!), can be the primary container for a build. This adds power and customization to the build process, especially when combined with Workflows, which allows for sets of jobs (build, test, deploy, etc.) to be strung together, sometimes running in parallel, each with its own base Docker image. To aid the transition from CircleCI 1.0 to 2.0, we’ve even provided a wide range of convenience images to meet common language and dependency needs, tweaked to maximize compatibility with the CircleCI platform.

However, as they say, with great power comes great responsibility. Using Docker can be intimidating. For some developers, it may seem to have a high learning curve. Others worry about maintenance or upkeep for any images they’ve created. And then there are privacy concerns—after all, many of the images on the main Docker registry, Docker Hub, are completely public.

Workflows has led many people to get “job happy” in their config files. One job to ‘build’, another to ‘test’, and another to ‘deploy’? Maybe, that’s not too bad. How about a fan-out, fan-in workflow that comes in at a total of 5 jobs where each uses the same Docker image? There’s going to be redundancy in that config.yml file. We can reduce it, and make YAML do the work for us.

Our Outrageous Decision to Orchestrate Nomad with Kubernetes

“Write less code.”

Rob Zuber, CTO of CircleCI, stepped back to observe this directive, written in faded scarlet on a whiteboard. Like all important directives, this one was pithy and counterintuitive; how could we possibly hope to build CircleCI 2.0 by doing less?

If you’ve read this blog post about our release philosophy, you’ll remember that replatforming was a pretty frightening prospect for us. One of the reasons it was so frightening was that we were starting from scratch; there’s a real danger in overdesigning a product when you do that. But there’s also an opportunity to take stock of all the new options — the great work that’s been done to advance the toolset.

Combining CircleCI, GKE and Houston to get code to customers simply, safely, and quickly.

This post was written by Mark McBride, CEO at Turbine Labs, Inc.

Overview

Engineering teams don’t exist to manually execute release processes or stare nervously at production metrics; they exist to build and deliver products to customers. We develop release processes to ensure the products we’ve built are good, understanding that the time spent on this assurance comes at a price: time spent thinking about releasing is time spent not thinking about product. At Turbine Labs, we spend a lot of time thinking about how to improve this balance, and it’s why we built Houston. Here we’ll show you how to create a high quality, low overhead continuous release pipeline for web applications using a combination of CircleCI, GKE and Houston.

We are excited to announce that Xcode 9 is now available for use on the CircleCI macOS platform.

The latest Xcode release, announced just yesterday, adds multiple improvements to the build system, which in turn brings great benefits to all customers using Xcode 9 in their CircleCI projects. The changes include improved simulator stability, significant reduction in the amount of Exit Code 65 failures, and shorter app build times.

To start using Xcode 9 in your macOS builds on CircleCI you can add the following to your circle.yml:

machine:
  xcode:
    version: "9.0"

TL:DR; CircleCI 2.0 now supports authenticating to AWS EC2 Container Registry (ECR) straight from the Docker executor. This means you can use private Docker images from ECR as your build image. View docs.

Starting today, customers using CircleCI behind their firewall can now access all of the features and performance that CircleCI 2.0 delivers, including Workflows, full Docker support, and VM-based jobs. CircleCI 2.0 has been generally available for our cloud customers since early July, and the results for those who have switched to 2.0 have been impressive.

CircleCI 2.0 ushered in a new era for continuous integration and delivery. Among the new features in 2.0 (including a new configuration file format, an emphasis on Docker images, and Workflows) came the ability to build locally via the CircleCI CLI. We can use local builds together with Git to validate our config file on EVERY COMMIT, effortlessly.

This post is written by Jacque Garcia, who was a summer 2017 Engineering intern at CircleCI.

Hello CS

As a kid from Compton, CA who had never even heard of “coding,” if someone would have told me 4 years ago I would be majoring in Computer Science I would have given them my eyes of suspicion.

I am originally from Compton, California (yes, “Straight Outta” Compton, and no, I have not seen the movie) and I am currently pursuing my Bachelor’s degree at UC Berkeley. I went undeclared my Freshman year after realizing that my major at the time, Chemical Engineering, wasn’t (and wouldn’t) make me happy. Something was missing.