Commencez par une application qui compte vraiment

Vous avez une liste de tout ce que votre équipe possède. Applications, bases de données, composants d'infrastructure, scripts, tâches cron. Peut-être avez-vous passé une semaine à faire un inventaire, ou peut-être l'avez-vous simplement griffonné sur un tableau blanc pendant une réunion. Maintenant, vous fixez cette liste, et la question vous frappe : par où commencer ?

C'est là que la plupart des équipes se figent. Elles craignent de choisir la mauvaise chose. Elles craignent de passer à côté de quelque chose de plus important. Elles craignent que ce qu'elles choisissent ne produise pas de résultats visibles. Alors elles continuent d'analyser, de discuter, et de reporter l'action.

L'astuce n'est pas de choisir le point de départ parfait. L'astuce est de choisir quelque chose qui a de grandes chances de fonctionner et de grandes chances d'être remarqué quand ça marche.

Commencez par une application, pas par l'infrastructure ou la base de données

Il est tentant de commencer par l'infrastructure parce que l'infrastructure semble fondamentale. Ou de commencer par la base de données parce que les modifications de base de données font peur. Mais le meilleur endroit pour débuter est une application.

Ce n'est pas parce que les applications sont plus importantes. C'est parce que les applications changent le plus souvent, et que leurs changements sont les plus visibles pour les utilisateurs. Lorsque vous construisez un pipeline pour une application, les résultats sont immédiats. Les builds deviennent automatiques. Les tests s'exécutent à chaque changement. Les déploiements cessent d'être des rituels manuels qui nécessitent trois personnes en visioconférence à 22 heures.

Cette expérience construit la confiance. Vous voyez le pipeline fonctionner. Vous voyez l'équipe commencer à lui faire confiance. Et cette confiance est ce dont vous avez besoin avant de vous attaquer aux parties plus difficiles comme les migrations de base de données ou le provisionnement d'infrastructure.

Trois critères pour choisir la bonne application

Regardez votre inventaire et choisissez une application qui remplit ces trois conditions.

Le diagramme suivant illustre les trois critères pour vous aider à décider :

flowchart TD A[Début : Lister toutes les applications] --> B{Développée activement ?} B -- Non --> C[Ignorer cette app] B -- Oui --> D{A des utilisateurs réels ?} D -- Non --> C D -- Oui --> E{L'équipe veut collaborer ?} E -- Non --> C E -- Oui --> F[Sélectionner cette application] F --> G[Construire le pipeline golden path] G --> H[Étendre aux autres apps]

Premièrement, l'application est développée activement ou modifiée fréquemment. Une application que personne ne touche ne vous apprendra rien. Vous avez besoin de vrais changements qui traversent le pipeline pour trouver les vrais problèmes. Si l'application est mise à jour tous les quelques mois, vous passerez plus de temps à attendre qu'à apprendre.

Deuxièmement, l'application a de vrais utilisateurs. Pas un prototype. Pas une preuve de concept qui tourne sur l'ordinateur portable de quelqu'un. De vrais utilisateurs signifient un réel impact. Quand le pipeline fonctionne, les utilisateurs reçoivent les mises à jour plus rapidement. Quand le pipeline attrape un bug avant le déploiement, les utilisateurs ne subissent pas l'interruption. L'équipe ressent la différence, et ce sentiment est ce qui vend la prochaine phase de travail aux parties prenantes.

Troisièmement, l'équipe qui possède l'application est prête à collaborer. C'est le critère le plus important. Vous pouvez avoir le meilleur plan technique du monde, mais si l'équipe est débordée, épuisée, ou simplement pas intéressée, le pipeline ne tiendra pas. Trouvez une équipe qui a un peu de capacité et un peu de curiosité. Travaillez avec elle. N'imposez pas un nouveau processus à une équipe qui est déjà en difficulté.

Prenez la décision rapidement

Le processus de sélection devrait prendre une ou deux sessions de discussion. Rassemblez l'inventaire. Regardez quelles applications changent le plus fréquemment. Parlez aux équipes. Demandez-leur si elles ont de la place pour essayer quelque chose de nouveau. Puis décidez.

Ne laissez pas cela traîner pendant des semaines. La paralysie par l'analyse est l'ennemi du progrès. Il vaut mieux choisir un candidat décent et commencer à construire que de passer un mois à analyser chaque option pour finir avec rien.

Cette application devient votre golden path

Une fois que vous avez choisi l'application, elle devient votre golden path. C'est un terme pour désigner le premier pipeline de livraison standardisé que votre équipe documente, construit et traite comme une référence pour tout le reste.

Chaque décision concernant les pipelines, les tests et le déploiement est d'abord appliquée ici. Comment structurez-vous le script de build ? Quels tests s'exécutent dans le CI ? Comment gérez-vous les secrets ? Comment déployez-vous en staging par rapport à la production ? Toutes ces questions trouvent une réponse pour cette seule application.

Quand le golden path fonctionne bien, vous avez un modèle opérationnel. La prochaine application peut suivre le même schéma. Puis la suivante. Ensuite, vous pouvez adapter le schéma pour les changements de base de données. Puis pour l'infrastructure. Chaque étape devient plus facile car vous ne partez pas de zéro.

Le golden path n'est pas spécial

Il est important de comprendre ce que le golden path n'est pas. Ce n'est pas une déclaration que cette application est plus importante que les autres. Ce n'est pas un privilège permanent. C'est une expérience délibérée conçue pour avoir le risque le plus faible et la plus grande chance de succès.

Si quelque chose tourne mal, les dégâts sont limités à une application. Si une décision s'avère erronée, vous la corrigez pour une application et en tirez des leçons. Les leçons s'appliquent ensuite à tout le reste.

Considérez-le comme un banc d'essai. Vous testez la capacité de votre équipe à construire un pipeline, à vérifier vos hypothèses sur l'automatisation, et à prouver que l'approche fonctionne avant de la généraliser.

Mettez tout le monde d'accord

Avant d'écrire une seule ligne de code de pipeline, assurez-vous que tout le monde sait quelle application est le golden path et pourquoi elle a été choisie. Cet accord évite les confusions plus tard. Quand quelqu'un demande pourquoi une autre application n'a pas encore été touchée, la réponse est claire : nous prouvons d'abord le schéma sur celle-ci, puis nous l'appliquerons au reste.

Écrivez-le. Mettez-le à un endroit visible. Mentionnez-le dans les mêlées quotidiennes. Le but n'est pas de créer de la bureaucratie. Le but est d'éviter que la question "pourquoi travaillons-nous sur ceci plutôt que cela ?" ne fasse dérailler la dynamique.

Liste de vérification pratique avant de commencer

  • Une application est sélectionnée, qui est développée activement, a de vrais utilisateurs, et a une équipe volontaire
  • La décision est documentée et partagée avec l'équipe
  • Tout le monde comprend qu'il s'agit du golden path, pas d'une priorité permanente
  • L'équipe propriétaire de l'application a accepté de collaborer
  • Un calendrier approximatif est fixé pour le premier pipeline fonctionnel (pas parfait, juste fonctionnel)

L'essentiel à retenir

Choisissez une application qui change souvent, a de vrais utilisateurs, et a une équipe qui veut travailler avec vous. Construisez le pipeline pour cette application en premier. Faites-le fonctionner. Apprenez-en. Puis recommencez pour la suivante. C'est ainsi que vous passez d'une liste de tout ce que vous possédez à un système de livraison qui livre réellement.