How to speed up your CI/CD pipeline

The modern market is a hypermodern environment, constantly changing and constantly growing. Every day, thousands of new competitors are created around the world, transformative technology shakes industries to their core and new paradigms are paving the way for doing business.

In this context, fast deliveries are more important than ever and customers want their projects to meet the demands of a competitive market that is advancing at breakneck speed. Continuous Delivery and Development (CI/CD) is a popular methodology that seeks to do just that, automating the development process and creating a constant cycle.

But even a method designed to speed up your development cycle can have its fair share of bottlenecks, and that's what we'll talk about today. What can we do to optimize our CI/CD pipeline.

Build only what you need

It can be tempting to try to push as much as possible into each commit, but building five different modules or services at once can often lead to more trouble than it's worth.

A good policy is for each commit to be like a good email, short and to the point. Even projects based on monolithic architecture have a lot to gain by adhering to one module at a time.

Focus your efforts on what is absolutely necessary, prioritize and keep it simple. Massive commitments can often act as bottlenecks due to code reviews, QA, and testing. If 99% of the code is perfect, but a single line raises a flag, the rest of the code may get stuck in the process while the bug is fixed.

If this sounds like someone selling microservices architectures, well, that's exactly what it is. While monolithic approaches have their own strengths, generally keeping everything micro and compartmentalized will save a lot of time in the long run.

Avoid making too many feature changes at once

A little continuation of the previous point. Resource changes are necessary, but at the same time, they pose a risk. From a software development perspective, with each feature change we run the risk of buggy our code or introducing unintended consequences.

From a user perspective, too many changes can confuse the end user and it is more difficult to assess which changes are working and which are not if they are all introduced at the same time. Even worse, you run the risk of one nasty change ruining the entire update, as people tend to generalize bad experiences.

As with building new modules, if a feature fails testing, the rest of the features should be put on hold while you find the culprit. To make matters worse, the more you've changed, the harder it will be to find the source of the problem.

It's worth repeating, the best way to avoid this type of bottleneck is to think small, one change at a time keeps things organized and is easier to handle for the entire team.

Run jobs in parallel

CI/CD pipelines can save a lot of time when used correctly, but just like a pipe, they can only handle so much. After a certain threshold, the continuous cycle collapses and a bottleneck is formed.

For those who are not very experienced in software development, the most common build steps are performed sequentially. In other words, each step is executed alone and only happens after the previous step is completed.

Sometimes we can divide the process into individual steps and execute them at the same time, this is commonly known as parallel or concurrent execution. Five jobs that take one minute to complete would take five minutes to complete in sequence and just one minute if run in parallel.

Obviously, not all work can be run in parallel, nor is it necessary. Some jobs are fast or efficient enough to handle the workload. Other jobs may require more time and resources, and in these cases, the process can be accelerated by creating other instances to run together.

Cache, Cache, Cache

Artifacts from previous CI/CD versions can be reused during new cycles. For example, a package or container required by your application can be used in subsequent cycles.

To avoid having to download or completely rebuild your resource pool for each cycle, you should cache everything and reuse it whenever possible. There are fantastic tools for this type of task, such as Artifactory.

By reusing resources you already have on hand, you can significantly increase the speed of your CI/CD pipeline. At the same time, you reduce the risk of problems arising from compatibility issues in the future.

While caches are useful, they shouldn't be used forever. It's important to delete their cache when you update them or when they are no longer needed, to avoid confusion in the future.

Use Canary releases

Some DevOps teams release preview versions to a small subset of users and collect feedback before fully committing to a release. Canary releases can help you collect useful data about your changes without exposing your entire user base to potential bugs or issues.

Large development teams can even create different canary releases, each targeting a different subset of users. This way, different changes can be evaluated in parallel and possible problems can be detected more easily.

For example, if you have three sample user groups, A, B, and C, and group A is reporting a bug, you know something is happening specifically with that canary version. This way, it is easier to trace the source of the problem.

Analyze your pipeline

We saved the best for last. We cannot emphasize how important it is for a team to constantly monitor their CI/CD pipeline. Measure how long each cycle is taking and look closely at which jobs are taking longer.

Is time being used on high-value steps? If that's not the case, what can you do to reduce the total time or rearrange your steps?

Are there long steps that are not adding value? Why are they in place? Can they be removed safely?

By understanding your own pipeline, you can make better decisions about how to increase the speed of each cycle. Remember that designing a CI/CD pipeline is an iterative process. You should keep working on it and constantly monitoring it to find areas of improvement.