Paul Hammant's Blog:
Branchable Continuous Integration
Most folks know that I like trunk-based-development, with branches made in advance of release.
Less well known is that I like my Continuous Integration configuration to be under source control too.
I’ve spent a lot of time in Jenkins recently configuring job, then copy-pasting that (after multiple clicks to navigate around) into similar jobs.
I would really like to be able to do all of that in Intellij, and just commit atomically, possibly in the same commits as regular changes. I’d also like to be able to make branches and push them to within the visibility of the CI master daemon, and it provision the implicit pipelines from that commit automatically.
What that means for me is that the CI tool should watch all commits, and be able to recognize its configuration files amongst the commits (new, changed and deleted) and reconfigure itself before it leaps into action to process the particular commit(s).
Cruise-Control was close in a bygone era. Indeed, I remember working with Paul Julius in 2005 to rework the XML-Include capability to be resilient to botched edits. That last would mean that the reconfig would not take down a whole pipeline if one dev forgot an angle bracket.
I wish the modern CI tools could be configured completely using commits, including new pipelines.
Updates
Nov 2013: Branchable CI with SnapCI blog entry from me.
Jan 2015: Ivan Moore talks up CI configuration under source control too.
Published
Syndicated by DZone.com
Reads:
Categories
Comments formerly in Disqus, but exported and mounted statically ...
| Fri, 30 Sep 2011 | Roger Almeida |
I have just one question: Is Go able to do it? | |
| Sat, 01 Oct 2011 | Jez Humble |
You can make Go do this. Simply create a pipeline that monitors version control where you check in your new configurations, and then have a little script checked in that merges the relevant configuration into Go's XML configuration file. Go monitors its config file on the filesystem every few seconds, and will pick up changes and dynamically reconfigure itself. Note that as of version 2.1 Go has jgit embedded, and versions its own configuration. You can see Go's configuration as it was when a particular stage was run (see the documentation here: http://www.thoughtworks-stu... ) There is also a RESTful API for managing Go's configuration, including seeing historical versions and updating, which is documented here: http://www.thoughtworks-stu... | |
| Sat, 01 Oct 2011 | Vraravam |
Yes - Go has that capability - which actually is a double-edged sword. But, on the whole, I would still prefer it to be managed in some SCM. What I meant by "double-edged sword". In typical deployment environments, you would have your code, your CI tool, your environments inter-twined with a process to make the whole deploy happen. (Continuous Delivery is a good practice, and I agree whole-heartedly with doing it - but have never seen it work completely ALL the time.) Having versioning for your CI (so as to be able to deploy a particular version of the code) - with the tooling at that [past] time, is what is the goal. But this breaks down very quickly if some other piece of your process/toolchain has "moved on" - usually not having backwards compatibility. Am I going on a tangent here? | |
| Mon, 03 Oct 2011 | Jim Bob |
typo alert on title "banchable" | |