The technical side of the Neos release process is a wild mixture of automated and manual tasks. Some areas are properly documented and some are just known to the elders of the tribe. In fact, I was probably the one, who has a broad overview of the process and tools… until this week.
Hosted by sitegeist we met in Hamburg for a "Release Process" topic sprint, a small and very focused sprint dedicated to improving the release process, it's documentation and tools. Moderated by Gina three developers (Martin, Wilhelm and myself) discussed the existing process and devised a plan to improve it. Sadly Gerhard and Christian could not make it to Hamburg, but at least we already know there are more people on board for the future…
We started on Thursday with an EventStorming session to get the release process on the wall, visualized for the first time ever. Even though I had prepared (most of) the event cards on beforehand, and knew the process (having done it myself a few times and having helped others) I was still surprised. It is incredible, how much that method helped to transform a stack of notes into a visual representation of a well-defined process, complete with key aggregates, hotspots, commands and some more details.
On Friday we spent some time discussing the hotspots we had identified. What went wrong in the past, where can things break and why. And even if something goes wrong, what is the consequence–does it affect the release in a way that warrants blocking it? And, after all: Are there ways to test the results of the steps? Can we automate them?
Of course some steps will remain manual, there are tasks that need human input. One example is the documentation and communication around a minor or even major release, but also the decision to actually trigger the release of a new version. But most of the currently manual steps can be both tested and automated, some even seem almost trivial in that regard. Which gives us hope to be able to reduce the "job description" for release managers a lot.
Since we want to model the process in a pipeline (as you might know from GitLab or Jenkins), to tie in any automated tasks into an easy to understand way with anything that needs to be done manually, we discussed what we would need for that. After a quick look into Jenkins' "Pipeline as Code" we concluded that part, thinking it could work out.
After a break we began to write down a first list of todo items and notes, outlining the process we had visualized. Since some of those items were actually known already and even existed as GitHub issues, we opted for GitHub as the future home of anything related to the release process. A new repository will hold issues, code and documentation related to the release process (the technical side, that is, as opposed to the "public view".) We set up a project board, defined some labels and transferred all existing relared issues to their new home.
Our next step is to transform the todo items from the sprint into issues, labeled and ready to be solved. The second task to solve for the first of our milestones is to complete evaluation of Jenkins as the pipeline solution. If nothing stops us, we will continue to work on the next milestones as planned, and Gerhard and Martin can release Neos 4.3 (together with Flow 5.3) with a shiny new build process toolchain.
Kommentare