Skip to main content

Microservice Continuous Integration – Where’s the Build?

Microservice Continuous Integration is not the same as our old CI ‘check-in and build’ process. Not even close. We started down the Continuous Integration path to solve the “really big build” problem.  Builds that ran for hours required a new approach, and so CI was born. Well, with microservices, we don’t have builds that run for hours; in fact, there may not be a compile/link step at all.

With microservices, you must think “functions.” Microservices are functions written in a few hundred lines of code, not thousands, using languages like Python that is interpreted (no compile needed). Even if a language like GoLang is used, and a compile is required, it is minuscule compared to the days of C++ or C#. In other words, a microservice continuous integration most likely will have NO compile step. In addition, microservices are loosely coupled, so NO link step is required.

In our monolithic CI/CD process, source code is checked out intermittently.  The build executes in a ‘build directory,’ and linking is performed. Linking pulls in external libraries that are needed by references defined in the source code or by the run-time environment.

In really smart shops, a software bill of material (SBOM) is created to validate the contents of the build. All that goes away with microservices. In microservice continuous integration, the complete business of running a monolithic build is disrupted to a point of non-existence.

The Continuous Integration Shift

With microservices, we shift the important step of the software configuration management process (creating the monolithic binary) from the development side of the house to the operations side of the house.  While I would like to say that there is no such thing as a continuous integration process with microservices, I know that statement will cause some techies to just flat out disagree – yes, we do ‘build’ a container image.

But that is different. The important understanding with microservices is that we are no longer managing a binary with all of the linking sorted out. Decoupling is the core of a service-based architecture. This fact changes the purpose of a traditional CI process.

microservice continuous integration

The Shift: microservice configuration management is no longer done at version and compile. It has shifted to run-time.

Re-thinking Continuous Integration

In your microservice approach, you need to rethink what microservice continuous integration means.  If we stick with the CI basics and pinpoint a feature of traditional CI that continues to be important with microservices, you will find ‘software configuration management.’ The challenge is to re-think where and how this step is done.

We still need to understand the configuration of our ‘logical application’ and we require the tracking of application to service dependencies. Yes, these basic features of CI are still important in this new modern architecture.

In many ways, these features of microservice continuous integration are more important. Because our microservices are immutable, meaning unchanging, you could have multiple versions of a microservice running and consumed in production simultaneously by different sets of users.

Managing the configuration of microservice versions to application versions becomes a challenge. This is exactly the same as our traditional build process. In the old build, we defined what versions of libraries would be linked into our binary. Some build experts would refer to this as ‘packaging,’ which is still important.

DeployHub and Microservice Configuration Integration

With microservice continuous integration, we seem to be throwing out the bathwater, but we want to keep the baby. DeployHub provides a method to perform an initial ‘packaging’ of your serviced-based applications to manage configurations. DeployHub does this through blueprinting. The blueprinting process involves defining the ‘baseline’ application version with specific versions of microservices.

If you integrate DeployHub into your CD pipeline process, our platform will automatically update your application version each time a microservice consumes has a new version available. So each time a new container build is performed for the microservice, DeployHub tracks the new version of both the microservice and the consuming applications.

In essence, DeployHub creates an SBOM that tracks all changes and relationships over time. DeployHub provides visual maps of the relationships between deployed application versions to deployed microservice versions and dependency reports.


While we are starting to move away from executing long builds as part of our continuous integration, there is still a process for microservice continuous integration. At the core is microservice configuration management. DeployHub’s microservice catalog tool supports your migration to microservices by providing a central hub of deployed microservice information that tracks the configuration of application versions.

While this information is lost when we stop doing traditional builds, DeployHub finds and keeps the configuration data and supports it through your CI/CD process.

Further Reading:

DeployHub Solutions: