Pour une livraison sans stress

Cette vidéo vous garantit de réduire le niveau de stress avant la sortie de votre prochain blockbuster

Laura Daly Laura Daly
Parcourir les rubriques

La meilleure mesure de la réussite d'une équipe Agile est la mise à disposition de logiciels fonctionnels aux clients. Mais même les équipes de développement expérimentées souffrent lorsqu'il s'agit de valider des tickets terminés par rapport à des artefacts ; les revues de code ont été sautées, le code n'a pas été mergé, les builds pour du code mergé échouent… Cela vous semble familier ?

Dans cette présentation, vous découvrirez :

  • Les bonnes pratiques de programmation pour améliorer votre capacité à livrer des produits de qualité. Découvrez pourquoi les revues de code sont essentielles pour garantir la qualité, et comment le suivi et la correction des builds défaillants permettront de garantir un délai de livraison plus court.
  • Comment configurer et maximiser le hub de livraison Jira Software. Découvrez comment économiser des heures de travail en permettant au hub de livraison de fournir une image claire de l'avancement et de l'état d'une version.
  • Automatisation complète du build, du code à la livraison. Simplifiez votre workflow en livrant votre version directement depuis le hub de livraison.

Regarder et apprendre

Questions réponses

Nos hôtes, Jason Wong et Megan Cook, ont sélectionné leurs Q&R préférées de cette présentation. Poursuivez votre lecture pour découvrir comment effectuer des livraisons fructueuses et sans stress.

Q1 : Quels sont les trois principaux facteurs non techniques qui font le succès du hub de livraison ?

R1 : (1) Livrez en toute confiance : les parties prenantes au sein de l'équipe et en dehors pourront savoir exactement ce qui est prêt à être livré à tout moment du cycle de livraison.

(2) Gagnez du temps, accélérez la prise de décision : sachez automatiquement et instantanément quelles fonctionnalités sont prêtes à être livrées et quelles sont celles qui posent problème. Le hub de livraison vérifie pour vous tous les tickets de votre version, afin que vous n'ayez pas à rapprocher manuellement les tickets et le code.

(3) Enregistrement des versions : déterminez ce qui a été livré (quand et dans quelle version) en examinant les versions livrées, et ce qui est actuellement planifié pour chacune des versions à venir en examinant les versions non livrées.

Q2 : En principe, qui gère la livraison des versions au sein d'Atlassian ?

R2 : Au sein d'Atlassian, chaque équipe a sa propre approche, mais en général, nous essayons d'automatiser le plus possible le processus, afin que les corrections de bugs de production ou la livraison d'une nouvelle version d'une correction de bug d'un produit puissent être effectuées par n'importe quel développeur de l'équipe à moindre coût.

Les équipes ont généralement une liste de tâches à accomplir, mais nous essayons de la réduire autant que possible. Des outils tels que le hub de livraison aident dans ce processus à s'assurer que ce que nous prévoyons de livrer est de haute qualité et qu'il n'y a pas de décalage entre l'état des tickets Jira Software et leur développement réel.

Certaines des plus grandes équipes (par exemple Jira Software et Confluence) auront en fait une rotation dédiée pour un Bug Master/Release Manager qui gère toutes les versions.

Pour les versions majeures et mineures plus importantes, une personne dédiée s'occupe généralement de la livraison, s'assurant que le périmètre est géré, et que tout le travail précédant la livraison est géré en fonction des risques et du temps. Ce travail peut être supervisé par un chef d'équipe ou un responsable du développement, mais nous essayons de faire en sorte qu'il y ait une rotation parmi les membres de l'équipe afin que chacun connaisse le processus et comprenne les exigences à respecter pour livrer un logiciel de qualité.

Pour la planification du calendrier, les chefs d'équipe se concerteront avec les responsables produits et le service marketing pour définir les attentes quant au moment où une version sera prête, et si le périmètre ou le temps doit être géré. Les décisions concernant les fonctionnalités qui seront livrées dans les différentes versions sont prises par ces personnes.

Q3 : Comment faire pour associer une branche, un commit, une pull request, un build ou un déploiement à un ticket ?

R3 :

1. Branche : ajoutez la clé de ticket au nom de la branche
2. Commit : ajoutez la clé de ticket au message de commit
3. Pull request : ajoutez la clé de ticket au nom de la branche source, ajoutez le message de commit ou le titre de la pull request
4. Build : ajoutez la clé de ticket dans un message de commit
5. Déploiement : ajoutez la clé de ticket dans un message de commit inclus

Q4 : Quelle est votre expérience en matière de gestion des conflits qui surgissent lorsqu'on travaille sur un même code pour des branches de ticket isolées ?

R4 : D'après notre expérience, cela pose rarement problème. La plupart des tickets présentent peu de chevauchement dans le code, mais il arrive que des conflits surviennent.

Généralement, deux problèmes se posent :

  • Branches de fonctionnalité longues, isolées du reste du développement
  • Tâches de refactoring massives, qui doivent être séparées jusqu'à ce qu'elles soient terminées, testées et prêtes à être livrées.

Pour le premier, une option sérieuse consiste à procéder au développement et à réaliser une intégration régulière, tout en marquant les fonctionnalités par des flags, rendant ainsi les changements en cours uniquement visibles pour vos équipes internes ou des clients spécifiques. Cela permet de garantir l'intégration continue de code contradictoire, et de minimiser les risques de conflit ainsi que les risques et l'impact lorsqu'un élément important est ajouté à la branche principale de développement.

Si cela n'est pas possible, et dans le cas de refactorings importants, nous veillons à ce que la branche de développement soit intégrée dans la branche de fonctionnalité aussi souvent que possible (en mergeant les changements apportés sur la branche de base/de développement dans la branche de fonctionnalité). Cela garantit que tout le développement en cours est terminé et testé par rapport à la branche de fonctionnalités longue aussi souvent que possible. En cas de conflit de merge, il est beaucoup plus facile de faire en sorte que les personnes qui ont apporté les changements aident à résoudre les conflits de merge ou, du moins, qu'elles en limitent le périmètre afin que la résolution soit plus facile.

La meilleure solution est de diviser tout travail en blocs qui peuvent être mergés dans la branche stable ou de développement aussi souvent que possible. Cela minimise les chances que des changements soient apportés simultanément aux mêmes fichiers dans des branches de fonctionnalités.

Q5 : Quelle stratégie recommandez-vous pour gérer des branches parallèles pour le développement continu (fonctionnalités), les hotfix et leur déploiement dans différents environnements (QA/staging/production) ?

R5 : Nous avons documenté un certain nombre de stratégies de branche sur la partie de notre site web dédiée à Git notamment la section Comparaison de workflows.

Vous trouverez plus d'informations avancées dans des conférences précédentes. Getting Git Right et les workflows de déploiement continu sont abordés plus en détail dans la vidéo Git workflows for SaaS teams (Workflows Git pour les équipes SaaS).

En bref, il existe deux workflows prédominants : un workflow de livraison des produits téléchargeables et un workflow SaaS pour les services en ligne (workflow Git pour les équipes SaaS).

Pour les produits téléchargeables, la plupart des équipes utilisent une variante de workflow Gitflow dans laquelle la branche principale est utilisée pour le développement en cours, et chaque livraison mineure précédente dispose de sa propre branche, à partir de laquelle des branches de correction de bugs sont créées et mergées. Lorsque cela est nécessaire, une version de correction de bugs est développée. Chaque branche de livraison antérieure merge tous les changements en aval des livraisons ultérieures et de la branche principale pour s'assurer que toutes les corrections de bugs sont incluses dans toutes les versions ultérieures.

Q6 : Le hub de livraison fonctionne-t-il bien avec Kanban et des livraisons fréquentes ?

R6 : Oui, cela fonctionne très bien. Le bouton Livrer du tableau Kanban peut être utilisé pour créer une version contenant tous les tickets relatifs à cette livraison. Une fois que cette version est créée, le hub de livraison peut être utilisé pour vérifier les éventuels avertissements ou pour se faire une vue d'ensemble de la version.

Même sans le tableau Kanban, vous pouvez créer une version à tout moment et y ajouter des tickets, même si ces tickets ont été classés comme terminés. Le hub de livraison peut alors être utilisé pour vérifier les éventuels avertissements afin de s'assurer que la version est prête.

Q7 : Le hub de livraison peut-il afficher des informations sur des tickets provenant de plusieurs projets Jira Software, ou le hub de livraison est-il spécifique du projet et de la version de correction ?

R7 : Un hub de livraison est une vue détaillée d'une version. Puisque les versions sont spécifiques de projets, le hub de livraison est, par conséquent, également spécifique d'un projet.

Q8 : Pouvez-vous faire en sorte que les avertissements du hub de livraison soient automatiquement renseignés dans un groupe Hipchat ?

R8 : Nous n'avons pour l'instant pas d'intégration entre les avertissements du hub de livraison et Hipchat, et n'avons pas l'intention d'en créer un pour le moment. Nous avons réfléchi aux différentes façons dont le hub de livraison pourrait améliorer la collaboration en équipes grâce à Hipchat, et nous aimerions avoir l'avis de nos clients sur la façon dont ils pourraient utiliser cette intégration ou toute autre intégration avec nos autres produits.

Q9 : À quoi le bouton Livrer est-il connecté ? À un script à déployer sur votre serveur de production en tant que tâche dans Bamboo ?

R9 : Le bouton Livrer est associé à quelques fonctions :

  • Il peut fixer la date de livraison et changer l'état d'une version à « Livrée ». Si un ticket est ouvert dans cette version, vous aurez la possibilité de déplacer ces tickets vers une autre version. Ces options sont disponibles avec ou sans l'intégration à Bamboo.
  • Lorsque Bamboo est intégré à Jira Software, le bouton Livrer peut être utilisé afin de lancer un nouveau build, qui peut être configuré dans Bamboo pour prendre les mesures nécessaires à la livraison de votre version (par exemple, un script à déployer en production ou produire un nouvel artefact).
  • Le bouton Livrer peut également être utilisé afin de lancer une étape manuelle pour un build Bamboo qui a été exécuté. Cela vous permet d'avoir un build qui s'exécute automatiquement et une étape optionnelle, qui n'est déclenchée que manuellement et qui effectue réellement le déploiement/la livraison. (Cette étape serait équivalente à l'ensemble du build dans l'option n° 2, mais peut utiliser les artefacts que le build produit lors de son exécution).

Q10 : Prévoyez-vous d'intégrer le hub de livraison à Github/Github Enterprise ?

R10 : Le hub de livraison fonctionne déjà avec GitHub et GitHub Enterprise. Vous devez simplement connecter votre instance Jira Software à votre compte GitHub en utilisant les comptes du système de contrôle de version décentralisé (DVCS) que vous trouverez dans le menu d'administration des extensions de Jira Software. Vous pourrez alors commencer à suivre l'avancement de n'importe quelle version grâce aux informations de développement correspondantes incluses dans le hub de livraison.