En bas de la page "conventional: comments" #JaiDécouvert : Google Engineering Practices Documentation (https://google.github.io/eng-practices/).

Dans le billet de blog d'Emmanuele Bassi "The Mirror", j'ai découvert l'expression informatique "Flag day".

Releasing GLib 3.0 today would necessitate breaking API in the entirety of the GNOME stack and further beyond; it would require either a hard to execute “flag day”, or an impossibly long transition, reverberating across downstreams for years to come.

source

L'article Wikipédia donne la définition suivante :

A flag day, as used in system administration, is a change which requires a complete restart or conversion of a sizable body of software or data. The change is large and expensive, and—in the event of failure—similarly difficult and expensive to reverse.

source

D'après ce que j'ai compris, un "Flag day" désigne un déploiement complexe où plusieurs systèmes doivent être mis à jour simultanément, sans possibilité de retour en arrière. C'est une approche risquée, car elle implique une transition brutale entre l'ancien et le nouveau système, souvent difficile à gérer dans des environnements interdépendants.

Un "Flag day" s'oppose à une migration en douceur.

C'est une situation que j'essaie d'éviter autant que possible. Des méthodes comme les Feature toggle ou l'introduction d'un système de versionnement permettent d'effectuer des migrations douces, par petites itérations, testables et sans interruption de service.

Concernant l'origine de cette expression, je lis :

This systems terminology originates from a major change in the Multics operating system's definition of ASCII, which was scheduled for the United States holiday, Flag Day, on June 14, 1966.

source

Je pense qu'à l'avenir, je vais utiliser cette expression.

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.

Je viens de déjeuner avec un ami qui m'avait fait découvrir Team Topologies. Cette fois, il m'a fait découvrir le modèle unFIX.

First, the unFIX model is a pattern library that provides many options for describing an organization design, ways of working within a team, decision-making, goal-setting, and more.

Think of the pattern options in the unFIX model as Lego blocks. Like these building blocks, they provide the flexibility to construct and adapt your organization according to your unique needs and preferences.

-- from

Je n'ai pas encore étudié le modèle unFIX.

Un autre sujet de notre discussion a porté sur la difficulté de définir des noms d'équipe générique pour des Stream-aligned team.
Il m'a raconté : « J'ai essayé de m'opposer à l'utilisation des Avengers comme nom d'équipe, mais je n'ai pas réussi ».

Cela m'a fait sourire, car j'ai rencontré un problème similaire avec des noms de Pokémon. Finalement, j'ai cédé et accepté ces noms, à condition de les accompagner de préfixes génériques comme "Team A - ", "Team B - ", etc.

Cette approche s’inspire du pattern de nommage des versions d’Ubuntu, qui utilise un format combinant un identifiant technique et un nom plus créatif, par exemple : "Ubuntu 24.10 - Oracular Oriole".

Pour ma prospection Freelance, il m'a conseillé de regarder du côté de la communauté Tech.Rocks.

Il a confirmé mes retours au sujet de Malt : ses amis ne reçoivent pas de propositions de mission via Malt.

Il m'a partagé cet article Building Stronger, Happier Engineering Teams with Team Topologies (Docker et Team Topologies).

Après avoir rédigé la note Commit Cavalier, #JaiDécouvert le concept de des projets de loi omnibus.

« Depuis les années 1980, cependant, les projets de loi omnibus sont devenus plus courants : ces projets de loi contiennent des dispositions, parfois importantes, sur un éventail de domaines politiques. »

-- from

Ceci m'a fait penser aux Merge Requests qui contiennent de nombreux petits commits, souvent de refactoring, qu'il serait fastidieux de passer en revue individuellement.

Je pense que je vais nommer ces Merge Request, des Merge Request Omnibus, ce néologisme sera une de mes marques idiosyncrasiques 😉.

J'ai donc décidé de baptiser ces Merge Requests des Merge Requests Omnibus. Ce néologisme deviendra l'une de mes marques idiosyncrasiques 😉.

#JaiDécouvert l'expression Core-stack developer dans cet article de David Larlet :

… when in doubt, focus on the core. When in doubt, learn CSS over any sort of tooling around CSS. Learn JavaScript instead of React or Angular or whatever other library seems hot at the moment. Learn HTML. Learn how browsers work. Learn how connections are established over the network.

The reason for focusing on the core has nothing to do with the validity of any of those other frameworks, libraries or tools. On the contrary, focusing on the core helps you to recognize the strengths and limitations of these tools and abstractions. A developer with a solid understanding of vanilla JavaScript can shift fairly easily from React to Angular to Ember. More importantly, they are well equipped to understand if the shift should be made at all. You can’t necessarily say the same thing about an INSERT-NEW-HOT-FRAMEWORK-HERE developer.

Building your core understanding of the web and the underlying technologies that power it will help you to better understand when and how to utilize abstractions.

That’s part one of dealing with the rapid pace of the web.

The Fallacy of Keeping Up (cache)

À défaut d’être complet (full) en raison de l’effervescence technique difficile à suivre au quotidien, il me semble de plus en plus pertinent de miser sur le cœur (core) des technologies utilisées. Comprendre et maîtriser les bases avant tout pour pouvoir ponctuellement et rapidement se spécialiser en fonction du besoin. Connaître ES6 vous servira ces 10 prochaines années, savoir utiliser React sera obsolète l’année prochaine. Sages développeurs, investissez.

-- from

Core-stack developer me fait penser à Choose Boring Technology et à mon article nommé Sur quelles compétences j'ai décidé ou non d'investir mon temps ?. Je me rends compte rétrospectivement que j'ai listé ma core-stack 🙂.

#JaiDécouvert le terme technique Best Current Practice (https://fr.wikipedia.org/wiki/Best_Current_Practice).

Je viens de déjeuner avec un ami qui m'a fait découvrir le livre Team Topologies.

#JaiDécouvert le site "Advantages of monorepos" (https://danluu.com/monorepo/).

Avantages :

• « Simplified organization » 👌
• « Simplified dependency management » 👌
• « atomic changes » 👌
• « Extensive code sharing and reuse » 👌
• « Unified versioning, one source of truth » 👌
• « Code visibility and clear tree structure providing implicit team namespacing » 👌
• « Large-scale refactoring » 👌
• « Collaboration across teams » 👌

#JaiLu les slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos.

#JaiDécouvert l'outil Git Subtree Splitter (https://github.com/splitsh/lite).