Diffusion continue de votre solution InterSystems à l'aide de GitLab - Partie II : Flux de travail GitLab

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Le flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans l'article précédent, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels. Et bien que nous nous soyons concentrés sur la partie mise en œuvre du développement de logiciels, cette partie présente :

• Le flux de travail GitLab est un processus complet du cycle de vie d'un logiciel, allant de l'idée au retour utilisateur
• Diffusion continue est une approche d'ingénierie logicielle dans laquelle les équipes produisent des logiciels en cycles courts, garantissant que le logiciel peut être diffusé de manière fiable à tout moment. Elle vise à créer, tester et publier des logiciels plus rapidement et plus fréquemment.

Flux de travail GitLab

Le flux de travail GitLab est une séquence logique d'actions possibles à entreprendre tout au long du cycle de vie du processus de développement logiciel.

Le flux de travail GitLab prend en compte le flux GitLab, dont nous avons parlé dans un article précédent. Voici à quoi ça ressemble:

1. Idée : toute nouvelle proposition commence par une idée.
2. Problème : le moyen le plus efficace de discuter d'une idée est de créer un problème à son sujet. Votre équipe et vos collègues peuvent vous aider à le peaufiner et à l'améliorer dans l'outil de suivi des problèmes.
3. Plan : une fois que la discussion a abouti à un accord, il est temps de codifier. Mais tout d'abord, nous devons établir des priorités et organiser notre flux de travail en assignant les problèmes à des jalons et des listes de problèmes.
4. Code : une fois que tout est organisé, nous sommes prêts à écrire notre code.
5. Commit : une fois que nous sommes satisfaits de notre version provisoire, nous pouvons valider notre code dans une branche de fonctionnalités avec le contrôle de version. Le flux GitLab a été expliqué en détail dans l'article précédent.
6. Test:  exécutez nos scripts en utilisant GitLab CI,  pour construire et tester notre application.
7. Révision : une fois que notre script fonctionne et que nos tests et builds sont réussis, nous sommes prêts à faire réviser et approuver notre code.
8. Mise en scène : il est maintenant temps de déployer notre code dans un environnement de mise en scène afin de vérifier si tout a fonctionné comme prévu ou si des ajustements sont encore nécessaires.
9. Production : lorsque tout fonctionne correctement, il est temps de déployer l'environnement de production !
10. Retour d'information: il est temps de regarder en arrière et de vérifier quelle étape de notre travail doit être améliorée.

Encore une fois, le processus lui-même n'est pas nouveau (ni unique à GitLab d'ailleurs) et peut être réalisé avec d'autres outils de choix.

Examinons certaines de ces étapes et ce qu'elles impliquent. Il y a aussi documentation disponible.

Problème et Plan

Les premières étapes du flux de travail GitLab sont centrées sur un problème : une fonctionnalité, un bogue ou un autre type de travail sémantiquement distinct.

Ce problème a plusieurs objectifs tels que:

• Gestion : un problème comporte une date d'échéance, une personne assignée, une date d'échéance, une durée et des estimations, etc. pour faciliter le suivi de la résolution du problème.
• Administratif : un problème fait partie d'un jalon, d'un tableau Kanban qui nous permet de suivre notre logiciel au fur et à mesure qu'il progresse d'une version à l'autre.
• Développement : une question est associée à une discussion et à des commits.

L'étape de planification nous permet de regrouper les problèmes en fonction de leur priorité, des jalons, du tableau Kanban et d'avoir une vue d'ensemble.

Le développement a été abordé dans la partie précédente, il suffit de suivre le flux git que vous souhaitez. Après avoir développé notre nouvelle fonctionnalité et l'avoir intégrée dans le master  - que se passe-t-il ensuite ?

Diffusion continue

La livraison continue est une approche d'ingénierie logicielle dans laquelle les équipes produisent des logiciels en cycles courts, garantissant que le logiciel peut être publié de manière fiable à tout moment. Elle vise à créer, tester et publier des logiciels plus rapidement et plus fréquemment. Cette approche permet de réduire les coûts, les délais et les risques liés à la mise en œuvre des modifications en autorisant des mises à jour plus incrémentielles des applications en production. Un processus de déploiement simple et reproductible est important pour la diffusion continue.

Diffusion continue dans GitLab

La configuration de la diffusion continue dans GitLab est définie pour chaque référentiel sous la forme d'un fichier de configuration YAML.

• La configuration de la diffusion continue est une série d' étapes consécutives.
• Chaque étape comporte un ou plusieurs scripts qui sont exécutés en parallèle.

Le script définit une action et les conditions à remplir pour l'exécuter :

• Que faut-il faire (exécuter une commande du système d'exploitation, exécuter un conteneur) ?
• Lorsque le script doit être lancé :
  • Quel est l'élément déclencheur (commit sur une branche spécifique) ?
  • Faut-il l'exécuter si les étapes précédentes ont échoué ?
• Faut-il l'exécuter manuellement ou automatiquement ?
• Dans quel environnement faut-il exécuter le script ?
• Quels sont les objets à enregistrer après l'exécution des scripts (ces objets sont téléchargés de l'environnement vers GitLab pour en faciliter l'accès) ?

Environnement : il s'agit d'un serveur ou d'un conteneur configuré dans lequel vous pouvez exécuter vos scripts.

Les systèmes d'exécution (runners) exécutent des scripts dans des environnements spécifiques. Ils sont connectés à votre GitLab et exécutent des scripts au besoin.

Runner peut être déployé sur un serveur, un conteneur ou même votre machine locale.

La diffusion continue, comment se déroule-t-elle ?

1. Un nouveau commit est ajouté au référentiel.
2. GitLab vérifie la configuration de la diffusion continue.
3. La configuration de la diffusion continue contient tous les scripts possibles pour tous les cas, de sorte qu'ils sont filtrés vers un ensemble de scripts qui doivent être exécutés pour ce commit spécifique (par exemple, un commit vers la branche master déclenche uniquement des actions liées à cette branche). Cet ensemble est appelé "pipeline".
4. Le pipeline est exécuté dans un environnement cible, les résultats de l'exécution sont enregistrés et affichés dans GitLab.

Par exemple, voici un pipeline exécuté après un commit sur une branche master:

Il se compose de quatre étapes, exécutées consécutivement

1. L'étape de téléchargement permet de transférer le code dans un serveur
2. Test  - cet étape exécute les tests unitaires
3. L'étape du paquet consiste en deux scripts exécutés en parallèle :
   • Création d'un client
   • Exporter le code du serveur (à des fins d'information principalement)
4. L'étape de déploiement déplace le client créé dans le répertoire du serveur web.

Comme nous pouvons le voir, chaque script s'est exécuté avec succès, si l'un des scripts a échoué par défaut, les scripts suivants ne seront pas exécutés (mais nous pouvons modifier ce comportement) :

Si nous ouvrons le script, nous pouvons voir le journal et déterminer pourquoi le script a échoué :

Running with gitlab-runner 10.4.0 (857480b6)
 on test runner (ab34a8c5)
Using Shell executor...
Running on gitlab-test...
Fetching changes...
Removing diff.xml
Removing full.xml
Removing index.html
Removing tests.html
HEAD is now at a5bf3e8 Merge branch '4-versiya-1-0' into 'master'
From http://gitlab.eduard.win/test/testProject
 * [new branch] 5-versiya-1-1 -> origin/5-versiya-1-1
 a5bf3e8..442a4db master -> origin/master
 d28295a..42a10aa preprod -> origin/preprod
 3ac4b21..7edf7f4 prod -> origin/prod
Checking out 442a4db1 as master...
Skipping Git submodules setup
$ iris session iris "##class(isc.git.GitLab).loadDiff()"
[2018-03-06 13:58:19.188] Importing dir /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/

[2018-03-06 13:58:19.188] Loading diff between a5bf3e8596d842c5cc3da7819409ed81e62c31e3 and 442a4db170aa58f2129e5889a4bb79261aa0cad0

[2018-03-06 13:58:19.192] Variable modified
var=$lb("MyApp/Info.cls")

Load started on 03/06/2018 13:58:19
Loading file /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/MyApp/Info.cls as udl
Load finished successfully.

[2018-03-06 13:58:19.241] Variable items
var="MyApp.Info.cls"
var("MyApp.Info.cls")=""

Compilation started on 03/06/2018 13:58:19 with qualifiers 'cuk /checkuptodate=expandedonly'
Compiling class MyApp.Info
Compiling routine MyApp.Info.1
ERROR: MyApp.Info.cls(version+2) #1003: Espace prévu : '}' : Offset:14 [zversion+1^MyApp.Info.1]
 TEXT: 	quit, "1.0" }
1 erreur détectée lors de la compilation en 0,010 s.

[2018-03-06 13:58:19.252] ERROR #5475: Erreur lors de la compilation de la routine : MyApp.Info.1. Erreurs: ERROR: MyApp.Info.cls(version+2) #1003: Espace prévu : '}' : Offset:14 [zversion+1^MyApp.Info.1]
 > ERROR #5030: Une erreur s'est produite lors de la compilation de la classe 'MyApp.Info'
ERROR: Job failed: exit status 1

Une erreur de compilation a provoqué l'échec de notre script.

Conclusion

• GitLab prend en charge toutes les étapes principales du développement de logiciels.
• La diffusion continue peut contribuer à automatiser les tâches de création, de test et de déploiement de vos logiciels.

Liens

• Partie I: Git
• Introduction au flux de travail GitLab
• Documentation sur GitLab CI/CD
• Flux GitLab
• Le code pour cet article

Prochaine étape

Dans le prochain article, nous allons :

• Installer GitLab.
• Le connecter à plusieurs environnements dans lesquels des produits InterSystems sont installés.
• Rédiger une configuration de diffusion continue.

Examinons la manière dont notre diffusion continue devrait fonctionner.

Tout d'abord, nous avons besoin de plusieurs environnements et de branches qui leur correspondent. CLe code est placé dans cette branche et transmis à l'environnement cible :

A titre d'exemple, nous allons développer une nouvelle fonctionnalité en utilisant le flux GitLab et la livrer en utilisant le GitLab CD..

1. Les fonctionnalités sont développées dans une branche des fonctionnalités.
2. La branche des fonctionnalités est révisée et fusionnée dans la branche master.
3. Après quelque temps (plusieurs fonctionnalités fusionnées), le master est fusionné dans le preprod
4. Après quelque temps (tests d'utilisateurs, etc.), la préprod est fusionnée dans la prod

Voici à quoi ça ressemble:

1. Développement et test
   • Le développeur valide le code de la nouvelle fonctionnalité dans une branche de fonctionnalité séparée
   • Une fois que la fonctionnalité est devenue stable, le développeur fusionne la branche de la fonctionnalité dans la branche master
   • Le code de la branche master est livré à l'environnement de test, où il est téléchargé et testé
2. Diffusion dans l'environnement de Preprod
   • Le développeur crée une demande de fusion de la branche master vers la branche preprod
   • Le propriétaire du référentiel approuve la demande de fusion après un certain temps
   • Le code de la branche Preprod est diffusé dans l'environnement Preprod
3. Diffusion dans l'environnement Prod
   • Le développeur crée une demande de fusion de la branche preprod vers la branche prod
   • Le propriétaire du référentiel approuve la demande de fusion après un certain temps
   • Le propriétaire du référentiel appuie sur le bouton "Deploy" (Déployer)
   • Le code de la branche prod est diffusé dans l'environnement Prod

Ou le même mais sous une forme graphique: