DevOps CI/CD Automation and Integration Guide

Konstantin Kalinin

Head of Content

June 8, 2022

To many of us, DevOps CI/CD automation doesn’t exactly sound like the most exciting topic. However, if you grasp how CI/CD pipeline workflow functions, you’ll have a better chance of succeeding with your next software project.

After all, CI/CD development method is not exactly rocket science. Think of it as a combination of strategy and best practices that help you ship high-quality software faster. We’ll cover everything you need to know, plus a little extra.

Top Takeaways:

• The CI/CD delivery model helps software development teams automate and streamline many repetitive tasks required for creating applications.
• CI/CD is more than a single tool orchestrating code assembling and deployment. It’s a combination of DevOps best practices, culture, and well-integrated tools.
• CI/CD is not a 100 percent automatic strategy because, depending on a project, manual testing of UX/UI might still be required.

Table of Contents:

1. Introduction to CI and CD
2. Benefits of CI/CD
3. Common Misconceptions about CI/CD
4. Difference between CI and CD
5. CI/CD Pipeline Workflow
6. CI/CD Tools in DevOps
7. CI and CD Best Practices
8. Securing Your CI/CD Pipeline
9. How Topflight Can Help with CI/CD Automation and Integration

Introduction to CI and CD

Modern software is a complex thing. Long gone are the days when an app running on a phone was purely local code. Today, software consists of servers, cloud-hosted databases, multiple front-ends, and countless integrations.

Imagine an army of developers working on Gmail, for example. Some are responsible for the browser front end, others maintain the mobile apps, yet another team handles the back end, and a few more engineers zero in on spam, search, and a multitude of other features.

If all these developers didn’t practice CI/CD, we’d be still stuck with this early iteration of Gmail:

Fortunately, CI/CD allows us to enjoy the modern Gmail interface with all its smart features. We’ve also grown to expect more exciting features rolling out in our mailboxes regularly.

How does CI/CD fit into this? What does CI/CD stand for in DevOps? I suggest we start by defining the thing.

CI/CD is Continuous Integration and Continuous Delivery/Deployment — the crucial part of DevOps, responsible for seamlessly turning code into delightful user experiences. You see, when developers write lines of code, they don’t automatically appear as new features or bug fixes for users. There are quite a few hoops to jump through.

And that’s where the integrated CI/CD strategy comes in — to automate these intermittent steps in the application development process. Let’s break it down and discuss each C separately, shall we?

Continuous Integration (CI)

Continuous integration describes the practice of collaborative source code management. Continuous implies the process is ongoing and frequent, and integration means that different bits of code need to work well together.

Again, imagine several developers working on different features and bug fixes at the same time. How do they make sure that their changes don’t break existing functionality and don’t conflict with each other?

Continuous integration dictates that they commit these changes regularly, preferably on a daily basis, using source code management tools like GitHub or BitBucket. Some other tools, e.g., Jenkins, then pull these bits of code together, compile them into an actual app, and run tests to make sure everything works as intended.

Finding discrepancies between different code bases at later stages instead of using automatic tools for building (aka compiling) and testing the software would take too much time. 

Continuous Delivery (CD)

As for continuous delivery, we need it to automatically deploy compiled and tested software to a staging pre-production environment where more manual and automated testing takes place.

No software runs in a vacuum. There needs to be an operating system, certain libraries, settings, plugins, and many other things that together create an infrastructure.

So the practice of continuous delivery ensures that compiled software runs successfully in such a staging environment that mimics the live (production) environment. That way, a development team can sort out all bugs and issues before the changes reach customers.

Continuous Deployment

Continuous deployment is like CI/CD continuous delivery, only this time, the app is deployed to a production environment where customers get to interact with it. Plus, the toolset includes instruments for tracking different KPIs related to software performance.

If any issues are discovered during continuous deployment, the tools allow to pause the deployment process and roll back the changes.

Benefits of CI/CD

Software development companies practice CI/CD for a reason. This foundational pillar of DevOps does bring plenty of benefits to the table. What are those?

Faster time to market

First and foremost, continuous integration CI/CD practices result in faster software development. Simply because developers spend less time on manual tasks like building app files and verifying code consistency. Naturally, they get more time to spend on actually developing new features or fixing bugs.

As a result, customers receive updates faster, and in today’s turbulent markets, it’s not something to scoff at.

Reduced costs

Since less time is spent on routine tasks, thanks to automated tests and such, the cost of development goes down. Although, that’s something we can enjoy in the long run. Short-term, the cost is likely to increase temporarily.

First, you will need to spend time educating team members and nourishing the DevOps culture. Then, you’ll need tools and servers to orchestrate the whole thing. Fortunately, after a while, the gains greatly outweigh the initial costs of implementing CI/CD.

Better software quality

Finally, customers get to use a better app because it has fewer issues and keeps receiving updates at regular intervals. And as we all know, happy customers attract even more customers, which can’t be bad by definition.

Common Misconceptions about CI/CD

I think we should also touch on a couple things people tend to get wrong about continuous integration and delivery.

100 percent automation

Even though automating CI/CD simplifies a lot of things for developers and other team members, it doesn’t have to be automated 100 percent. This statement is especially true for complex projects where several developers may work on a large feature at once.

Here are a few things that still need to happen amid all automation:

• developers need to provide peer review of newly committed code
• QA engineers have to try and break software before customers do it
• product owners may need to approve the public rollout of certain features

Of course, a properly set up CI/CD pipeline won’t break the chain of automated tests with these manual interventions. I just want to highlight that code written by developers doesn’t miraculously travel through the whole CI/CD pipeline and transforms into working software on its own. Human intervention is still required at key points.

Continuous delivery equals continuous deployment

To many business owners, CD can mean either continuous delivery or deployment, and they may think it’s one and the same thing.

However, as already mentioned, continuous delivery is about making an app available in a staging (aka test) environment, whereas CI/CD continuous deployment is about making the app available to customers.

In that sense, continuous deployment goes one step further than delivery and marks the final stage in a CI/CD pipeline.

CI/CD is just one part of DevOps

While it’s true that DevOps is more than CI/CD alone, we can’t deny that the CI/CD pipeline is the essence of DevOps. Take away CI/CD, and there won’t be much left.

The best practices for automating source code management and its transformation into a working application are absolutely crucial to DevOps implementation.

Differences between CI and CD

So far, we’ve figured out that CI and CD mark different stages of DevOps, which in turn encompasses the whole software development process. Let’s focus on how CI and CD differ from each other.

CI always goes before CD

Continuous integration always precedes continuous delivery/deployment because, in order to deliver something, we first need to compile source code and get artifacts. Those are executable files that run in a test or live environment and manifest themselves as working software.

CD loops back to CI

Continuous delivery and deployment influence continuous integration by providing various metrics. For example, we can track build times, defect rates, and mean time to repair (MTTR). If some indicators are deteriorating, there’s a high chance that we need to reconsider our CI practices.

CI and CD may rely on different tools

Although it’s hard to find an instrument that doesn’t try to do it all, these days, CI and CD can still be powered by different tools. The CI toolchain has more to do with source code control, while CD deals more with solutions like Kubernetes and Docker orchestrators.

Not all results of CI get pushed to production

Please note that while all changes get accumulated during the CI phase, that doesn’t mean they all will be part of the CD. Development teams often use special flags to identify features as ready or postponed for a public release.

So even if some features have been approved at the CI stage, they may not reach customers until stakeholders are ok moving forward with them.

CI is more for developers, while CD is for QA engineers

As you already understand, CI/CD integration must be embraced by the whole team. At the same time, you can’t help but notice that CI is more relevant for developers and CD for QA engineers.

Of course, ideally, DevOps engineers oversee the whole process and ensure smooth transition along the way.

CI/CD Pipeline Workflow

Let’s review a typical CI/CD pipeline. As you already know, the pipeline exists to automate and streamline the process of turning pure code into a working application.

The source and build steps mark the CI phase. From source to test, we have continuous delivery. And the final step, production, belongs to the continuous deployment phase. Here’s what happens at each stage.

Source

The first phase is when developers check new code into a shared repository where other engineers can review and approve the changes. This practice is also known as version control.

Build

During the build phase, a dedicated software suite compiles source code from the shared repository into executable files; and then wraps them into a container image and deployment packages.

It’s at this point that code and application are tested with automated unit tests and build tests. Put simply, a series of automatically run tests ensure that all basic functionality of the application is working correctly.

Test

The next phase in the pipeline involves delivering artifacts we received from the build step to staging CI environments. That’s where more automatic and manual testing takes place. Operations teams run all sorts of tests here, including high load testing, integration tests, etc.

Production

Finally, all tested artifacts need to be deployed to a production environment, which means they replace the live app with an updated version. At this stage, we can also gather all DevOps metrics to optimize our pipeline if necessary. Fancy names aside, these metrics mostly track how fast we get from code to a working app and how quickly we can fix issues.

Note that we’re talking about a generic CI/CD pipeline. Different DevOps teams will rely on slightly different variations based on their project needs.

Example of a CI/CD Pipeline

Here’s an example of a typical CI/CD implementation:

As you can see, code versioning and control happen in Git. Later on, source code is compiled using GitLab and CodeBuild workflows, and packaged into a container image with the help of Docker. Finally, it’s deployed using CodePipeline and Kubernetes. Jenkins, in this example, plays the role of a central automation server, orchestrating all principal stages of the process, including automation support.

CI/CD Tools in DevOps

There’s no shortage of CI/CD tools on the market. Typically, you’ll see a combination of different tools that best fit a project structure and the type of application being developed. Some of the most popular names in the industry include Jenkins, TeamCity, CircleCI, and Travis.

All major cloud service providers, like AWS, Google, and Microsoft, offer their own suites of CI/CD tools. For example, you can pick from AWS CodePipeline, which includes CodeCommit and CodeDeploy, or Cloud Build by Google or Azure Pipeline by Microsoft.

As already mentioned, development teams usually create a custom toolchain for their DevOps processes using a number of CI/CD tools.

Code management tools:

• GitHub
• GitLab

Building and configuration tools:

• Maven
• Gradle
• Puppet

Testing:

• Selenium
• JUnit

Deployment:

• Docker
• Kubernetes

Monitoring:

• Splunk
• Nagios

Alternatively, some companies prefer to build their own custom CI/CD tools using open source solutions like Jenkins or stick with its 1000+ plugins. In the end, what matters is that everyone on the team is familiar with the selected DevOps tools, and they integrate well.

CI and CD Best Practices

What are some CD and CI best practices development teams should follow to guarantee a successful release of a product?

Frequent code commits

Ideally, developers should commit code changes on a daily basis. This way, it’s much easier and quicker to resolve any issues so common for any project. In addition, the development process becomes completely transparent for all team members.

Infrastructure as code

Software is not built in a vacuum. And to speed up the onboarding process for newcomers, it’s vital that all development, testing, and production environments can be set up and configured automatically, within minutes.

Notifications

The tooling that developers use to automate CI/CD steps has to support notifications that keep everybody up-to-date on any new issues and the status of code and application at any stage of development.

Secrets management

It goes without saying that modern software includes all sorts of private information that’s necessary for a correct functioning of an application. For example, passwords, credentials, and secret keys may be required during the testing phase.

An experienced development team would avoid including such data in code and instead would opt for using special tools like AWS Secret Manager. Such tools keep all secret configurations and exchange this data via a protected connection.

Consistency

All team members need to be aware of the standard toolchain for a project and stick to using the same tools in the same capacity. It’s completely inappropriate if, for example, an engineer working on a back end uses some random plugin for Jenkins and front-end developers don’t.

Build once

This best practice refers to the fact that all artifacts created during the build step should be only produced once. Furthermore, such artifacts (aka code packages) should be assigned a version number and stored online in a shared repository. This approach ensures no errors will be introduced at later stages.

Decide priorities for automation

The absolutely first thing to automate in CI/CD implementation is code commits and compilation. After that, the team should cover as many unit tests as possible, followed by functional, smoke, UI, and other automatic tests.

Securing Your CI/CD Pipeline

Leaving a CI/CD pipeline unprotected will lead to insecure software. It’s vital to manage security risks at all phases of the pipeline. This includes establishing access control, secret configuration management, and registry scanning, among other security measures.

Managing CI/CD access rights

It’s recommended that you provide only specific team members with access rights to the CI/CD pipeline on a granular basis. This prevents injections of malicious code into the development environment.

By practicing the principle of least privilege, we can protect the entirety of our pipeline and prevent hacking of our software.

Source composition analysis (SCA)

SCA involves scanning source code to spot potential vulnerabilities stemming from open-source libraries and other borrowed components. SCA tools usually kick in at the very beginning of the CI/CD pipeline, before code gets compiled, and inform about any unsafe dependencies in code.

Static app security testing

SAST often compliments SCA testing and focuses on custom code written by your team. SAST tools look for potential threats in code, e.g., incorrect input validation or the use of insecure connections for data transferring.

Registry scanning

Deployment scenarios often imply the packaging of code and other necessary components into containers. In this case, it’s recommended to perform automated testing of containers as they enter registries.

Since SAST and SCA testing go only through source code and can’t inspect any additional components (dependencies, etc.) from a container, registry scanning becomes crucial to identify any security vulnerabilities before deploying an application.

Runtime security

The goal of runtime security testing is to identify threats once the software has been deployed to a live environment. The combination of tools used for runtime security always depends on the specifics of your CI/CD pipeline, e.g., whether you use containers and what orchestrator manages them.

However, the process mainly has to do with inspecting software logs, audit logs, and network metrics to identify live vulnerabilities before they escalate.

How Topflight Can Help with CI/CD Automation and Integration

CI/CD continuous integration and continuous deployment are standard components of any project at Topflight. We usually integrate the CD and CI pipeline right from the get-go. However, we also offer CI/CD as a service and can help you introduce these DevOps best practices into live products. Here are some examples of the projects where we focused on DevOps and CI/CD services.

CruiseControl, a crew management platform.

As the client’s customer base continued to grow, it became crucial to overhaul the infrastructure and improve release lifecycles.

We were engaged to rethink the deployment strategy and build a high-performance multi-environment infrastructure inside the customer’s AWS environment. Our goal was to create a solution with a high degree of automation and performance. Long-term wins:

• improved the platform’s responsiveness on the global scale
• automated deployment of the cloud infrastructure
• enhanced the stability and reliability of the cloud infrastructure

Skyline, a platform for lien search.

The app offers compute-demanding features such as PDF generation and image processing and connects to multiple APIs to sync the lien data. The project maintains a multi-environment setup with development, testing, and production on AWS.

To dynamically escalate application workload while keeping optimal performance and intending to switch to a more modern, cost-effective architecture, Skyline decided to move their whole cloud infrastructure to serverless. Long-term wins:

• reduced monthly hosting costs by 60%
• development/debugging time reduced from weeks to hours
• improved the app’s availability and performance

If you have any questions about continuous integration and continuous delivery (CI/CD), please schedule a call with our experts. And remember that today, CI/CD DevOps is not a fancy practice, but a must for any successful project.