Mercredi 27 novembre 2024 à 11:29

Il y a quelques jours, j'ai écrit une note au sujet des stratégies de versionning et aujourd'hui, #JaiDécouvert le site TrunkVer (https://trunkver.org/) (from).

We have identified a frequent source of avoidable confusion, conflict and cost in the software delivery process caused by versioning software that should not be versioned - or rather, the versioning should be automated.

source

👍️

However, we keep encountering teams and organizations that apply semantic versioning or a custom versioning scheme to software that does not need any of that - and through this, they create an astonishing amount of unnecessary work such as arguing whether or not a certain piece of software should be called “alpha”, “beta”, “rho”, “really final v4” etc, manually creating tickets listing the changes or even specialized gatekeeper roles such as “release engineer” - in the worst case a single person in the whole organization. Because this makes it harder, boring and costly to deploy, it systematically reduces the number of deployments, and through this the delivery performance of the organization.

source

👍️


Depuis 20 ans, j'ai rarement développé des librairies ou des API REST utilisées par des tiers.
Par conséquent, je n'ai pratiquement jamais eu besoin d'utiliser Semantic Versioning dans mes projets.

La plupart des projets sur lesquels je travaille suivent le modèle "Rolling release".

Je croise trop souvent des développeurs utilisant la spécification Semantic Versioning alors que leur projet suit le modèle Rolling release et je pense que TrunkVer serait bien plus adapté à leur contexte.


Cela fait plusieurs années maintenant que j'utilise la méthode suivante pour identifier "la version" de ce que je déploie.

Dans mes scripts de déploiement, je génère un fichier version.json, comme ceci (example) :

cat <<EOF > version.json
{
    "environment": "prod",
    "branch": "$(git rev-parse --abbrev-ref HEAD)",
    "gitDate": "$(git show -s --format=%ci | sed "s/ /_/g")",
    "buildStamp": "$(env TZ=Europe/Paris date '+%Y-%m-%d_%H:%M:%S-%Z')",
    "gitHash": "$(git rev-parse HEAD)"
}
EOF

Ensuite je l'insert au moment du docker build et je l'expose sur une URL http.

Ce qui donne, par exemple, ceci :

$ curl https://notes.sklein.xyz/version.json
{
    "environment": "prod",
    "branch": "main",
    "gitDate": "2024-12-03_23:43:26_+0100",
    "buildStamp": "2024-12-03_23:51:09-CET",
    "gitHash": "04c83c82a663260626e02502be1015d23b4859c2"
}

Ma méthode ne correspond pas exactement dans la forme à la méthode TrunkVer mais cela s'en rapproche.


Journaux liées à cette note :

J'ai découvert les fonctionnalités de Goreleaser #golang, #JaiDécouvert

J'ai de nombreuses fois remarqué l'existence de projet Goreleaser, mais je découvre seulement ce soir l'étendue de ses fonctionnalités. Et surtout, je découvre que depuis 2024 il n'est plus limité au seul langage Golang.

Quelques fonctionnalités de Goreleaser :

  • Génération automatique des releases GitHub, GitLab, etc
  • Génération et publication des images Docker, Flatpak, AUR, Source RPMs, etc
  • Génération de changelog
  • Publication automatique d'annonce sur Mastodon, Reddit, Mail, Discourse, etc

Comment j'ai pu passer à côté de toutes ces fonctionnalités 🫣.

J'ai lu le billet Building GoReleaser: from shell script to paid product qui retrace l'histoire de ce projet.

Attention toutefois, de nombreuses fonctionnalités sont payantes : GoReleaser Pro.

Je vais commencer par utiliser Goreleaser dans sklein-convarchive, et je verrai bien si à l'avenir les fonctionnalités payantes sont limitantes ou non.

Voir aussi : 2024-11-27_1129.


Premier problème le 6 août 2026 à 23h29, le support de podman est dans la version payante de GoRelease : https://goreleaser.com/customization/package/docker/#using-podman.