Imagine you’ve been invited to a 24 hour diner famous for 5 star meals. There’s a large kitchen staff filled with chefs and specialists for ingredient buying, planning, preparation, cooking, arrangement and service to the diners. There are endless changes and updates to the official menu, and constant taste testing to avoid accidental poisoning or at least not turn off diners. Managing the moving parts of all new changes makes it a success.
Continuous Integration and Delivery (CI/CD) does this for software projects – it manages software changes, testing and delivery to end-users.
DevOps and the Software Development Life Cycle (SDLC) involves multiple developers and continuous changes. Continuous Integration / Continuous Delivery (CI/CD) manages the traffic control of DevOps’ workflows. CI/CD is a philosophy about how to launch good software changes and updates.
Why is Continuous Integration / Continuous Delivery Important?
“Combining the work of multiple developers is hard. Software systems are complex, and an apparently simple, self-contained change to a single file can easily have unintended consequences which compromise the correctness of the system.”
CI is focused on updates and testing. It’s much like a kitchen staff creating new dishes, introducing different ingredients and taste testing, and making them ready for live production – for the “diners”, software end-users.
“Continuous integration is the process of taking your code and putting it together (integrating) with all of the other code.”
CI keeps changes in a project from piling up and overwhelming the value of including changes. The right CI tools automate chores, provide backtracks in case developers need to “undo” and keep clean records of projects.
What follows Continuous Integration? Continuous Delivery.
CD follows CI’s testing, and makes changes ready for delivery.
Continuous Delivery automates the integration of software updates. Automation puts the CI/CD philosophy and attitude into action.
“Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them.”
Key rule: CI/CD can only integrate what has been tested first.
Amazon’s description of CI offers a simple top down view:
“Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.”
“Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently).”
“The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.”
An image from Amazon describing CI/CD helps illustrate the workflow:
This is not a new idea – here’s a 2010 quote on Continuous Delivery (CD):
“Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.”
“In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production.”
CI/CD works like a five-star restaurant: Build and test early on. “Taste” as you cook in “small batches”. Don’t wait until a multi-course meal is ready to leave the kitchen for dining service – you can’t undo untested spoiled dishes without waste, repetition and drama. Each dish has to be ready for service.
When dishes approved for “service” actually leave the kitchen for the dining room, that’s when the people who made the food are done.
“Continuous delivery is taking the code from the main repository and getting whatever kind of artifact that’s produced by the code into a production environment. Preferably this is through an automated process where no manual intervention or steps are required to deliver that artifact. This means that the steps required to get the artifact into production are codified in some way that an automated process can follow. Each step should boost your confidence that your system is indeed going to run in a production setting and things are going to work as expected.”
Here is a picture of the same CI process. (via Hackernoon) VCS is “Version Control), CI Server is (Continuous Integration Server) and App Server is where the tested and production ready changes are delivered.
Other CI/CD terms – “feature flags”, “version control branching”.
CI/CD includes “feature flags” and “version control branching”. Flags are changes which may be included in the production version but have not been “turned on” until they’re ready to go live. Branching is traffic control. Each change contributed to the repository, “feature”, is like a car in a multi-lane highway. “Version control” is about how to “merge” features, which exist in separate branches, into the right traffic lanes (such as “development”, “testing” and “production”/live software).
Let’s recap about CI/CD’s place within DevOps:
“Continuous integration and continuous delivery (CI/CD) enables the key promise of DevOps: delivering code changes more frequently and reliably.”
“In software engineering, continuous integration (CI) is the practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day…”
Continuous Integration is both a practice and an attitude:
“… continuous integration is an attitude, not a tool. It’s a shared agreement by the team that:
- When we get the latest code from the repository, it will always build successfully and pass all tests.
- We will check in our code every two to four hours.
There’s lots of ways to make this happen, but they tend to be a variation on this theme:
- Before check-in, run the build and tests and make sure they pass.
- Tell people not to update from the repository because you’re doing an integration.
- Check in.
- Go to a different machine (often a dedicated “integration machine”), get the latest code from the repository, and make sure latest changes build and pass there, too.
- Done–tell people they can update again.”
Every job needs tools and for CI/CD, there are tools including:
Jenkins is a leading tool for automation of CI/CD processes.
“Jenkins is the number one open-source project for automating … With thousands of plugins to choose from, Jenkins can help teams to automate any task that would otherwise put a time-consuming strain on [resources]. Common uses include building projects, running tests, bug detection, code analysis, and project deployment.”
From a near 80% share of the CI/CD market, Jenkins is at the top of most common CI/CD tools.
Jenkins is the oldest vendor in this space, with a market share of 70 to 80%, a user base of 1M+ million developers with access to community support tools. There are about 1500 plugin choices to automate workflows, and more can be created and shared within this community – a powerful network effect.
“[Jenkins] …. was one of the earlier big players in the continuous delivery space. It helped push the whole concept forward by giving you a powerful build and delivery pipeline. Along with its large plugin ecosystem, you could spin up nearly any workflow in a snap. Jenkins X is the new version of this platform that targets Kubernetes and Docker.”
“The industry at large is now moving toward having Docker as the base component in systems. With Kubernetes now the leader in running Docker “containers”, there’s a need to take advantage of these systems and make it easier to deploy. Jenkins X took the lessons learned from Jenkins, then applied them to a Docker and Kubernetes ecosystem.”
(We wrote a note about DevOps tools like Docker and Kubernetes.)
A few of the many CI/CD tools available include TeamCity, Circle, GitLab CI/CD, GoCD, TravisCI, Buddy, Bamboo, Chef, Puppet, and Drone.
TeamCity
TeamCity is the next best alternative CI/CD tool aside from Jenkins. This tool is secure “out of the box” with stable plugins. Like market leader Jenkins, TeamCity is used for Java and .NET projects.
CircleCI is a leading CI/CD cloud-based platform with a wide range of features. Thousands of developers -free from having to create and manage a “build infrastructure” – have used it to build, test and deploy their code.
GitLab
GitLab CI is built for GitLab. It’s a fast growing CI/CD platform running on a dashboard with a developer friendly user interface and documentation for every feature.
GoCD
GoCD is a continuous delivery server released by ThoughtWorks in 2010 and specializes in advanced workflow modeling for deployment pipelines.
TravisCI
Travis CI provides CI for software projects hosted at GitHub and Bitbucket.
Buddy’s platform with a well-designed and feature rich user interface. It enables automation with simplicity highlighted by its automation pipeline.
ATLASSIAN BAMBOO
Atlassian’s CI server, Bamboo, supports mobile developers automated delivery of apps to the Apple or Google apps stores.
CHEF
Chef for the better part of the last decade has been a trusted configuration management platform. It provides automation of infrastructure management, configuration and deployments irrespective of the scale of the network. It works for all environments – on site local hosting, cloud or hybrid environments.
PUPPET
Puppet is an open source tool which can manage both Unix and/or Windows configurations.
DRONE
A CD platform made for DevOps platform Docker – custom configurations are enabled thanks to a rich resource of plugins.
Proper service requires both the right tools and the right technique, practiced by DevOps specialists. If you have any questions about CI/CD for your needs, please feel free to reach out to us at Osolabs.
