Haut de page

Mettre en place votre infrastructure DevOps


Publié par
Edouard Dorcier

7 mars 2018

J’ai récemment pu faire l’expérience de la mise en place de l’ensemble de la suite Atlassian (Crowd, Jira, Confluence, Bitbucket et Bamboo) de A à Z, chez un client. L’objectif de cette entreprise était de gérer ainsi la réalisation des projets informatiques en agilité : depuis la documentation, en passant par l’automatisation des tests (unitaires puis fonctionnels), et jusqu’au déploiement en production.

Nous n’avons donc pas réinventé la roue, puisque ce process est décrit par de nombreux acteurs du marché et que les différentes méthodes utilisées pour articuler les différentes phases entre elles, sont souvent bien connues. Scrum ou Kanban pour l’agilité, Git et Git Flow pour le développement et les principes de l’intégration et/ou du déploiement continus.

Cette mission m’a permis d’approfondir mes connaissances sur les liens qui unissent les différentes applications entre elles et sur les forces de la suite Atlassian par rapport aux autres applications du marché. Je vais donc partager tout cela avec vous à travers cet article.

La documentation

L’agilité implique d’avoir constamment de la matière pour « nourrir » les équipes de développement. Jira Software propose de nombreuses fonctionnalités qui simplifient et fluidifient les interactions entre le Product Owner (le client de l’application) et les développeurs :

  • la représentation du backlog produit & les possibilités de présentation et d’ordonnancement de ses demandes
  • la création et le démarrage de sprints en quelques clics
  • les tableaux de suivi adaptables à vos processus de développement
  • les rapports de suivi sur le travail effectué (en particulier les rapports par sprint)

C’est aussi ici que Confluence peut proposer un renfort intéressant pour Jira Software. Nous nous en sommes ici servis de base documentaire. Finis Word, PDF, Excel… Finis les répertoires présents sur différents serveurs, sans aucun suivi structuré… Finies les recherches dans les piles d’eMails afin de récupérer l’information intéressante. Désormais, tout est centralisé dans un espace Confluence lié au projet de développement.

Un nouveau projet ? Je crée un espace Confluence dédié, avec des droits restreints à l’équipe en charge. Le cahier des charges initial est écrit dans une nouvelle page, gérée dans cet espace, sous la page principale. Chaque grosse fonctionnalité qui peut constituer une Epic est ensuite créée sous cette page. Les spécifications fonctionnelles sont écrites dans une autre page, au même niveau que le cahier des charges et sont structurées de la même manière.

Confluence permet ensuite de créer une nouvelle demande de type Epic dans Jira pour chaque fonctionnalité, à partir d’une simple sélection de texte dans la page Confluence :

De même, en créant un tableau dans une page concernant une fonctionnalité, et si une Epic est déjà liée à cette page, vous pourrez en sélectionnant une partie de ce tableau créer une Story par ligne. Elle sera directement liée à l’Epic ! Vous n’avez qu’à sélectionner la colonne contenant le titre et celle contenant la description, et le tour est joué.

Les demandes sont automatiquement créées dans votre projet, liées à l’Epic et prêtes à être utilisées dans votre backlog. De plus, chaque demande Jira contiendra le lien qui vous ramène automatiquement vers la page Confluence où vous pouvez décrire le plus exhaustivement possible votre demande, ou encore ajouter des schémas ou des maquettes. Et inversement, les tickets Jira sont visibles depuis la page Confluence de l’Epic, vous offrant ainsi une vue globale de l’ensemble des Stories liées et leur avancement. Il n’y a alors qu’un point d’entrée pour la documentation et vous n’avez plus besoin d’aller dans Jira pour créer de nouvelles Stories. Au contraire, il suffit par exemple de créer un nouveau tableau et de rajouter une ligne pour chaque nouvelle demande, puis de recommencer le processus de création. C’est simple et efficace.

Le processus de développement

Les pratiques d’intégration continue et les méthodologies de développement, comme le Test Driven Development, ont énormément apporté à la qualité des développements et à la vie des développeurs. Mais il faut bien admettre que ces méthodes sont parfois difficiles, d’une part, à comprendre, d’autre part, à implémenter. Ce fut le cas ici pour l’utilisation de Git Flow.

Pour un débutant, l’utilisation de Git, de ses commandes et sa philosophie sont déroutantes. Si vous ajoutez par-dessus tout ça la notion de Git Flow, qui organise le développement de nouvelles fonctionnalités, les releases, les mises en production et la correction d’anomalies en production,  vous avez perdu une partie de vos équipes. Il va donc falloir organiser vos processus et former les principaux concernés : développeurs, Product Owner, responsables des releases…

Nous avons utilisé Bitbucket. Il nous a permis, à l’instar de Github ou Gitlab, de gérer les dépôts Git distants. Nous avons défini un projet par application (ou programme). Puis, nous avons créé autant de dépôt que nécessaire (frontend, backend, service). Nous avons ainsi pu configurer des autorisations au niveau du projet (en particulier, les droits en lecture et en écriture) ou du dépôt (pour les différentes actions Git en affinant par type de branche).

Nous avons également défini un modèle de branches pour effectuer une première implémentation de Git Flow, sans s’encombrer du plugin git-flow pour Git, et donc de commandes supplémentaires. Dans ce modèle coexistent les branches master, develop, features, releases et hotfix.

Ce modèle de branches est intéressant pour une meilleure organisation de vos dépôts. En effet, Git Flow demande une grande rigueur et de l’apprentissage de la part des développeurs. Les fonctionnalités proposées par le lien natif entre Jira Software et Bitbucket permettent de guider les développeurs et d’éviter les erreurs. Voyons deux cas concrets où cette intégration entre Jira Software et Bitbucket aide particulièrement les équipes.

Développement des Stories

Notre cas d’utilisation ici concerne le développeur : que se passe-t-il une fois qu’un Sprint a été défini et chiffré ? Le sprint commence et un développeur prend une Story dans le Sprint Backlog. Il se rend dans l’écran de la demande et clique sur « Créer une branche ». Il choisit comme branche de départ la branche develop et choisit le type de branche Feature. Il n’a plus qu’à récupérer les informations du dépôt distant en local et à travailler sur sa branche. Le tout en deux clics !

Le nom de la branche est proposé automatiquement lors de sa création. Ce qui élimine les risques d’erreur.

De la même manière, les commits doivent contenir l’identifiant de la demande Jira correspondante afin d’être recensés en son sein. La difficulté ici est d’enseigner les bonnes pratiques aux développeurs.

Pour guider au maximum les développeurs, nous avons utilisé l’app de Bitbucket « Yet Another Commit Checker ». Cet app permet de vérifier (entre autre) la relation entre l’utilisateur connecté à Bitbucket et le nom et l’adresse email fournis dans le commit (usurpation d’identité), puis de valider le contenu du message de commit afin d’imposer la saisie d’un identifiant de demande Jira valide.

Lancement d’une release

Maintenant mettons-nous dans la situation où l’équipe vient de terminer un sprint Scrum. Développeurs, Scrum Master et Product Owner sont alors d’accord sur l’ensemble des fonctionnalités proposées par le produit et décident de lancer le processus de mise en production. En réunion, l’équipe crée alors conjointement :

  • une branche release depuis la branche develop qui porte le numéro de la version

  • la version cible dans le projet Jira et y ajoute l’ensemble des Stories de ce sprint, et potentiellement des sprints précédents qui n’ont pas fait l’objet d’une release.

Encore une fois, ce sont des actions simples qui ne demandent que quelques clics et la saisie d’un champ de formulaire. Conjointes, elles permettent de fixer en parallèle dans les deux applications le périmètre fonctionnel de la release et de faciliter les travaux de documentation (potentiellement dans Confluence) et de tests de la part des équipes métier. Si des bugs sont détectés, ils peuvent également être inclus facilement dans la version cible.

Le déploiement continu

Entre en scène Bamboo ! Grâce à ses liens avec Bitbucket et Jira Software, nous avons pu automatiser certaines tâches, trop chronophages pour les développeurs.

Les builds

Nous avons ici opté pour un plan de build unique, associé à un plan de déploiement unique. Le but avoué était de simplifier la configuration et donc la maintenabilité de l’ensemble.

Dans ce plan de build, un script vérifie sur quel type de branche le commit a été effectué et décide de mener certaines actions en fonction :

  • la branche develop sert de branche de base. A chaque commit, le plan de build est lancé et permet la création du livrable.
  • un plan est créé en plan de branche pour la master. Lorsqu’un commit est détecté sur cette branche, le livrable est créé, puis publié (sur un dépôt Nexus par exemple).
  • un plan est créé automatiquement pour chaque branche feature. Une compilation du projet et une revue de code sont effectuées à chaque commit sur une de ces branches.
  • un plan est créé automatiquement pour chaque branche release ou hotfix créée. Ces plans sont lancés manuellement par le développeurs et aboutissent à la création du livrable.

Suite du développement d’une Story

Nous avons vu plus tôt que nous pouvions désormais créer un branche feature simplement. La nommer avec l’identifiant de la demande Jira associée nous a permis de la lier sans effort au plan de build associé.

 

Sans presque rien toucher, nous avons donc une traçabilité supplémentaire de notre produit.

Suite de la release

De la même manière, la vue des demandes associées à une release nous présente les branches Jira, mais également les builds qui ont été effectués. Le métier peut donc connaître les demandes qui ont été déployées en recette ou en qualification (pratique pour les tests réguliers et la finalisation des releases).

Les déploiements

Il en va de même pour les déploiements ! Chaque build peut être ensuite déployé sur un environnement propre. Nous avons pour notre part créé un plan de déploiement par dépôt et créé à l’intérieur, autant d’environnement que nécessaires. Une fois ces déploiements effectués, ils sont liés aux demandes Jira correspondantes. Tout est disponible au sein de la fiche et même dans le récapitulatif de la release associée.

Conclusion

La mise en place des outils Atlassian constitue une brique fondamentale dans le cadre d’une transition vers l’agilité et le déploiement ou l’intégration continu. Les différents liens entre les applications ont permis de fluidifier activement les processus. Quelle que soit l’évolution, la documentation est effectuée dans Confluence et liée à des demandes Jira. Durant le cycle de vie de ces demandes, le travail effectué (écriture de code, build, déploiement) y est directement consigné. Tout peut être tracé avec un minimum d’effort, ce qui permet à chacun de se concentrer sur le coeur de son métier.

Cependant, cette installation et ce paramétrage ne garantissent pas pour autant à eux seuls la réussite de cette transition. L’essentiel du travail consiste à définir en avant tous les processus à implémenter dans les outils. Cela se fait à travers des ateliers, des réunions et des discussions successives, impliquant les différents acteurs du changement. Les points de blocage techniques ou fonctionnels qui peuvent se présenter seront abordés à ces occasions.

Sur le projet détaillé dans cet article, nous avons par exemple défini qu’une demande d’évolution ou un cahier des charges pouvaient contenir une ou plusieurs fonctionnalité, elle(s)-même(s) correspondante(s) à une Epic dans Jira. Tout peut donc être structuré à partir de là. Le cycle de vie des Epic devient le cycle de validation documentaire. Chaque fonctionnalité possède une page à part entière, qui comporte un lien vers l’Epic et dans laquelle seront définies les User Stories, selon le principe défini au préalable. Ces dernières suivront leur propre cycle de vie et seront davantage conformes aux méthodes agiles.