CI/CD: It’s a Culture, Not a Feature

How CI/CD can be scaled up to make our code more dynamic yet more reliable while saving time

What is CI?

You probably already know that CI stands for Continuous Integration, but what exactly are we integrating?

From Wikipedia:

In software engineering, continuous integration (CI) is the practice of merging all developers’ working copies to a shared mainline several times a day.

This practice saves us time and effort because the longer the development continues on a branch without merging back to the main repository, the greater the risk of multiple integration conflicts and failures when the developer branch is eventually merged back.

When changes are merged to the main repository, automatic tests are being run to ensure that these changes do not break functionality, and that our code is still stable. This automation allows us to detect conflicts early, thus saving time.

I suggest that this practice can be scaled up. Not only can we continuously integrate changes in our own code base, but we can continuously integrate changes in other code bases on which we depend.

Dependencies, dependencies, dependencies

During code development we may depend on a plethora of different dependencies: a compiler, an interpreter, IDEs, test frameworks, linter, etc. In addition, let’s not forget about code dependencies. You must agree that sometime our code development may seem like building Lego made up of third-party code libraries.

New versions of said dependencies come out all the time by their developers. When developing code over a period of time, we can benefit from continuously integrating those new versions with our code:

• sometimes this can reflect in performance improvements;
• in other times new features can be published which would ease our own code development;
• in better cases tiresome bugs are attended and fixes;
• and in the best case, we avoid losing support as certain versions can become deprecated. This is no joke — as critical security flaws could be discovered and never fixed.

As long as we refrain from upgrading our dependencies, we’d have to deal with more conflicts and failures just like if we delay the integration of our changes to the source code.

In other words, we should be continuously integrating the latest versions of our dependencies in order for our code to be more feature-richer and more stable.

Automation

As said in the introduction, when a change is made to the code base, tests are being run automatically to validate the integrity of the product. We can also run these tests when a new version of one of our dependencies is released.

We can also automate the process of packaging our product into an artifact which can be delivered to our user.

Continuous Delivery

Continuous delivery is an approach in which teams release new versions of their software in short cycles.

When a change is made to our code base — containing a feature or a bug fix — we’d want to release that change to our users as fast as possible. This allows us to gain feedback from the users about the change more quickly, which lets us focus our development on the next change.

That said, of course, regardless if our product is aimed for an end-user or a tool/library for other developers. If the latter is the case, that other developer could be you!

That operation can be automated in such a way in which we release a new version of our code automatically each time our CI infrastructure concluded that our code has passed all the necessary tests — validating that our code is ready for delivery.

One for all, all for one!

Implementing both CI and CD in our product allows our users to get the latest features or bug fixes which helps us learn how our changes were accepted, but also helps them with their development, as they get our latest improvements.

Likewise, if each one of our dependencies would implement CI/CD, we’d benefit as well, as we get their (and their dependencies’) latest improvements.

So, if everyone were to continuously integrate better tools, improved their own libraries, and continuously deliver their upgraded products, everyone in the chain would benefit.

Conclusion

Implementing CI in our projects saves us time and effort by reducing the time needed to integrate new changes to our code.

Expanding on that notion, we may as well continuously integrate newer versions of our dependencies, allowing us to always work with their best version of the product.

Using continuous delivery for an automated release of your software is a good idea too: we’d benefit from faster feedback which will focus our development on the needs of our users. Also, our users would benefit as well by getting the latest, most improved version of your product.

A good CI/CD infrastructure benefits everyone in the chain of development — making everyone’s code more reliable and stable yet still very dynamic for changes.