Continuous Delivery: putting pressure on your skills, but in a good way
Switching to continuous delivery means abandoning existing practices and habits, and applying and developing new ones. But it doesn’t need to be a fast change, says CD coach Eduards Sizovs.
JAXenter: So your talk at the DevOpsCon will focus on the trouble that teams encounter with Continuous Delivery. In your experience, what are the most common obstacles that teams will hit when moving towards CD?
Eduard Sizovs: Since every organisation is unique, obstacles almost never repeat themselves and that makes the challenge especially interesting. Despite the heterogeneity of problems, one common obstacle still crops up – lack of organisational alignment. Often organisations try to push CD initiative from the top, but the team is not ready to pick up.
The opposite can also be true – a team is willing to implement CD, but cannot get support from management or fellow teams, especially from traditional, change-resistant parts of the organisation, such as security and operations. Usually CD requires significant architectural and organisational change and may end up becoming an expensive and time-consuming initiative. Getting a buy-in from paying customers becomes complicated and requires facts, numbers and ROI analysis. Often the initiative stops here and people give up.
I suggest treating CD as long journey instead of short and expensive marathon run. Practically it means spending about 10-20% of your time on implementing CD with baby steps instead of “stopping the world” and steeping into deep CD waters. Firstly, it will be much easier to get approval from the rest of organisation; secondly – CD is never ready or done and devoting 10-20% of time is enough to continuously get better at it.
And what’s your worst CD horror story?
I saw an experienced team working on continuous delivery and modernising their technical stack for several months – introducing containers, putting Docker inside Docker inside Docker etc. Surprisingly, after all their efforts, these folks were unable to control the monster they’ve built and overall delivery became even slower than before. The team was forced to roll-back and it took them few more months. Given nowadays IT costs, that’s a real horror.
I will share more horror stories during my presentation at DevOpsDays. Yeah, and I will tell a story about people who were fired after failing.
In terms of the developer’s everyday work, what’s different for programmers working in a CD environment compared to projects that have slower release cycles?
There is an effect of acceleration in software development (coined by Kent Beck). During transition to shorter delivery cycles, a team must abandon existing practices and habits, apply and develop new.
For example, going fast requires fine-tuning the process and elimination of muda (wasteful activities). Traditionally, handovers between people or re-work are primary candidates for elimination. It may sound simple, but reality is not that fluffy. For example, for engineers it may mean applying practices they never did before such as TDD, pair programming (or even pairing with QA professionals!), usage of feature branching on the code level. In sum, CD puts pressure on our skills and that is a good thing in general, since it enables professional growth and boosts overall product quality.
Is CD always the right choice? Are there instances where you would say it makes sense to not take the CD path?
In a perfect world everyone would like to deliver reliably and in short cycles, but everything comes with cost. CD is investment in infrastructure, automation, testing, architecture. So you have to balance benefits vs. costs.
Does it make sense to invest in a throwaway prototype? I doubt it! Does it make sense to invest in daily deployments for a product in standstill? I doubt it!
Often the process of ‘going live’ is not as simple as updating a web server. Let’s say you have to produce physical hardware, educate a whole business unit or write vast amount of documentation in multiple languages. The aforementioned factors are not uncommon and must be taken into account before shortening release cycles to the extreme.
Also, CD cannot be considered as ‘everything or nothing’ – you can easily leave out some parts of it. For most companies to deliver continuously and reliably, Netflix-level infrastructure is not needed. You can (and should) stick to a minimal number of practices and tools that work for you and your organisation.
On the other side, what would you say are the biggest positive impacts that teams are likely to enjoy in a CD approach?
CD makes change easy and safe. The easier change is, the more changes will hit production faster. More timely changes give rapid feedback. Rapid feedback is a gift from heaven because it lets you see result of your work immediately and whether you’re doing the right thing.
What could be more enjoyable than the realisation that work that you do makes sense to your customers? Certainly profit from these happy customers!