Demander un devis

Réalisation · travail interne, chaîne de livraison

Notre chaîne de livraison : chaque mise en ligne numérotée, et un retour arrière écrit d'avance.

Ce n'est pas une mission pour un client : c'est l'outillage qui met en ligne ce site et les projets que nous livrons depuis notre forge. Chaque version devient une image Docker numérotée, déployée sans qu'aucune clé d'administration ne circule dans la chaîne. Revenir à la précédente ne demande aucune reconstruction, et la procédure est écrite.

01/Le contextePourquoi nous l'avons construite

Une mise en ligne à la main dépend de la mémoire de celui qui la fait

Nous sommes deux à livrer. Il fallait qu'une mise en ligne suive toujours le même chemin, et que nous sachions à tout moment quelle version tourne. Pour chaque risque, ce que fait la chaîne.

  1. 01Chaque mise en ligne faite à la main diffère un peu de la précédente.Toujours le même chemin : construction de l'image, publication au registre, déploiement demandé par la forge.
  2. 02Une image étiquetée « dernière version » ne dit pas quel code tourne.Chaque image porte son numéro de version et l'identifiant de son commit, inscrits dans l'image elle-même ; aucune étiquette mouvante.
  3. 03Revenir en arrière en urgence oblige à reconstruire une version que nous n'avons plus.Les numéros se suivent sans trou : le précédent désigne toujours une image publiée, qu'il suffit de relancer.
  4. 04Un envoi involontaire sur la branche principale part en production : c'est arrivé chez nous.La branche principale est fermée à l'envoi direct dans tous nos dépôts actifs : tout passe par une demande de fusion, chaîne au vert, administrateurs compris.
02/Ce que nous avons construitEn service aujourd'hui

Du commit à la mise en ligne, sans geste à la main

Une demande de fusion valide, la branche principale livre, et chaque étape laisse une trace que nous pouvons relire.

  • 01
    Forge auto-hébergée. Code, demandes de fusion, chaîne et registre d'images sur notre propre forge Forgejo.
  • 02
    Valider sans livrer. Une demande de fusion construit l'image pour vérifier qu'elle passe, sans la publier ni la déployer.
  • 03
    Numéro de version. La date, puis le rang de la publication dans la journée, réservé avant la construction pour qu'aucune image n'en écrase une autre.
  • 04
    Image Docker en plusieurs étapes. Dépendances, construction et exécution séparées ; l'image finale tourne sans privilège, avec une sonde de santé.
  • 05
    Une image qui sait d'où elle vient. Commit d'origine et numéro de version sont inscrits dans ses étiquettes : c'est le conteneur qui dit ce qui tourne.
  • 06
    Déploiement par contrôleur. La forge demande la mise en ligne à un contrôleur, avec une clé dédiée ; les secrets de l'application restent sur le serveur, jamais dans le dépôt.
  • 07
    Retour arrière écrit. Remettre le numéro voulu, relancer, vérifier par le conteneur ; un numéro absent fait échouer la commande sans toucher au site en place.
  • 08
    Garde-fous. Branche principale protégée dans tous les dépôts actifs ; chaque lundi, les images réellement en service sont analysées et le nombre de failles critiques arrive par e-mail.
03/Un schémaComposé en texte, ce n'est pas une capture

Un schéma du parcours, en attendant une capture de notre forge

Aucune capture de la forge n'est encore publiée. Ce schéma suit une mise en ligne, du code au serveur.

Schéma de la chaîne de livraison en quatre temps : une demande de fusion, chaîne au vert, rejoint la branche principale ; le projet est construit en image Docker numérotée, avec sa sonde de santé ; chaque version est gardée dans notre registre privé ; l'image est déployée sur nos serveurs, avec un retour arrière écrit d'avanceSchéma de la chaîne de livraison en quatre temps : une demande de fusion, chaîne au vert, rejoint la branche principale ; le projet est construit en image Docker numérotée, avec sa sonde de santé ; chaque version est gardée dans notre registre privé ; l'image est déployée sur nos serveurs, avec un retour arrière écrit d'avance
Fig. 01Schéma du parcours, composé en texte. Ce n'est pas une capture de notre forge.

Quatre temps, du code à la mise en ligne

Une demande de fusion validée, une image Docker numérotée, gardée dans le registre privé, puis déployée par le contrôleur ; revenir à la version précédente est écrit d'avance.

04/TechnologiesCe que nous avons choisi, et pourquoi

Une chaîne courte, que nous pouvons relire de bout en bout

Peu d'outils, et chaque règle écrite dans le dépôt, à côté du code qu'elle livre.

  • ForgeForgejo et sa chaîne Forgejo Actions, registre d'images privé sur la même forge.
  • ImagesDocker en plusieurs étapes, exécution sans privilège, sonde de santé, étiquettes de commit et de version.
  • DéploiementDocker Compose sur le serveur, numéro de version lu dans un seul fichier ; une valeur absente fait échouer la commande au lieu de servir une image au hasard.
  • AccèsContrôleur de déploiement joint par une clé qui ne sert qu'à le déclencher ; secrets de l'application sur le serveur, hors du dépôt.
  • ContrôlesBranche principale protégée dans tous les dépôts actifs, chaîne au vert avant fusion, administrateurs compris.
  • VeilleAnalyse hebdomadaire des images en service avec Trivy, rapport par e-mail et rapport d'audit en PDF.
05/Pour aller plus loinPrestation voisine, et le blog

Pour un logiciel livré avec sa chaîne

Développement .NET à StrasbourgDu code testé, livré avec sa mise en production automatiséeProtéger la branche principaleMesure, mise en place et pièges, sur le blog

Et maintenant

Des mises en ligne à la main, et personne ne sait quelle version tourne ?

Chaque logiciel que nous écrivons part avec sa chaîne de livraison. Décrivez-nous votre projet, nous vous dirons ce qui est faisable, avec un délai et un ordre de prix.

Discuter de votre projet

Réponse sous 24 h ouvrées, par l'un des deux fondateurs. Ou par téléphone : 07 59 96 14 99.