The CircleCI Blog Feed - CircleCI

How We Interview Engineers at CircleCI

Jeff Palmer — Thu, 22 Mar 2018 13:38:00 -0700

Since the beginning of 2018, we have had over a thousand candidates pass through the engineering hiring process. Our engineering interview consists of four stages following an initial screen. We broke down the percentages of candidates that pass through each stage of our hiring process, and it looks like this.

Out of any group of 1000 applicants:

250 will pass the initial screen.
117 will pass the hiring manager phone screen.
44 will pass the micro-skills assessment portion of the interview.
7 will pass the macro-skills assessment.
Fewer than 3 will pass the on-site interview and receive offers.

Following our Series C, we’ve ramped up our hiring further, building on what we’ve learned so far. We’ve been talking a lot internally lately about how we interview, and thought folks might be interested in what our interview process looks like for engineering roles, and why.

CircleCI and Snapcraft: Everything You Need to Know

Ricardo N Feliciano — Fri, 16 Mar 2018 03:00:00 -0700

Snapcraft, the package management system fighting for its spot at the Linux table, re-imagines how you can deliver your software. A new set of cross-distro tools are available to help you build and publish “Snaps”. We’ll cover how to use CircleCI 2.0 to power this process and some potential gotchas along the way.

How a Seemingly Simple Logging Problem Turned into a Bear Trap: Lessons Learned

Alexander Mann — Thu, 15 Mar 2018 02:41:00 -0700

“Developers are drawn to complexity like moths to flame, frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn’t like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.” Neal Ford

I have been coding in Clojure for almost 4 years now. I have been fighting with logging in Clojure for almost 4 years now. This is not something for which Clojure is solely to blame, but it is something that seems to often suffer the Lisp Curse.

This past year, while working in a field of green (ie, building Contexts), I was once again confronted with a “simple” problem in the realm of logging…namely we were spitting out all of our secrets. Figuring this was probably enough to block launching it publicly, my team took some time to dig deeper and hunt down the errant class writing all of our requests to stdout.

CircleCI: Helping Intuit Teams Save 40% (or more) on CI/CD

Tue, 06 Mar 2018 08:53:00 -0800

This post was originally published on Intuit Quickbooks’ engineering blog.

Docker on CI is powerful

CircleCI has an amazing set of features in a simple package that allows our developers to move faster than ever before. Coming from our old build system, we wanted to push Circle to the limits such that we could squeeze as much speed out of it as possible.

Goals

Be as small as possible
Be reliable/reproducible
Be fault tolerant

From the outset, we wanted to make sure that we could build at scale with the least amount of friction possible. That meant embracing open source, and interweaving it our internal solutions. At each step of our build process, we focused on these things.

We’re Sunsetting CircleCI 1.0: August 31, 2018 is the Final Day for 1.0 Builds

Matt Wyman — Tue, 27 Feb 2018 08:08:00 -0800

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.

A Brief History of DevOps, Part IV: Continuous Delivery and Continuous Deployment

Alek Sharma — Mon, 26 Feb 2018 08:57:00 -0800

(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.

Preserve Build Integrity and Prevent Future Problems with Deterministic Builds

Ricardo N Feliciano — Thu, 22 Feb 2018 06:00:00 -0800

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.

Headless Chrome for More Reliable, Efficient Browser Testing

Zachary Scott — Thu, 15 Feb 2018 06:40:00 -0800

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.

How Open Listings Uses CircleCI to Scale Rapidly and Ship Safely

Tue, 06 Feb 2018 09:22:00 -0800

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.

A Brief History of DevOps, Part III: Automated Testing and Continuous Integration

Alek Sharma — Thu, 01 Feb 2018 07:06:00 -0800

(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.