New to CI/CD? Here's a quick crash course on continuous integration and continuous deployment.
Jan 23, 2019
Alex Hisaka
D2iQ
5 min read
The driving principle behind DevOps is to optimize personnel and processes around the shared goal of rapidly delivering a valuable customer experience and iteratively improving on that experience. Organizations that rely on DevOps can improve software much faster than those that continue to rely on traditional software development and infrastructure management processes.
CI/CD is a necessary component of DevOps programs because of its ability to rapidly deliver software as containerized microservices.
The goal is to decrease time-to-release while constantly adding new features and minimizing software defects. This adds up to users getting the best possible experience available with little to no downtime.
CI: Developers Feel the Need for Speed
CI is the process of building software, in this case executable microservices, after raw code is checked in by developers (the "Dev" in "DevOps"). Once checked into a central repository, code is built and tested so that the code base is good. Functionality, security, and performance unit tests automatically run on code after developers check it in to identify bugs early in the app lifecycle.
It's critical to keep CI as straightforward and fast as possible because developers want to write code with minimal distraction.
Advantages of CI include minimizing the number and severity of bugs that make it into production, improving software quality, deploying rapidly without breaking existing functionality, speeding the deployment of new features and functionality into production, and maximizing developer productivity by reducing the time it takes to validate and release new software updates.
In CI, developers commit small code changes throughout the day, merging local code with code in the repository before pushing it to the build server. The build server then unit tests the code and either accepts or rejects the code commit.
Create and Share New Code with Source Code Control
A shared code repository sets the stage for the complete rapid application delivery process. Source control methods (such as versioning and branching) make it possible to develop, build, and test multiple code segments at the same time. Developers create and run unit tests before pushing code to the central repository. A central repository also removes the potential for developers to hold code in isolation. The CI process is driven by developers who merge code early and often.
Git (GitLab and GitHub) is a popular solution for a centralized source control repository that provides distributed version control. Source code control allows developers to share the code that they've developed individually and collaborate together as a team on the same code. Source code control retains multiple versions of the code in case it's necessary to revert to a previous version.
Source code control is an important element of CI because it's how the new code is tracked and moved through the pipeline. Developers work with code locally and share changes centrally. This gives developers flexibility in where and how they work.
After code is placed in a source code control solution, it's necessary to build it so it can be run and tested.
Build Code for Testing and Execution
DevOps teams build workflows so that when code is pushed to a particular branch of the source code repository, the changes are detected, and a builder tool is triggered to build the code and test it in a controlled environment. The build process can be time consuming and resource intensive. Automated tests include unit tests, style checks, and static code analysis that run on code after it is built to verify that it meets functional requirements and does not break current features.
At the end of the CI process, the build tool provides artifacts like binaries, images, stylesheets, and data files as needed.
CD: Operators Feel the Need for Automation and Consistency
Infrastructure engineers (the "Ops" part of DevOps) focus on continuously delivering and deploying the application code as it is developed. The goal of CD is to deliver and deploy applications to environments in an automated manner that is consistent, fast, and scalable. This requires dynamically provisioning and configuring infrastructure such as networks and servers, whether they are physical or virtual. On top of that, environments are dynamically provisioned and configured so they meet all application requirements and dependencies.
Well planned and executed CD programs result in higher quality software delivered faster and with lower risk. Infrastructure can be used more consistently and efficiently, resulting in decreased costs.
Automation is a key component of the CD process, and practices can be partially (with manual checks) or fully automated. Scripting plays a large role in ensuring consistency between environments such as cloud providers, on-premise datacenters, and hardware variations.
Many enterprise technology leaders see CD as an important opportunity to improve efficiency when migrating to container-based microservices. New tools and best practices have become available to allow for automated and flexible deployments that preserve high availability while rapidly rolling out new features. DevOps teams that validate on every commit shift the decision about when to go live to business teams because committed code is always ready to be deployed.
Teams relying on CD benefit from automating the delivery process in the following ways:
- Improving code quality
- Improving developer productivity
- Shorter feedback loops with faster code iteration
- Faster updates to customers
Release Artifacts to be Deployed
Once developers have written code, checked it into source code control, built it, and tested it, the code is now ready to be released. A release is a collection of artifacts in the DevOps CI/CD process. An artifact is a deployable component of an application. The release process combines artifacts and prepares them to be deployed in staging and production environments. It's important to have a central location to store artifacts so they can be released into production as a group. Artifacts can be reused downstream, so development teams don't need to code the same functionality multiple times.
Speed Apps Towards Deployment, Monitoring, Logging
After an artifact is created and stored, it needs to be deployed. In a mature DevOps environment, code moves from developer to deployment in a fully automated manner, allowing the code to be deployed quickly with decreased risk. Deployment typically involves some form of scripting that contains configuration information and executes the necessary tasks to create the execution environment.
Automation is critical for consistency and scalability of deployment. It's important to monitor and log running applications in each step of the CI/CD process. The CI/CD toolset must be optimized for performance and scale.
Deployment Methods
Once you've moved an app into the deployment phase, it's necessary to select a deployment method.
There are multiple deployment methods for rolling out new software in the CI/CD process, depending on an enterprise's tolerance for the risk of disruption, the amount of time available to deploy, and other environmental intricacies. It's important that enterprises select CI/CD tools and infrastructure that supports the deployment scenarios required by the business.
To learn how to make CI/CD work for your business, download the ebook "Implementing Elastic CI/CD".
