GitOps problems

This is what I've learned from reading the article 'Reverte doch einfach!' (author: Lars Kölpin-Freese) in the magazine Javamagazin (in German language, 3rd issue of 2024).

Table of contents

• Abstract
• Upward migration
• Stateless apps
• Traveling back with git revert
• Down migration at infrastructure level
• Summary

Abstract

In GitOps, text files are used to administer IT infrastructure. This article raised the question of using 'git revert' if any rollback is necessary.
A simple rollback per versioning of the infrastructure with git should be feasible for stateless apps.

Upward migration

For upward migration, especially involving databases, scripts are used for traceability. The available tools are:

• Liquibase
• Flyway

Stateless apps

There are three types of applications/apps:

• stateless apps
• stateless apps with stateful dependencies
• stateful apps

A stateless app has all its data in its deployment, i.e. there is no dynamic data.
The advantage here is such an app is scalable and can be rolled back as it went.
But in practice, software update can only go up and rollback is practically impossible.
A big part of stateless apps has stateful dependencies, e.g. database correction.

Time travel with git revert

There are two possibilities for down migration:

• app level
• platform level

For down migration, scripts are also employed as the tools which have destructive effects, e.g. drop column.

Down migration at infrastructure level

Downgrade of applications can also be done at infrastructure level. The objective here is to enable data inventories without having developers to implement anything.
To achieve this, a backup system must be implemented first. There should be a separate system (of a software) to do the backup, especially the database into a storage.
Then with git revert, a rollback of a new version can take place. A disadvantage of this is that new data will be loss.

Summary

What I've learned from this article is the need to create a backup system, orchestrated with scripts, before rolling out a new version. To my understanding, the deployment time will be increased, but still that would be open for discussions among developers and SREs.