A Tale of Two CI Systems
A Tale of Two CI Systems
Having used Bamboo and Travis CI, it is clear that both systems achieve much the same result, but do so in significantly different ways, and one is a clear winner.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
My day job revolves a great deal around Bamboo, Atlassian’s CI system. It builds code, deploys apps, runs tests, and is an integral part of a development process that demands repeatability and consistency.
Both systems achieve much the same result but do so in significantly different ways.
Bamboo, and other CI systems like Jenkins, provide a separate system that treats your codebase as an input that is configured as part of a build process that is completely self-contained inside the CI server. All configuration of and interaction with the build process is done inside the CI server, and your code base has no concept of the CI system being used.
Travis CI takes a different approach by providing a very bare user interface and defining the build process in a configuration file checked in as part of the project’s source code. The CI server itself presents a few options for defining variables and monitoring the progress of a build, but the vast majority of the configuration exists inside the project being built.
Having real world experience with the two systems, I must confess that I find the configuration based approach of Travis CI much more enjoyable to use for two main reasons.
Because the Build Configuration Is Version Controlled
You already know how to use GIT. You know how to branch, merge, look back through the commit history and manage security in GIT. And in Travis CI all of that knowledge is immediately applicable to your CI configuration.
How do you look back through the history of a build configuration in Bamboo, or secure projects or copy configurations between projects? You need to know the Bamboo process for any of these tasks, and the processes don’t inherently share any concepts with the way you have already been managing your version-controlled code repositories.
There is very little to understand about how a Travis CI build configuration is managed because Travis CI doesn’t manage it. If you already have a version control process in place, then you already have a Travis CI configuration process in place.
Because the Build Configuration Is Put Back in Developers' Hands
The problem with centrally managed services like Bamboo is that they fall into the trap of providing facilities for the lowest common denominator. This is not because Bamboo itself isn’t capable of an incredible range of processes, but because any black box managed by people who don’t gain anything by investing the time to tweak processes and manage incremental improvements will naturally stagnate once it provides a baseline that is good enough.
With Travis CI, the burden of writing, debugging and maintaining the build configuration falls back on the developer. The CI system provides a wide range of capabilities and the guarantee that your build won’t break anyone else’s. You write it, you build it, you deploy it. Travis CI removes the barriers to the kind of incremental improvements that can only be implemented when the people who have the most to gain are given the ability to put the improvements in place.
If I had to do it all over again, I would definitely implement a CI system that placed configuration inside the codebase that it builds rather than maintaining it in a separate system. Travis CI has proven to be quite easy to use, and the upcoming Atlassian Pipelines shows promise as well. It is just so much easier to maintain a text file in a GIT repo than custom project configurations exposed by a web based UI.
Published at DZone with permission of Matthew Casperson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.