Industrialisez votre workflow de développement

16 Mar 2020 | Développement, Node.js, PHP

Quand les clients de CFD-Innovation commencent à utiliser les solutions de développements Open Source comme PHP ou Node.js sur IBM i, ils démarrent souvent par un POC. Dans le meilleur des cas, celui-ci se fait dans un environnement de développement (machine, partition ou liste de bibliothèques). Une fois convaincu par le POC, nous basculons la première application en production ! 🙂 Le plus souvent, les premières MEP (Mises En Production) restent manuelles, mais il faut vite penser à « procédurer » et à industrialiser ces workflows. En effet, il sera plus difficile de le mettre en place quand les projets seront plus importants : augmentation du nombre de développements et de MEP, agrandissement des équipes de développement…

Mais que faire et comment s’outiller pour industrialiser les workflows applicatifs ? Par où commencer ?

La première approche de CFD-Innovation est l’adoption d’un outil de versionning comme SVN ou Git. C’est un outillage incontournable pour la suite. Comme son nom l’indique, ce type d’outils va permettre de gérer les versions du code au fur et à mesure des modifications. Voici les principales raisons d’adopter une solution de versionning :

Garder un historique des modifications (traçabilité à la ligne de code !)

L’auteur
La date et l’heure
L’explication
Les fichiers modifiés et leurs modifications

Faciliter les retours en arrière (rollback)
Travailler en équipe (mais pas uniquement ! Très utile même pour un développeur seul)

Une fois ce premier pas effectué, nous pouvons aller plus loin avec l’adoption d’un outil centralisant la vie de notre application (de notre code, mais pas que !). Dans les fonctionnalités intéressantes d’un tel outil, on retrouve des systèmes de gestion de tickets, de gestion d’équipes, de documentation, d’intégration continue etc…

Pour ce type de fonctionnalités, CFD-Innovation travaille avec GitLab. Premièrement et à l’instar de GitHub, il permet la configuration d’un dépôt « remote » permettant de réaliser des sauvegardes externes à l’environnement de développement et de faciliter le travail en équipe en mettant à disposition du code dans un endroit partagé. La solution peut être utilisée en mode Cloud avec des projets privés ou publics, mais aussi en OnPremise.

En plus des fonctionnalités d’un remote git, GitLab propose des fonctionnalités de gestion de projet de développement très efficaces :

Un système de tickets pour gérer les tâches de développements, les bogues ou des sujets de discussions. Ce système permet de suivre de façon claire l’avancement des développements, dans des représentations de type Kanban.

Un wiki pour centraliser toute la documentation autour d’un projet (documentation technique, documentation fonctionnelle), le tout versionné pour garder une trace de l’historique de la documentation au même titre que le code.

Des fonctionnalités de CI/CD (Continuous Integration / Continuous Deployment) qui ne seront pas explorées dans cet article de blog.

Nous voilà maintenant outillé ! Nous pouvons alors passer à la mise en œuvre d’un processus pour aller d’un environnement dédié au développement, à celui de production en passant par celui de recette.

Chaque projet et chaque contexte sont à étudier mais voici un exemple de workflow applicatif simplifié, appliqué par CFD-Innovation, utilisant le système des branches Git. Il est important de prendre en compte que le workflow à mettre en œuvre dépendra de nombreux facteurs comme les ressources humaines impliquées, le type d’application, le nombre de MEP, les moyens informatiques à disposition…

Le développeur travaille en local dans son projet de développement. Assez régulièrement, et dès qu’une petite fonctionnalité (sprint au sens SCRUM) est terminée, il pousse son développement dans une branche « dev » sur le git remote.

Une fois la fonctionnalité entière terminée (et prête à passer en test), le développeur crée une « merge request » permettant de soumettre à validation son développement à une tierce personne (chef de projet, responsable informatique…) pour le passer en recette.

Cette dernière vérifie le code et passe les développements en recette en acceptant la merge request.

Les utilisateurs ciblés testent la version en recette jusqu’à la valider (ou non).

Le responsable de l’environnement de recette procède alors à « une merge request » vers la branche de production.

La personne habilitée à gérer l’environnement de production vérifie à son tour le code et passe les développements en production en acceptant la merge request.

Le graphique ci-dessous explicite un peu plus ce workflow en y ajoutant un circuit parallèle pour les hotfix.

Exemple GitFlow

Cet article vise à appréhender quelques outils et méthodologies permettant d’industrialiser les workflows de développements. Comme mentionné plus haut, chaque projet étant unique, tous les cas ne sont bien entendu pas explicités ici.

Pour en savoir plus dans votre contexte, contactez-nous !

Merci à Arnaud ROYO pour le travail effectué au sein de CFD-Innovation sur ces sujets.

Coordonnées

gdumas@cfd-innovation.fr