Notre recette pour des mises en prod’ quotidiennes
Il était une fois une équipe qui galérait à mettre en prod’…
Il était une fois une équipe qui galérait à mettre en prod’…
This article is also available in English.
J’ai rédigé une série d’articles qui racontent comment une équipe a réussi à améliorer son process et ses pratiques de mise en production, jusqu’au point où faire plusieurs mises en production dans la même journée ne choque plus personne.
Voici la liste des articles. Ces articles suivent un ordre logique : les articles plus récents référencent les précédents.
Bonne lecture !
De 1 release par trimestre à plus de 2 par semaine
Management visuel et gamification pour le process de mise en productionjp-lambert.me
Cadencer les mises en production et en démultiplier le rythme
Avec toujours plus de management visuel, bien entendu !jp-lambert.me
Le stand-up : point de synchro release
Le moment où prend vie le management visueljp-lambert.me
Isolation Continue : choisir librement l’ordre des mises en production
Un autre élément important sur notre chemin vers le Déploiement Continujp-lambert.me
Détail de notre process de mise en production
Conçu pour compenser les difficultés connuesjp-lambert.me
Gestion de risque : formalisation et communication
Quand l’information se perd, c’est tout le process qui menace de s’enrayerjp-lambert.me
Pour faire court— Notre recette pour des mises en prod’ quotidiennes
Si je devais résumer tous ces articles et en faire une grosse recette, alors je listerais les ingrédients suivants. J’ai ajouté des liens vers les articles si jamais vous vouliez creuser plus spécifiquement un point donné :
Nous faisons beaucoup de management visuel
… Pour s’assurer que le process est bien suivi
… Pour synchroniser plusieurs équipes
… Pour accélérer le rythme des mises en production, en traitant bien les mises en prod’ comme plus importantes que les nouveaux développements
Les éléments de management visuel s’intègrent bien avec les rituels existants : stand-up quotidien, planification d’itération, revue d’itération
Nous avons arrêté GitFlow en faveur d’un autre modèle de branches qui nous a rendu plus flexibles
Nous plaçons un effort particulier sur la communication et la synchronisation avec les dépendances externes à l’équipe
Nous prenons également garde à bien gérer dans le process les risques que nous ne pouvons pas corriger pour le moment, comme des problèmes d’environnements ou s’assurer d’être en capacité de faire un rollback en amont de la mise en prod’
Nous avons arrêté de faire des passes de non-régression complètes pour mener à la place des sessions de test de non-régression ciblées et basées sur une analyse de risque
… En gardant bien trace de ces éléments d’analyse de risque et en s’en servant pour faciliter la communication avec le reste du monde
Et voilà ! 💥
Et vous alors ?
Est-ce que vous avez réussi un exploit similaire ? Comment vous y êtes-vous pris ? Pourriez-vous partager votre expérience dans les commentaires ? ✍️
Merci d’avance ! 👋
Cet article vous a plu ?
Abonnez-vous à moi via le bouton Follow pour être notifié des autres articles !
Et n’oubliez pas de m’applaudir 👏 et de partager l’article ! N’oubliez pas que c’est votre amour 💓 qui me fait mettre autant de cœur à l’ouvrage.
Merci 😄