This article was written in collaboration between Uri Scheiner and Dinesh Garg.
Traditional CI tools (like Jenkins, for example) are designed in a way that forces the user to make sure that the clients (from which the steps are being executed) contain all the libraries that are needed for the step to run. For example: if the step is executing an HTTP request, an HTTP client must be installed. If the step is deployed to a K8s cluster, a kubectl is needed, etc.
This architecture is difficult to maintain. A large implementation of CI can easily get out of control for several reasons:
This is a nightmare for every CI team, which leads to a lot of time wasted, failure, and mainly frustration.
Fortunately, Harness CI is designed differently. Harness CI is container-based, which really takes away all the burden of managing libraries in slaves and gives you full control and visibility of which libraries and CLI are needed in every execution.
Let’s see what happens when you author a CI pipeline in Harness.
After you add a build stage to your pipeline, you can start adding the steps that will get executed when the build is triggered.
For each step, there are only a few things you need to define:
And you’re ready to go!
When the pipeline gets executed, Harness manages the complete lifecycle of each of these steps:
As the containers are ephemeral and immutable, you don’t have to worry about updating the libraries. If you want to use a new version of a CLI, just set the step to use a different image. Interested in using different versions of the same library? Simply specify the tag of the image to pull at runtime.
In order to save on resource consumption, Harness seamlessly determines the optimal pod specification based on your pipeline configuration. For example, in the screenshot below, the memory and CPU allocated would be done as follows:
Max (S1, S2, {S3+S4+S5})
Max (2GB & 1CPU, 3GB & 1CPU, {(4GB & 1 CPU) + (2GB & 1 CPU) + (2GB & 1 CPU)})
Max (2GB & 1CPU, 3GB & 1CPU, 8GB & 3 CPU) -> 8GB & 3CPU
You should use a container-based CI solution if:
In this article, we learned about container-based CI tools and how they differ from a traditional tool like Jenkins. The world truly is heading towards container-based architecture - just look at the bulk of CI/CD tools out on the market now. Most are cloud-native, and old tools like Jenkins (at over a decade old) simply aren’t the way anymore. We highly encourage you to try Harness for yourself and see how simple CI can be.
If you’d like to do some further reading on CI, why not read about Test Intelligence? This new feature is designed to save you shiploads of time - move fast, without breaking things.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.