Pourquoi Agile n'est pas « agile » sans la livraison continue

La livraison à la fin de chaque sprint est à votre portée. Voici comment vous lancer.

Ian Buchanan Ian Buchanan

Les pratiques Agile peuvent être vues de deux façons : recettes et capteurs. Les personnes ayant beaucoup d'expérience logicielle ont noté les pratiques qui amélioraient leur productivité. De plus, ces pratiques révèlent les causes de nos manques de productivité en amplifiant leurs conséquences.

La livraison continue fait partie de la recette Agile et met parfaitement en évidence les inefficacités. De plus, pour profiter des avantages d'Agile, vous devez rester agile durant toutes les phases du cycle de développement logiciel. La planification et le développement itératifs ne valent pas grand-chose si vos user stories et correctifs de bugs languissent dans un dépôt pendant des semaines avant que les parties prenantes et les clients y jettent un œil.

Vous n'êtes #agile que dans la mesure où vous êtes capable de livrer fréquemment, et sans problème.

L'essence d'Agile se résume à « inspecter et adapter ». Ceci dit, vous n'avez probablement pas besoin de mettre votre système de développement et de déploiement sous un microscope pour déterminer s'il nuit ou contribue à l'agilité de votre équipe. Et le fait que vous lisiez ceci est un bon signe que vous avez déjà classé votre système dans la catégorie des « obstacles ». Alors, il est à présent temps de s'adapter.

Vivre avec une frustration continue

Il y a un état commun du logiciel que je qualifie de « frustration continue ». Il s'agit de l'absence de toute pratique d'intégration continue ou de livraison continue. Dans cet état…

  • Vous commitez dans la branche principale et attendez nerveusement que quelqu'un vous le reproche.
  • Votre ligne de code principale est instable.
  • Les bugs se cachent dans un enchevêtrement de changements de code, et vous redoutez les efforts à venir pour les identifier (et pire encore, les corriger) parce que vous avez travaillé sur cette zone de code il y a tellement longtemps.
  • Lorsque les testeurs veulent tester une fonctionnalité, ils doivent déranger tous les développeurs pour se renseigner sur l'état actuel et trouver une version fonctionnelle.
  • La livraison nécessite un gel du code. Quelqu'un devient un goulot d'étranglement artificiel pour les changements de code afin qu'il puisse stabiliser la livraison. Pendant ce temps, personne n'arrête vraiment de travailler. Vous arrêtez juste de commiter des changements de code, ce qui signifie qu'un torrent de code non testé inonde votre dépôt comme autant d'eaux usées non traitées dès que le gel est levé.

Erreur | CI/CD Atlassian

Si cette histoire vous évoque quelque chose, sachez que tout espoir n'est pas perdu.

Réfléchissez à la façon dont « inspecter et adapter » a amélioré votre processus de planification, et extrapolez cela dans les processus de développement et de livraison. Imaginez que vous puissiez détecter des problèmes dans chaque commit effectué. Maintenant, imaginez que vous puissiez détecter des problèmes sur votre poste de travail local, avant même de faire un commit. Ce que vous venez d'imaginer est essentiellement la raison pour laquelle Agile a besoin de la livraison continue : les développeurs ont besoin de feedback rapide.

Ce qui est formidable dans le parcours vers la livraison continue est qu'il démarre avec vous. Vous n'avez pas à le promouvoir auprès de qui que ce soit, ni à convaincre votre équipe que vous devriez être plus comme Etsy. Et personne n'utilise de technologie si unique qu'elle échappe aux principes, pratiques et outils de base de la livraison continue. Vous pouvez dès maintenant appliquer des pratiques qui vous simplifieront la vie.

Commencez par un script et un serveur

Par le passé, Make était la seule option, mais beaucoup de développeurs craignaient les bugs liés aux espaces. Plus tard, Ant a remplacé les espaces par des crochets. Maintenant, vous pouvez ignorer ces générations précédentes. Bien sûr, vous verrez toujours de nombreux projets open source utilisant Maven ou même Ant. Mettez cela sur le compte des vieilles habitudes. Mais vous pouvez recourir aux langages de développement XML comme option de secours.

La dernière génération de langages de développement est beaucoup plus facile à apprendre et à utiliser. Dans la plupart des cas, vous pouvez utiliser un langage de développement écrit dans la même langue que la vôtre pour développer votre application, ce qui vous simplifie la vie (et celle de votre équipe).

Tableau du langage de code et outil recommandé correspondant | CI/CD Atlassian

La partie « continue » de la livraison continue implique d'obtenir du feedback sur chaque commit, c'est pourquoi les serveurs de build écouteront automatiquement votre dépôt et déclencheront un build en cas de changement. Être continu implique également de réparer le build en cas de problème. En tant que développeur, vous bénéficiez de l'isolement du changement. La meilleure façon d'éviter des correctifs de bugs complexes et difficiles est de les empêcher de s'accumuler en premier lieu. Les serveurs de build, comme Bamboo, sont faciles à installer. Initialement, le but est simplement d'exécuter votre script de développement dans un environnement propre. Dans un sens, la première fonction de votre serveur de build est de vous aider à détecter les problèmes dans votre script de développement.

Commencez à détecter les problèmes automatiquement

Comme vous pouvez l'imaginer, votre serveur de build peut détecter bien plus que des problèmes grâce à votre script de développement. Il y a des choses faciles comme activer les avertissements du compilateur (pour certains langages) et des choses plus difficiles que chaque coach Agile défendra comme les tests automatisés. En effet, les tests uniquement manuels sont un goulot d'étranglement pour la livraison continue. Si vous débutez avec des tests automatisés, recherchez la couche (unité, intégration, acceptation, interface utilisateur) qui vous fournira le feedback le plus rapide.

Mettons fin à la controverse : les tests automatisés ne constituent PAS une menace pour les testeurs manuels.

En fait, les testeurs humains font d'excellents guides quand il s'agit de décider ce qui doit être (ou non) automatisé. Une stratégie d'automatisation intelligente repose sur la question : « Quels types de problèmes seraient les plus utiles à détecter ? » Vous avez besoin d'humains expérimentés qui se spécialisent dans la qualité logicielle pour y répondre.

Les graines de la livraison continue

Tout le monde peut se lancer. Mais si vous êtes le seul à appliquer ces principes, personne ne parlera de livraison continue. L'étape suivante consiste à insuffler ces pratiques essentielles dans votre équipe.

Inspirez-vous de livres et d'articles sur l'intégration continue et les tests Agile. Plus tard, vous trouverez de plus en plus de raisons pour lesquelles être prêt au déploiement est utile. Ensuite, vous pouvez vous inspirer de la livraison continue et du déploiement continu.

Le point de départ est assez similaire pour tout le monde, mais le résultat final sera quelque chose d'unique à votre produit et à votre entreprise.