Il n'y a pas si longtemps, lors de l'un des projets de notre entreprise, il a été décidé d'abandonner définitivement l'utilisation de Subversion pour le stockage et le versioning du code au profit de Git.
Les principaux objectifs de la transition étaient les suivants:
- Amélioration de la transparence du processus de développement.
- Implémentation de la procédure de révision obligatoire du code avant de mettre à jour les mises à jour des environnements de test.
- Implémentez une intégration continue pour créer des mises à jour après examen du code et les installer sur des environnements de test.
Une condition préalable pour atteindre ces objectifs était l'utilisation de GitLab (ce serveur Git était déjà utilisé par le client et il y avait déjà du code qui appartenait à l'avant de la solution) et Jira (également déjà utilisé par le client).
Il a été proposé d'utiliser Git Flow comme modèle de développement cible, en y ajoutant un code de révision. Ce modèle de développement de facto est devenu la norme dans le développement de logiciels open source et est utilisé par la plupart des géants de l'industrie. C'est pourquoi son support est intégré à de nombreux outils populaires pour travailler avec Git. Un grand nombre de documents ont été écrits sur le sujet de son utilisation; je citerai les plus réussis pour la familiarisation initiale: un et deux .
En soi, ce modèle n'offre que des principes généraux de maintenance du code, en laissant de côté les processus accompagnant son écriture. Par conséquent, l'implémentation de tout le reste, y compris le code de révision, dépend du serveur Git spécifique. À cet égard, GitHub est le plus pratique: il a été initialement conçu comme une plate-forme pour la collaboration d'un grand nombre de développeurs indépendants et vous permet de limiter les droits d'envoyer des commits (Push) dans le référentiel avec la possibilité de créer des demandes d'envoi de code. De plus, GitLab propose son propre workflow de gestion du code appelé GitLab Flow, conçu pour utiliser GitLab CI. Par conséquent, dans GitLab, la fonctionnalité de création de demandes d'envoi de code n'est pas implémentée et il est proposé d'utiliser des demandes de fusion de branche pour examiner le code de modification. Pour créer et installer des artefacts sur le projet, Jenkins était déjà utilisé, ce qui vous permet de créer et de configurer de manière flexible des tâches d'assemblage et de déploiement, et il a été décidé de ne pas passer à GitLab CI, rejetant simultanément l'idée d'utiliser GitLab Flow.
Je note également que le projet a été configuré des intégrations dans Jira et Git. Dans Jira, dans le plugin Git, un référentiel créé pour stocker le code source a été ajouté pour le suivi, et dans GitLab, ce référentiel a été configuré pour s'intégrer à Jira dans la section "Intégrations" du référentiel.
Pour résoudre ce problème, un flux de travail pour travailler avec du code a été développé, dont la structure est similaire à Git Flow, mais qui permet d'effectuer des révisions de code chaque fois que des modifications sont apportées aux principales branches de processus (develop, release-n et master) à l'aide de GitLab. Ensuite, le processus résultant sera décrit, ainsi que les étapes de l'intégration continue et de la livraison de logiciels aux chaînes adjacentes. Entre parenthèses sont les commandes correspondantes à exécuter.
Le référentiel créé pour stocker le code source est téléchargé dans le référentiel local (git clone) et Git Flow (git flow init) y est initialisé - en plus de la branche master (pour créer des balises afin de stocker des versions stables), la branche develop est créée (la branche principale de développement, dans qui intègre les branches de fonction, les versions et les correctifs), des masques sont définis pour les branches de fonction, les versions et les correctifs, et une transition est effectuée vers la branche de développement.
Ensuite, la branche de code source actuelle de Subversion est transférée vers la copie de travail, le code est validé (git add -A + git commit -m "Commit message") dans la branche develop du référentiel local et son téléchargement vers le référentiel distant (git push origin develop). Après cela, vous pouvez commencer à développer de nouvelles fonctionnalités à l'aide de Git pour versionner le code.
Pendant le développement, la version actuelle de la branche develop est téléchargée et des branches sont créées à partir de celle-ci pour le développement de nouvelles fonctions (fonction de flux git start MYFEATURE) conformément aux codes de tâche Jira dans lesquels le développement est en cours.
Une transition vers la branche créée (git checkout MYFEATURE) est automatiquement effectuée, la fonctionnalité planifiée est développée et les modifications sont validées dans la branche locale MYFEATURE (git commit -m «Commit message»). Notez que pour une intégration correcte de Git et Jira, le code de validation dans Jira auquel ce correctif s'applique doit être indiqué dans les messages de validation. Ces validations seront ensuite affichées dans les tâches qui leur correspondent, ainsi que dans la section «Git commits» du projet, à l'aide de laquelle vous pouvez déterminer sans ambiguïté ce qui est inclus dans une version particulière.
Lorsque la fonctionnalité de la tâche sélectionnée est développée et prête à être soumise à l'environnement de test, les validations créées sont téléchargées vers la branche distante avec le même nom (git push -u origin MYFEATURE) et une demande de fusion de la branche téléchargée avec la branche develop est faite au chef d'équipe ou à ses fonctions intérimaires.
Pour demander une fusion, le développeur résout les conflits de fusion (le cas échéant) et le responsable de l'équipe de développement (ou agissant) produit une révision du code, au cours de laquelle il est possible de créer des validations supplémentaires (git commit -m "Message de validation") avec des corrections des commentaires reçus. lors de la révision du code, dans une branche avec de nouvelles fonctionnalités et en les envoyant au dépôt central (git push -u origin MYFEATURE). Après la réussite de l'examen, le chef d'équipe (ou intérimaire) confirme la fusion des succursales. Ici, il n'est pas superflu de définir l'indicateur de suppression de la branche après la fusion - sinon le nombre de branches peut rapidement atteindre des échelles indécentes.
Pour assurer une intégration continue dans le référentiel GitLab, un Web Hook est configuré dans la section "Intégrations", qui appelle les tâches Jenkins pour construire et installer de nouvelles fonctionnalités sur l'environnement de test. Jenkins, en utilisant un plug-in pour travailler avec Git, télécharge le code source, obtient le nom de la tâche et utilise l'API Jira pour demander une liste des composants qui ont été modifiés et doivent être assemblés, démarrer le processus de construction, exécuter les tests unitaires et charger les artefacts créés s'ils réussissent. sur Sonatype Nexus et les installe dans un environnement de test. Si, à l'une des étapes, un échec se produit ou que les tests unitaires échouent, à l'aide du plug-in Telegram, l'équipe de développement est informée du résultat de la génération. Si l'installation a réussi, l'équipe QA est avertie que la tâche est prête pour les tests.
Si des défauts apparaissent, la version actuelle de la branche develop est téléchargée et à partir du commit de fusion de la branche MYFEATURE avec la branche develop, la branche hotfix-MYFEATURE est créée (git checkout [BASECOMMIT] -b hotfix-MYFEATURE).
Lors de la création, une extraction est automatiquement effectuée dans la branche créée, des corrections sont apportées et des modifications sont validées dans la branche locale hotfix-MYFEATURE (git commit hotfix-MYFEATURE -m «Commit message»). Une fois la correction terminée et prête à être envoyée à l'environnement de test, ils sont poussés vers une branche distante du même nom (git push -u origin hotfix-MYFEATURE) et une demande de fusion est créée avec la branche develop.
Pour demander une fusion, le développeur résout les conflits de fusion (le cas échéant) et effectue une révision du code, au cours de laquelle il est possible de créer des validations supplémentaires avec des corrections des commentaires reçus. Une fois l'examen terminé, les succursales fusionnent. Immédiatement après le transfert du correctif à la branche de développement, le Web Hook fonctionne également pour appeler la tâche dans Jenkins pour générer, exécuter des tests unitaires, charger les artefacts créés dans Sonatype Nexus et installer le correctif sur l'environnement de test. Un mécanisme de notification similaire fonctionne pour les corrections.
Si tous les défauts sont corrigés, la version actuelle de la branche develop est téléchargée et de la validation de fusion de la branche hotfix-MYFEATURE à la branche develop, la branche release-mn est créée (git flow release start RELEASENAME [BASECOMMIT]).
La création d'une branche de publication initialise également le lancement d'un Web Hook pour appeler une tâche dans Jenkins, qui télécharge le code source de Git, obtient le nom de la branche de publication de celui-ci et, à l'aide de l'API Jira, interroge la liste des composants qui ont été modifiés dans le cadre des tâches de publication, télécharge les versions actuelles de Sonatype Nexus et les définit dans un environnement de test de régression. Après l'installation de la version sur l'environnement de test de régression, des scripts sont exécutés pour préparer l'environnement pour le test (redémarrage de l'application, nettoyage de la base de données, etc.) et les autotests de régression sont exécutés pour vérifier le fonctionnement de la fonctionnalité principale du système, ce qui aboutit à un rapport utilisant le plug-in Allure Reports pour Jenkins. Après l'installation, l'équipe QA est informée dans Telegram des résultats de l'exécution de l'autotest et de l'état de préparation de la version pour les tests de régression manuelle.
Si des défauts apparaissent lors des tests de régression, la version actuelle de la branche release-mn est téléchargée et, à partir du dernier commit, la branche hotfix / BUGNAME est créée par le nom du défaut dans Jira (git checkout -b hotfix / BUGNAME [BASECOMMIT]).
Une extraction est automatiquement effectuée dans la branche créée, les corrections nécessaires sont apportées et les modifications sont validées dans le correctif de la branche locale / BUGNAME (git commit hotfix / BUGNAME -m "Commit message"). Une fois la correction terminée et prête à être soumise à l'environnement de test de régression, ils sont poussés vers une branche distante du même nom (git push -u hotfix origin / BUGNAME) et une demande de fusion est créée avec la branche release-mn
Pour demander une fusion, le développeur résout les conflits de fusion (le cas échéant) et effectue une révision de code, au cours de laquelle il est possible de créer des validations supplémentaires avec des corrections aux commentaires reçus lors de la révision de code. Ces validations sont également effectuées sur le correctif de branche locale / BUGNAME (git commit hotfix / BUGNAME -m «Commit message») et elles sont transmises à une branche distante du même nom (git push -u origin hotfix / BUGNAME). Une fois l'examen terminé, les succursales fusionnent. La fusion initialise le lancement du Web Hook pour appeler la tâche dans Jenkins, similaire à la précédente, mais différente en ce qu'elle télécharge le code depuis Git, en obtient le nom du défaut, utilise l'API Jira pour demander une liste des composants qui ont été modifiés dans le cadre du correctif, collecter ces composants, télécharge sur Sonatype Nexus et les installe dans un environnement de test de régression. De plus, par analogie, l'environnement est préparé pour l'autotest, les autotests de régression sont exécutés et les résultats sont notifiés.
Lorsque tous les défauts sont corrigés, la version est installée sur un environnement productif. Pour ce faire, fusionnez la branche release-mn avec les branches develop et master et créez également une balise release.
Une fois créé, il initialise le lancement du Web Hook pour appeler la tâche dans Jenkins, qui télécharge le code source depuis Git, obtient le numéro de version de celui-ci et, à l'aide de l'API Jira, demande une liste des tâches incluses dans la version et des composants modifiés dans le cadre de ces tâches, après qui extrait la version actuelle des artefacts de Sonatype Nexus et les installe dans un environnement productif.
Avec les correctifs pour les ventes, il a été décidé d'utiliser un processus similaire à celui de la version - sinon les étapes de test des modifications apportées seront perdues.
Lors de la mise en œuvre du processus, une formation a également été dispensée aux employés n'ayant pas d'expérience de travail avec Git et GitLab, pour lesquels un programme de formation approprié a été développé. Avec cela, vous pourrez vous-même organiser une formation sur l'utilisation de Source Tree et Intellij IDEA pour travailler avec Git, ainsi que GitLab pour effectuer des révisions de code. Dans le prochain article, je lui donnerai, en complétant avec des illustrations.