Improve with Automation by Repetition
Any Release Engineering system is a complicated workflow system made up of lots of scripts, typically in a CI/CD tool. It can be confusing to determine what to improve at any point.
To begin automating the system, the easiest low hanging fruit of a task can be a good option at times. At others, what is most painful, cumbersome, or logically tough might be best.
Most often, Release Engineering systems move towards automation gradually. It is illogical to halt the company from releasing their product to customers because a robust Release Engineering system with all bells and whistles isn't ready. And in the odd chance that you do have the budget and capacity, a product's shape and its characteristics need to be clear for the Release Engineering system to serve it properly. Focus on simple solutions first instead of clever ones as the tendency of over-engineering in this context is high.
Here's a high-level improvement workflow you may adapt:
- When working on a release train, keep a journal and logbook and note down anything that feels painful, overly manual, and cognitively burdensome. These are the areas you want to tackle first.
- When running a postmortem with the team, make a case for why this particular area needs attention. Focus on the why and pitching the problem first.
- Before devising an automated script as a solution, figure out how the current workflow can be made better first. This may require that you test the manual improvement out in the subsequent train. This is really the heart of this improvement workflow, the ability to test-drive an improvement manually before coding it into the system.
- Once the improvement has seen one or more repetitions, invest in automating it then.
This tactic allows for a process to evolve that is more resistant to changes over time. Coded workflows are more expensive to change and maintain.
Oftentimes when building software, it's hard to test out the feature without actually building it. One has to get creative to test business outcomes. Because the input and output are under the control of the team, a workflow improvement can usually be tested by hand before programming it.
When Tanzu Application Service began its life, it was packaged, tested, and published to the customers by hand. This meant there was a lot of toil in the process. The whole publishing workflow was manual until only a couple years back. But gradually, we've moved uploading, adding product to the distribution catalog, entering data in forms, and flipping the switch to public access all automated.