Moving to the right tool isn’t easy, is it?
Most of us go through a similar process when starting out on a new project: meet the team, meet the tools, the process, the objectives; but as DevOps/CD/automation practitioners we instinctively start looking at areas of inefficiency, optimisation, can we go faster?! This often leads to us suggesting tools that we’ve previously used, favour highly and want to introduce, so that the team can realise the same benefits you’ve previously experienced.
So, if we assume that all recommendations are slightly biased based on one's experience, and people have different experiences, is it possible to get consensus to change tools, which is often costly and painful?
Having listened to a client prioritize shorter cycle time, more stable releases and clearer deployment visibility, my team recently started a journey. We are moving from the Continuous Integration (CI) tool, Jenkins to the Continuous Delivery tool, Go. I’ve failed at changes like this before, often attempted without proper appreciation of the consequences: a chain reaction of events that ensues for (sometimes) years to come. I’ve found that more work is needed than simply making a recommendation and acting on it: no matter how obvious the decision to switch tools may seem, doing comparison due diligence saves you a lot of effort (read: pain) later.
What is Go CD?
Go has grown up a lot, from it’s original incarnation as the Cruise Control CI tool in 2000, to a paid-for ThoughtWorks Studio product Go, and now as the current open source tool Go CD (to avoid any confusion with golang, or that ancient Chinese board game played by really smart people). ‘Deployment pipelines’ are a first class concept. A concept that now has a community supporting it which takes concerns like parallelism, visualisation, and end-to-end traceability very seriously. Deployment pipelines as a concept considers the start of a pipeline to be a code change, and the end, a deployment to a customer facing environment like production.
Marketing as code?
The perception of bias increases when your company had a hand in the evolution of the tool they are suggesting. If financial gain were involved then a case could be made for ulterior motives, but now Go is free I can only speculate on why... a conspiracy to embed ThoughtWorks branding? I’m cool with Infrastructure as Code, but Marketing as Code (copyright pending) is an interesting accusation.
>> “We lose others respect as tool agnostics, when we consider consuming our own dog food.”
Other people suffer from bias speculation. Marco’s early 2014 blog post is still the most hit Jenkins vs Go resource, but continues to be met with suspicion due to his ThoughtWorks Studios tenure. We lose others respect as tool agnostics when we consider consuming our own dog food. Not invented here, anyone?
Unfortunately there is little else out there by way of comparison. Some of this is because the Jenkins community regularly pushes out plugins that bolt on elements of functionality and change the parameters of a comparison.
Take it into your own hands
On my team we installed Go to pilot and demo the Value Stream Map visualisation. Although this alone was not enough to change a tool as embedded as Jenkins, we started to look at other areas of inefficiency where Go could offer value. We worked in parallel for two months - adding and modifying a pipeline in Jenkins, then proving we could do the same thing in Go - but see a more coherent view of code promotion. But this was wasteful duplication and we needed to either drop Go or make a stand for it’s benefits.
Fig1. Go Value Stream Map showing final Prod deployment with traceability back to all VCS repo’s, and fan-out:in capability.
Step 1: To be agnostic you must be transparent
Having had some experience failing to introduce new tools in a past life, I was adamant to do this by the numbers. I started an internal wiki page, visible to all, which broke down the needs of the programme from a CD perspective and compared Jenkins against Go for each need. It required investigating the major players in the Jenkins plugin marketplace: Build Pipeline, Delivery Pipeline and the newcomer with fan-in capability: Workflow.
Fig2. Jenkins Build Pipeline plugin
By having a central visible placeholder, comparing Go and Jenkins on specific value propositions, all team members can contribute to an unbiased (or perhaps biased from all sides!) informed foundation upon which a decision can be made. It was a good analytical start and important for future retrospecting of historical decisions. It was also important to acknowledge that all tools have issues and/or shortcomings and the road ahead will not be free of bumps. Posterity FTW!
Step 2 Showcase, listen, document
Showcase the new tool candidate amongst the people who will use it, listen to their concerns, and document. A lot of resistance comes about when change is dumped on people. Prove through doing: an hour here and there to show, listen and address concerns is courteous and reinforces relationships.
>> “[It] is important that the people rowing the boat are rowing in the same direction.”
One word of warning, watch out for changing too quickly, especially in large teams. This can give the effect of a new tool failing, but the problem is really with its hasty delivery. It must be a ‘pull’ from teams rather than a ‘push’. “Thou shalt not feud based on differing opinions of relative tool merits.” You may have worked on projects where teams are too keen to switch tools, thinking that with the ‘latest and greatest’ surely world domination was possible; a different form of (novelty-based) danger.
You won’t escape all cynics
Even with a careful approach, it can be clear some people still prefer a known evil. Depending on their level of influence and involvement, naysayers can be nurtured or ignored accordingly. What is important is that the people rowing the boat are rowing in the same direction, and the value of a new tool is understood by the most junior developer and explainable to the highest stakeholder. Promote a shared vision, transparent analysis, and collaboration with the right people and you might just get something close to ‘the right tool for the job’.
Sign up to receive the latest edition of P2 Magazine.