As developers, we’re always looking for ways to take our customer’s problems and turn them into solutions, and sometimes it can take a painfully long time to deliver those solutions. We might have multiple steps involved in the release process or only do a few releases every year, and that can slow us down. What we need is a process that allows us to deliver changes quickly and without a lot of overhead.

In this article, we’ll discuss how to use continuous integration paired with continuous delivery and maybe even mix in a little continuous deployment as well to speed up delivery.

What is CI/CD?

Continuous integration (CI) and continuous delivery (CD) or CI/CD for short, is a software engineering process that allows teams to streamline processes, improve collaboration, and deliver high-quality software at a faster pace.

The “CD” in CI/CD can refer to either continuous delivery or continuous deployment, which are related concepts that sometimes get used interchangeably when discussing this topic. For this article, we’ll use CD to refer to continuous delivery.

CI/CD involves some or all of the following processes:

• Continuous Development
• Continuous Testing
• Continuous Integration
• Continuous Delivery
• Continuous Deployment
• Continuous Monitoring

We’ll talk about these more later in the article.

Why Use CI/CD?

In a non-CI/CD environment, there is usually a gap between the development of the software and the deployment of that software. Sometimes those two processes are handled by two completely different teams. CI/CD removes this gap by enforcing automation in the building, testing, and deployment of our code. To do this we’ll have automated tools that will verify our code, package it for deployment, and then deploy it.

CI/CD aims to increase defect discovery, increase productivity, and provide faster release cycles. In some environments, this can mean weekly releases, and in others, it can be daily or even hourly. At my day job, we release multiple times a day.

How Can We Do CI/CD?

Now that you’ve seen the benefits of CI/CD. You might be wondering how you can bring CI/CD to your team, and that can be done by creating your own CI/CD pipeline.

A CI/CD pipeline is a series of steps, either manual or automated, that must be performed to deliver a new version of the software. This pipeline will enact continuous integration, continuous delivery, and continuous deployment with one or more steps for each piece.

The pipeline I’m about to outline is not the only possible pipeline but it is the one I like to suggest PHP-based teams use to gain the most benefit from CI/CD. You’ll have to determine which parts make sense for your team and which ones don’t but I highly recommend using them all.

Continuous Integration

The first step in our pipeline is implementing Continuous Integration (CI). CI is a process by which we make frequent merges of small changes into a “main” (or “trunk”) branch. This is in contrast to making just a few large changes to that “main” branch. The idea is that it’s easier to identify defects and other software quality issues on smaller changes than on larger ones developed over an extensive period.

For example, I’ve worked on changes that have had thousands of lines of changes and been weeks worth of work. When the change reached the pull request review stage, the developer in charge of the review couldn’t easily review everything so it took a long time to get everything reviewed, there were a bunch of merges conflicts I had to manage, and lots of bugs snuck through the process. By breaking that one large change into dozens of smaller changes of about a hundred lines or less it was easier to review, and find errors, we were less likely to run into merge conflicts, and we could easily locate which merge caused new errors on our servers.

When we take this approach a little more planning needs to be done because our goal is to always have shippable software and we can’t create a form that doesn’t have the backing logic and we can’t create the backing logic if we need to add a column to the database. So we need to make sure we’re working in the correct order.

If you have a change like this where one change builds on another you’ll need to be prepared to have multiple PRs that build off each other. It adds some non-trivial overhead to managing them but the ease of the PR process should be expedited because of how quickly they can be reviewed.

On our team, the workflow for this works like the following.

First, we check out the main branch and then pull down any recent changes. This will make sure we have the most current version of the branch so we will have fewer conflicts when we’re ready to merge them in. From this branch, we’ll create a new branch based on the name of whatever feature we’re developing and do our development work. When we’re all done with the section of the work we’re doing we’ll push it up to a system like GitHub, BitBucket, or GitLab.

This brings us to the next topic we need to cover which is “Continuous Testing”. Because the overarching objective of CI/CD is to deliver quality code and applications we need to be continuously testing our code both during development, before it’s integrated into the main branch, and after every change. This can be a challenge to do manually so we always want some kind of automated tests to verify its correctness.

This is a case where you want to throw everything and the kitchen sink at your code to make sure it’s valid. You’ll want to do dynamic testing with tools like PHPUnit and Selenium as well as static code analysis with tools like PHPStan and PHP CodeSniffer. We want this to be as automated as possible so it’s best to use whatever solution your hosted Git allows. We have a article on how to set up GitHub Actions specifically about using it for automated testing.

Once all the automated tests have passed we can send the PR to another developer for review. Once they’ve approved the changes we can move on to the next main stage of this process.

Continuous Delivery

The next stage of the CI/CD pipeline is the Continuous Delivery stage. Because we spent all that time up front testing our change we can easily merge our change into the main branch and know that we have code that can be deployed to our customers with less chance for serious bugs. For most teams, this just requires us to have the original developer merge the changes into the main branch but you might have a dedicated person or team for this.

Once the changes have been merged in there are several options for what could happen and it depends on how your application needs to be deployed.

The first is that the deployment of the software may be initiated manually by your operations team. If your team, is deploying manually the process should be as automated as possible and it should be possible to do from anyone’s computer. I once worked on a team where one person had access to the software required to deploy our software. If he was not in the office for the day we couldn’t release a new version of our software.

The next is that we might “hold” those changes until we’re ready for a release. If you’re writing desktop software or software that requires a lot of manual testing before it’s released this might be how your team operates. I once worked on a web application that was developed like this. We had 4 yearly releases and there was always stress in the month before we feature-locked the release, in the month that we were testing the release, and then there was usually an onslaught of new tickets after the release. It made it an incredibly stressful environment.

The third option is to release the software without any additional people or delays. That’s where “Continuous Deployment” comes into the picture

Continuous Deployment

When we’re using Continuous Deployment (another “CD” I know) to deploy our software, we automatically release a developer’s changes into production so it can be usable by customers. This ensures our software updates are fast and can be reliably deployed to our production environment. Because it’s a small change and not a huge bundle of them we can see how the single change affects our code and it reduces the stress level because there’s less than can go wrong and we can quickly roll back the change or fix any bugs that are found.

This is how I deploy my software because the automated tests and checks give me the confidence that I didn’t introduce a bug or break some existing functionality.

There are a lot of software options that will help you execute Continuous Deployment especially because it’s so dependent on the infrastructure that you’re using. It can be as low-tech as a script that can be called through a webhook that just runs the steps required to update the code to something as complex as a solution that rolls out a new Docker image to a series of servers over a few hours.

If you’re looking for something that’s low complexity I suggest you look at our article on using Deployer to deploy your PHP code. It’s an excellent beginner’s solution for basic setups.

Continuous Monitoring

The final concept we’re going to discuss today is “Continuous Monitoring”. To ensure the health and performance of the application as a whole we need to use continuous monitoring tools. They provide insights into metrics like response times, error rates, and resource utilization, which allows us to quickly fix errors before they become a serious problem in our application.

There are tons of these tools that your team will have to pick from but I highly recommend you find one that will group errors so errors that have a higher frequency are brought to the top. It should have a way to track when a release happens so you can more easily track what release caused the problem to make it easier to locate the change that caused the error. I also like to have it so it can pipe the issues it finds into Jira or whatever issue-tracking software you’re using.

We’ve been sponsored by HoneyBadger in the past and they provide an excellent solution for error handling.

What You Need To Know

• CI/CD is a process to quickly take ideas into production
• Should be automated as much as possible
• Can automatically deploy our software as well