Once upon a time, back when waterfall was the primary software development methodology, you could spend months or years working on a single software project. With the help of agile methods, programming cycles were reduced to days or weeks.
How quaint all that looks now! Weeks? Ha! In today’s DevOps-driven world, we use continuous integration, continuous delivery, and continuous deployment (CI/CD) to update programs in time frames measured in days or hours. For example, with its CI/CD pipeline, Netflix takes less than half an hour to move its programs from code check-in to multi-region deployment.
Can you say fast? I knew you could!
Automation is a key part of the CI/CD process, so naturally there are several tools that aim to help you manage the tasks. To set the stage, let’s review the basics of CI/CD before I give you an overview of some popular CI/CD tools.
How CI/CD works: A short refresher
In CI, developers integrate their code into a shared code repository’s main branch early and often. The goal is to reduce development costs by dealing with issues as soon as possible.
With continuous integration, the software is not written in isolation and then merged into the larger system at the end of a development cycle. Typically, code is integrated multiple times a day. Thus, programmers can resolve code conflicts and other issues while it’s still relatively easy to fix them.
Doing this manually would be incredibly time-consuming and annoying. For practical purposes, nearly every CI setup uses automated test suites. When code is ready to merge, an automated process kicks off a new codebase build. The automation also runs a suite of quality assurance tests to check for bugs and determines if the update introduces integration problems.
Continuous delivery is the next step after CI, in which you also automate release cycles. This may mean deploying new application versions when the software passes automatic tests. For instance, one such test, called a canary release, rolls the application out to a small subset of users; after getting their sign off, the system releases the software to production.
Finally, once an IT shop is comfortable with continuous integration and delivery, it can attempt continuous deployment. New code is continuously released to users in a process called a pipeline. All changes that pass successfully through the production pipeline’s automated tests are automatically released. That means the end of release days or Patch Tuesdays. When all works well, the code moves smoothly and automatically from programming to testing to release.
To make all this happen—and achieve the “when all works well”—you need the right tools. Here are some of the best known ones.
Jenkins
If you know of any CI tool, chances are it’s Jenkins. This open source program, which is supported by CloudBees, is one of the oldest and best-regarded CI programs. It also has about 2 million users, making it the most widely deployed CI program.
Jenkins is a cross-platform CI tool that can be configured both through a GUI interface and console commands. Jenkins’ CI process can be defined either declaratively or imperatively using the Groovy language or with text boxes using Jenkins’ web user interface.
Jenkins is noted for its flexibility. In large part, that’s thanks to the ease of adding plugins and the power provided in doing so. This can be a mixed blessing. Since everything is done using plugins, from listening for web hooks and watching repositories to supporting Docker, some DevOps consider Jenkins to be fragile.
Written in Java, Jenkins began as a fork of Sun/Oracle’s Hudson in 2011 and was released under an MIT license.
f you don’t want to run Jenkins on your own servers, CloudBees offers a hosted solution. CloudBees also has a full analytics platform, but you have additional options; advanced analytics and dashboards also are available from Jenkins’ large open source community.
With more than 1,400 plugins, Jenkins’ flexibility and broad support demands you give it a try. It’s especially popular with GitHub build integration, but it can be used for almost any conceivable CI/CD job.
Buildbot
Buildbot is a popular CI framework with a long history. It dates all the way back to 2003, when Mozilla began using it. While Mozilla depreciated Buildbot in favor of Taskcluster, the older tool is still used by other well-known open source projects such as Chromium, GNOME, and WebKit. Buildbot itself is written with the Twisted Python library and licensed under the GPLv2.
A Buildbot installation comprises one or more controllers and multiple workers. The controllers monitor source-code repositories for changes, coordinate workers’ activities, and report results to users and developers. Workers run on all major operating systems and version control systems.
To configure Buildbot, you provide a Python configuration script to the controller. These scripts can be simple, using built-in components, or expanded with Python. That makes it an easy choice for any pythonista, and suggests a steeper learning curve if you don’t know Python.
At heart, Buildbot is a job scheduling system. It’s used primarily to automate build testing across a wide array of platforms. If that’s all you need, check it out. Need more? Keep looking.
CircleCI
The CircleCI tool is admired for its speed. That’s because CircleCI caches builds and can run tests in parallel over multiple machines. The net result is quick test times. It’s also appreciated because it can be run in the cloud or as an on-premises version.
You can use CircleCI on almost any operating system or cloud. CircleCI is a single-page web application that makes heavy use of AJAX and HTML5. What you can’t do with it is build Windows applications. While you can build applications using .NET Core under Docker with CircleCI, that’s far from full Windows building or test support.
The program gets good marks for usability. Explains Forrester in a report, its “setup wizard, with its out-of-the-gate YAML Ain’t Markup Language (YAML) examples and next-step guides, is one of the most developer-friendly tools for configuring projects. Reference customers were impressed with the simplicity and flexibility of setting up build notifications and alerts.” Among the other advantages cited are its build diagnostic capability via Secure Shell (SSH), workflows, and Docker support.
CircleCI build configurations are stored in a file called circle.yml, which lives in each project’s root directory. By treating CI configurations like any other source code, it’s easy to back up and share CircleCI configurations.
In addition, CircleCI works in conjunction with other common developer tools, such as Slack, HipChat, and IRC, as well as testing tools like Code Climate and Sauce Labs. There’s also an option to notify you only if the build status changes.
While it is not an open source program, the company says you can build open source projects on CircleCI.
If you’re wedded to open source or Windows, you can skip CircleCI. But if that’s not you and you need really fast testing, CircleCI deserves your attention.
Spinnaker
Netflix knows a thing or two about CI/CD. Spinnaker, its continuous deployment tool, is a microservices application based on a set of Docker containers. Since 2014, every time you’ve enjoyed watching “Stranger Things” or “The Unbreakable Kimmy Schmidt,” you can thank Spinnaker for their smooth delivery to your television.
Spinnaker can be deployed in Docker Swarm or Kubernetes clusters and be set up in Amazon Web Services (AWS), Azure, and Google Cloud using templates. Spinnaker can package application artifacts, such as binaries and container images. You can also use Spinnaker with other CI tools, such as Jenkins and CircleCI, which may be a good option for a shop that doesn’t want to standardize on a single tool. For all its good points, you should know Spinnaker is not a build tool; it’s a testing and deployment tool. The build part is handled by Jenkins or other CI tools.
For CD, though, Spinnaker demands your attention. Spinnaker boasts a multicloud approach and pluggable architecture. Its predecessor, Asgard, had been locked in on AWS.
Google joined forces with Netflix with shared goals in creating open source Spinnaker. As Google product manager Christopher Sanson explains, “Out of the box, Spinnaker supports sophisticated deployment strategies like release canaries, multiple staging environments, red/black (a.k.a. blue/green) deployments, traffic splitting, and easy rollbacks.”
This makes Spinnaker especially good at testing and deploying applications across entire server fleets very quickly. Thus, Netflix uses it to constantly update its software at a breathtaking rate.
Among its virtues is its wide support on nearly every platform. Spinnaker currently runs on AWS EC2, Kubernetes, Google Compute Engine, Google Kubernetes Engine, Google App Engine, Microsoft Azure, and OpenStack, with support for Oracle Bare Metal and DC/OS (Datacenter Operating System) coming soon. You can also work with Spinnaker’s open source code, which is under the Apache 2 license.
Zuul
Zuul is an open source CI/CD program that’s been hiding in plain sight since 2012. You probably overlooked it because its creators were using Zuul as the in-house CI/CD system for the then open source OpenStack cloud program. OpenStack started its CI work with Jenkins but decided it needed something more to handle its complex, multiple-project needs.
OpenStack, if you don’t know it, is made up of over 50 open source programs. Managing its numerous components from multiple contributors was, and is, a challenging job.
The Zuul project’s focus is on multi-repo gating. In this methodology, Zuul strives to automatically ensure correctly ordered testing of changes in parallel, which in English means making sure things happen in the right order. This speeds up the CI process so developers don’t have to wait forever for their changes to make it into the code repository.
Zuul accomplishes this with its dependent pipeline manager, which enables parallel execution of test jobs for gating while ensuring changes are tested correctly, exactly as if they were tested one at a time. How? By performing speculative execution of test jobs. Zuul assumes that all jobs will succeed and then tests them in parallel. If they do succeed, all the code can be merged, which certainly speeds up software integration.
However, if one code snippet fails, the batch is reexamined; changes that were expecting it to succeed are re-tested without the failed change. In the worst case, changes are tested one at a time. This makes Zuul ideal for handling large, complex projects.
The OpenStack Foundation recently spun out Zuul from the main OpenStack project. Zuul is open source and licensed under Apache 2. If you’re dealing with complex projects, spend some time investigating its features.
The future of CI/CD
This is far from an exhaustive list. There are dozens of others.
Before deciding which tool is right for you, look at your projects and what you really need to move them into the 21st century. For example, Zuul is overkill for most projects. Others, such as Spinnaker, are great for testing and delivery, but they’re not meant for integration.
- Before looking at the tools, decide on which functionality you need. There’s no point in investing in Jenkins, which is great at CI, when what you really want is a CD tool for your existing CI system.
- Do you want to self-host or use a cloud-based service? What are your company’s data storage rules? Which fits better in your budget? Keep in mind if you self-host, you need an in-house DevOps team to run it.
- What do others in your field think about these services? Is there already a recognized best-of-breed CI/CD tool in your business? Or, as with Kubernetes, must you face the sad fact that there is “no single best set of tools” for CI/CD. In any case, you need to do a lot of testing to find the right fit for your company.
Best practices in CI/CD are still a work in progress, and so are the tools that support them. It’s likely that we soon will see a shake-up as the best CI/CD tools prove themselves in the marketplace and on DevOps’ desktops.
While Netflix, CI/CD’s poster child, can complete integration, testing, and delivery in hours, most companies are far from reaching that level of efficiency. Given the business advantages, it’s a goal well worth working toward.
CI/CD is not an end to itself. But when you couple it with your business goals, you’ll be taking a major step forward in improving not just your software deliverable times, but your bottom line as well.
CI/CD tools: Lessons for leaders
- There are many significant CI/CD programs. For now, there are no true market leaders. Expect to try out several to find the one that best fits your business needs.
- Before you decide on a CI/CD tool, analyze your corporate CI/CD needs. This means you must work closely with your development team.
Continuous integration and delivery tool basics was first published in HPE enterprise.nxt