CircleCI Blog

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.

One issue that we see a lot in support here at CircleCI is flaky web browser tests. Since most browser automation frameworks use Selenium under the hood, I decided to sit down and see what was needed to get better logs of the test process to aid customers in troubleshooting their hung and failed builds.

None of the webdriver browser testing frameworks appear to have very good logging when things go wrong. It seems that at best you will get a failed test due to the test not finding an element you know is on the page, and at worst the test sits silently until it times out.

Logging is needed to know what is going on.

Gaining access into the world of tech hasn’t been the easiest thing for me. I grew up in East Baltimore; I know how unfair the system is. People talk a lot about diversity in tech. Seems to me they think of diversity as what can be seen on the surface, but I believe it’s much deeper than that. For example, most of the other African American people I know in tech came from homes that had both parents and went to really good schools; I grew up with a single mother and went to community college. I dropped out once I finished all my core CS classes so I could start working. People in the Valley get admired when they drop out of elite schools, but if you’re not dropping out of Stanford, you don’t get congratulated. It’s all dependent on your demographic situation.