Je termine ma première année complète chez Taleo à Jacksonville. Je suis toujours attiré par le code. Comme chef d’équipe, je regarde davantage le trajet qui le transforme en service : build, configuration, déploiement, données, surveillance et reprise. Je reste volontairement général sur ce que je n’ai pas à raconter ici; le mécanisme vaut pour bien des systèmes.

source -> build versionné -> paquet -> configuration d'environnement
       -> déploiement -> tests de santé -> trafic -> mesures et logs
                                      |
                                      `-> retour ou correction

Le paquet devrait être le même entre test et production. Les adresses, comptes et limites changent par configuration; modifier le binaire directement sur un serveur crée une version que personne ne sait reconstruire. Chaque déploiement porte un identifiant pour relier une hausse d’erreurs au changement exact.

Un test de santé confirme que le processus répond. Un test synthétique traverse une fonction réelle. Les deux sont nécessaires : /health peut être vert pendant que SQL Server refuse les requêtes. Les logs reçoivent un identifiant de corrélation pour suivre l’appel entre composantes, et les métriques gardent temps de réponse, erreurs et profondeur des files.

Une release doit prévoir son échec

Je décrirais une mise en production ainsi :

1. sauvegarder ou préparer la migration de données et son retour;
2. déployer le paquet sur une instance hors trafic;
3. exécuter santé et transaction synthétique;
4. envoyer une petite partie du trafic si l’architecture le permet;
5. comparer erreurs et latence avec la version précédente;
6. poursuivre ou revenir selon des seuils décidés avant la release;
7. conserver l’heure, la version et la décision dans le journal de changement.

Le retour n’est pas toujours remettre l’ancien fichier. Une migration de schéma peut rendre l’ancienne application incompatible. Il faut introduire les colonnes de façon compatible, migrer par étapes et retirer l’ancien format dans une release ultérieure. La reprise se conçoit en même temps que le changement.

Le cloud me paraît moins mystérieux parce qu’il garde exactement ces responsabilités. La machine se trouve ailleurs et peut être créée à l’heure, mais l’image, les clés, l’état et le coût restent à gérer. Une instance éphémère exige une recette plus propre; elle ne transforme pas une application fragile en service résilient.

Windows 7 rappelle la même chose côté poste. Le système ne gagne pas seulement avec une nouvelle fonction, mais avec un démarrage mesuré, des pilotes compatibles et des confirmations de sécurité qui ne deviennent pas du bruit. Le mobile ajoute le cycle de vie, le réseau intermittent et la batterie. Le drone ajoute des capteurs imparfaits et un état sûr sur perte de liaison. Le courriel ajoute une chaîne de récupération d’identité.

Tous ces cas peuvent être examinés avec quatre questions : quel état doit survivre, quelle frontière protège cet état, quelle mesure montre le service réel et comment reprend-on après une interruption? Comme chef d’équipe, je veux que les réponses appartiennent au groupe plutôt qu’à une seule personne.

Le code qui compile reste un moment satisfaisant. En 2009, je vois surtout tout ce qu’il ne prouve pas encore. Mon prochain réflexe sera de suivre une feature jusqu’au déploiement, puis de provoquer une panne contrôlée pendant que le chemin de retour est encore frais.