CircleCI Blog

TL;DR: Today we are changing our project setting called “Build Processing” to “Pipelines.” If you want to know why, read on. If not, nothing about this will affect you for a while, so you can stop here.

The change to “pipelines” begins our process of moving all projects over to having this setting on by default. This is the first of several changes we’ll be making to roll out the concept of pipelines throughout our platform. The vast majority of users should not notice any change because of today’s update, but we wanted to share more detail on what we are doing, and why, so you have more context on things that will be coming in the future.

An excerpt from a product manager’s retrospective on the launch of CircleCI orbs.

In November 2018, we launched CircleCI orbs. I recently wrote about the design decisions we made while building new package manager. Here, I want to share some of the lessons we learned (or re-learned) launching a major new feature. You likely won’t be surprised that we think a lot about how to ship working software, and our retro process helps us put in words what we observe and learn along the way.

What follows is an excerpt from our internal retrospective on the orbs launch initiative, edited a bit for public consumption.

Less than three months ago, we launched CircleCI orbs, our package management ecosystem for CircleCI configuration. In that time we have seen over 300 orbs created in just the first 10 weeks and more than 200 organizations using orbs across over 1,000 projects in tens of thousands of builds. We are also featuring more than 20 official partner orbs through our new Technology Partner Program. We’re incredibly grateful for the huge and positive response.

In this piece, I want to take a look back and share the key design decisions that went into creating and launching CircleCI orbs. If you’re using orbs today and want to understand how to get the most from them, or if you’re thinking about designing your own package management system, this post is for you.

Today we made a small change to the navigation inside CircleCI. Where you saw the word “builds” you will now generally see the word “jobs”. This change has zero impact on the functionality of CircleCI; all your projects should behave identically to yesterday.

That’s all you need to know to enable you to keep using CircleCI just as before. If you’re curious about why we’ve made this change, read on.

The umbrella term “DevOps” has grown so much over the last few years that the word now strains to mean the same thing for all people. This is less a semantic issue and more a reflection of the growing scope of software delivery automation. At the helm of this growth are the operators who manage the tooling and practices that enable today’s software delivery methods. Their role has morphed and grown immensely, even over just the last two years that CircleCI has been running behind their firewalls. These operators’ responsibilities are myriad: they are responsible for keeping the tool chains that developers use every day humming along while answering to the business for security, cost control, and compliance. Behind the scenes, they are keeping inevitable technical fires at bay while facing increasing pressure from senior management to deliver on Digital Transformation.

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.

Few things make us as sad as seeing a support ticket asking why a build is slow or hearing from our account managers that a customer is voicing concerns about slow builds. At CircleCI, we loathe slow builds. We consider it our mission to increase the total throughput of the software development process, and build speed is certainly a significant factor in overall throughput for many teams.