Minimally Invasive Repairs with Z2

<!–
_When I talk about Z2 I usually show a picture like this one:

I do that for a purpose of course. It is meant to provide the impression that everything is driven from the repositories. I.e. it’s system centric. To propagate changes, you only need to propagate changes. Nothing else requires thinking. Does that come across?

That picture captures a real development and production landscape of a previous project (except that I added the hubcr lately). So this is not an idea, it is meant to explain something existing. Hence it lacks all that was deemed obvious to the reader (developers familiar with the technology) at the time. The obvious at that time is of course all that matters when talking to people not familiar with Z2.

It does show repositories and change flow along some dev → staging → production chain. It shows developer environments on the bottom, some automated testing environment on the top left, some staging installation at the top middle and a production landscape on the right.

Coming back to the motivation for this blog’s title: As runtimes will pick up changes by themselves, because there is no deployments and the likes, there is no such thing as a roll out in the sense of a complicated activity. Changes can be applied and made effective at minimal impact on the operational complexity. If you need fix a single line of code, than that’s the most complex thing you need to do.

A few examples:

• A pre-production environment, called “staging” here, provides a de-coupling from daily development progress for production qualification. From a developer perspective, fixing the staging system means to check out a Z2 core, fire it up, test local changes, commit/push.
  Due to its pre-configured environment, the developer’s local staging installation will pull anything needed from the right repositories and would even use a shared staging application database.
• Running automated integration tests means exactly that: Running them. There is virtually no environment to write setup scripts for. Changes will be picked up automatically.
• Applying a critical hot-fix in production requires to apply the minimal change possibly (after testing in pre-prod) in the production code base and to trigger a synchronization on the hub, restarting the servers as appropriate.

What makes repairs minimally invasive is not the amount of changed code, it’s the little amount of work to be done and the little risk to be taken when applying changes.