How do you configure your CI server?
Most people configure their CI server using a web based UI. You can confirm this by searching for "setting up Jenkins job", "setting up TeamCity build configuration", "setup ThoughtWorks Go pipeline" etc. The results will tell you to configure the appropriate CI server through a web based UI, probably with no mention that this is not the only way.One of my serial ex-colleagues, Nick Pomfret, describes using these web based UIs as "clicky-clicky". In this article I will use the Jenkins term "job" (aka "project") to also mean TeamCity build configuration or GoCD pipeline. In this article, I'm calling GoCD a CI server; get over it.
What is wrong with clicky-clicky?
Clicky-clicky can be useful for quick experiments, or maybe if you only have one job to set up, but has some serious drawbacks.It works - don't change it
Once a job has been set up using clicky-clicky, one problem is that it is difficult to manage changes to it. It can be difficult to see who has changed what, and to restore a job to a previous configuration. Just version controlling the complete CI server configuration file (which some people do) does not do this well, because such files are difficult to diff, particularly when there are changes to other jobs.Lovingly hand crafted, each one unique
Another problem with clicky-clicky is when you have a lot of jobs that you would like to set up in the same way, clicky-clicky is both time consuming, and inevitably leads to unintended inconsistencies between jobs, which can cause them to behave in slightly different ways, causing confusion and taking longer to diagnose problems.Can't see the wood for the tabs
Furthermore, web UIs often don't make it easy to see everything about the configuration of a job a compact format - some CI servers are better than others for that.The right way - scripting
If you script the setup of jobs, then you can version control the scripts. You can then safely change jobs, knowing that you can recreate them in the current or previous states, and you can see who changed what. If you need to move the CI server to a new machine, you can just rerun the scripts.In some cases a script for setting up a job can be much more readable than the UI because it is often more compact and everything is together rather than spread over one or more screens.
Fully automated configuration of jobs
It can be very useful to script the setup of jobs so it is totally automatic; i.e. when a new project is created (e.g. a new repo is created, or a new directory containing a particular file, e.g. abuild.gradle file, is created), then a job can be created automatically.
If you take that approach, then it saves time because nobody needs to manually setup the jobs, it means that every project that needs a job gets one and none are forgotten, and it means that the jobs are consistent so it is easy to know what they do.There are some subtleties about setting up fully automated jobs which I won't go into here - maybe a future blog article.
Tools for scripting
For GoCD, see gomatic. For other CI servers, please add a comment if you know of anything that is any good!Copyright ©2015 Ivan Moore
3 comments:
The job-dsl plugin for jenkins allows you to use a groovy-based DSL to reproduce environments.
"Store project settings in Version Control" is in TeamCity 9. Alas no svn support as yet...
Team City 9 changes
I'm currently looking at Ansible to script our CI environment including Jenkins (https://github.com/bbc/ansible-playbooks). It's taken far longer than it should have because of the assumption by the tool's developers and it's community that "clicky-clicky" is the way to go. The job-dsl plugins gets you some ways but theres a whole load of other configuration that resists automation.
Post a Comment