Well, I have finally reached the holy Grail of DevOps—The Phoenix Project business novel. Only to realize once again that everybody has already read it except me. Therefore, I guess I will just briefly cover the points that got my attention or looked unclear/funny.
An interesting approach: to unroll a functionality but not to activate it. Thus the code is in production and everything works. Or to activate it but not for all users/scenarios. Or do that only for testing purpose. Alas, this doesn’t work with all types of software. But we should use it where we can.
There are “three ways”:
1) No local optimization. Work in small batches, never passing defective code down the line. Toolkit:
a. Continuous build, integration and deployment.
b. Build environments on request.
c. Limit WIP.
d. Build safe systems and organizations that are safe to change. This point is a bit vague. I guess, I will grasp it when the time comes (or when I finish reading DevOps Handbook J).
2) Building feedback. Not quite clear how to do this in my situation. Have to sort it out yet.
a. Stop production line if tests and builds fail. A relatively simple one if one learns to understand 1 and 2d.
b. Keep improving your work even to the disadvantage of your everyday routine. Everything is clear, but it takes political will to achieve. Can you lend me some? =)
c. Create quick autotests to make sure your code is ready for deployment at all times.
d. Create common goals between Dev and Ops.
e. Omnipresent telemetry to signal whether everything is all right. A sad one: in our situation, this is going to be expensive, lengthy and difficult to accomplish. But there is progress.
3) Building a culture to foster constant experimenting and learn from one’s wins and losses.
a. Create a culture of innovations and risk-taking. So much to learn here yet. For me.
b. Earmark at least 20% of time for continuous improvement. As I saw from one experiment, it takes more than just “you have 20% of your time dedicated to work on improvements”. We may also need to address the previous item and possibly other missing things.
Even though “break the silos” is a dominating rule in the book, this story is about greater responsibility on the part of the product code writers. Release automation just doesn’t leave us any other option. Manual deployment by Ops does balance out poor coding or testing in some degree (assisted by developers, admins can roll things back or fix them on the go), but a fully automated system must be able to do it all by itself. Well, of course, one can still wake admin up to fix things, but that would mean extra downtime. This is somewhat set off by the fact that now Ops’ responsibility for code/environment delivery infrastructure becomes very high. In fact, this component is expected to be incredibly robust. Nearly more so than product availability itself.
It is not even about cost saving; automation is needed for developers to be able to get productive-like environments all by themselves. To really turn stage-environment tests into a quality mark, meaning that the actual deployment will not fail. And to reuse the expertise for different development teams.
According to the book, the main work streams are: business projects, technical projects, changes, repairs/firefighting. But I am not quite on to it:
1) Why business and technical projects are listed separately? Is it a technical project to update a mail system? One featuring business functionality, let’s say. This division looks a bit arbitrary to me.
2) Projects consist of changes; why are these separate, again?
Funny stuff: once again, there is Russian mafia seeking to buy your clients’ data, stolen by hackers. I guess, we have one more national brand to go with the Bear and the Balalaika. =)
Ease of reading: Yes, it’s both easy and interesting. After all, it is more of a fiction piece, quite well written, too.
Usefulness: above average. A breakthrough is still way off, and I don’t have all the answers. I need to read more. But I cannot call it time lost, either—certainly a useful book.