Back in 2006 Jenkins was all I knew.
In the beginning of my career I was glad that something was doing my job for me!
Wait, so you are telling me that this Jenkins guy is just going to sit there waiting for me to push a button so it can build my code?!
What else do you want from a building system? right?
All CI systems are the same.
✓Fancy UI — They were fancy for 2006
✓Point and click configuration — What could go wrong? I’ll remember all this settings forever!
✓Top secret code production behind a username and password — No one will guess my P4sswOrd
✓Takes less than a day to install — I don’t really remember how long I took to install my build system for the first time
Not all CI systems are the same.
A few years go by and it became an odd affair where I tried other solutions like TeamCity, Bamboo and CruiseControl and kept coming back to Jenkins or Hudson (when it had an identity crisis).
For the most part Jenkins always had my back but it’s only when it goes wrong that you start asking tough questions:
- How am I going to replicate all these job settings?
- What are the actual steps to install slaves?
- Should I update the plugins, heck even Jenkins itself, and risk a few hours/days of fixing tools or keep ignoring security threats or buggy plugin runs?
- What do you mean there’s no space on the master?
- Why are the slaves offline?
If you are lucky, some of these questions will come up during your sprint and not when you are already late trying to deploy your stuff.
If you are really lucky you’ll have someone to worry about these things (and enjoy it o.O ) while you can sit back and code.
Less turbulent times ahead!
Fast forward to August 2014 and concourse is released for the first time. Concourse is a wonderful proposition albeit a bit green still.
I won’t justify the above claim that the system is not yet fully matured because:
- I do not want to influence you not to try it since you may not even need the things that are not yet available in concourse.
- I do not want to ‘date’ this post unnecessarily by claiming that it does not support X and when you read it in t(x)+25t (ie when cars fly and shopping in Saturn is so yesterday) it already does all of that.
Go try it! seriously, go… I’ll wait and as long as you
I won’t even mind you not finishing the rest of the post.
Yet another build tool ?
Concourse’s cheeky concourse vs page faults *all* other CI systems and, even though, while reading it, your Stockholm Syndrome will kick off in defence of your beloved CI system, if you breathe deep a couple of times you may start to agree with its proposition.
They are all broken by design and we never really seen it!
Why are we complacently using the same broken systems day in and day out? Well I don’t have all the answers … OK I’m lying, I DO have all the answers! We use broken systems because we are being paid to develop / have more interesting things to develop other than our tools!
Have you ever seen a mechanic taking care of his jack? or a builder encasing his hammer? of course not. They expect their tools to perform day in day out and when they don’t they rush to the shop to replace their trusty friend for a new one. We do the same thing except that we have to down tools and fix our building tools.
One of the best dev ops / app ops engineer I've worked with pointed me towards a post that I will cherish forever. Even though this was written in November 2011, its content was as up to date then as it is now.
If you attempt to put into practice all the steps in that article, you’ll soon realise that concourse developers must have read the same things that Adam Wiggins did, or maybe they just all think alike ;)
Of course nowadays none of those steps are new but we never really had a CI system that enforced and encouraged all good practices for building your code.
Well that was true until we had concourse. Long live concourse, death to other CI systems! One CI system to rule them all!
