Diffusion continue de votre solution InterSystems à l'aide de GitLab - Partie I : Git

Tout le monde dispose d'un environnement de test.

Certains ont la chance de disposer d'un environnement totalement séparé pour la production.

-- Inconnu

.

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
• Git flow (processus de développement)
• Installation de GitLab
• Flux de travail GitLab WorkFlow
• GitLab CI/CD
• CI/CD avec des conteneurs

Cette première partie traite de la pierre angulaire du développement logiciel moderne - le système de contrôle de version Git et divers flux Git.

Git 101

Alors que le sujet principal que nous allons aborder est le développement de logiciels en général et comment GitLab peut nous aider dans cette entreprise, Git, ou plutôt plusieurs concepts de haut niveau sous-jacents dans la conception de Git qui sont importants pour une meilleure compréhension des concepts ultérieurs.

Ceci dit, Git est un système de contrôle de version, basé sur ces idées (il y en a beaucoup d'autres, voici les plus importantes) :

• Le développement non linéaire signifie que tandis que notre logiciel est publié de manière conséquente de la version 1 à la version 2 puis à la version 3, le passage de la version 1 à la version 2 se fait de manière parallèle - plusieurs développeurs élaborent un certain nombre de fonctionnalités/corrections de bogues simultanément.
• Le développement distribué signifie que le développeur est indépendant d'un serveur central ou d'autres développeurs et qu'il peut facilement développer dans son propre environnement.
• Fusion - les deux idées précédentes nous amènent à la situation où plusieurs versions différentes de la vérité existent simultanément et où nous devons les réunir en un seul état complet.

Je ne dis pas que Git a inventé ces concepts. Non. C'est plutôt Git qui les a rendues faciles et populaires et cela, accompagné de plusieurs innovations associées, c'est-à-dire l'infrastructure en tant que code/conteneurisation, a changé le développement de logiciels.

Terminologie de base de git

Référentiel est un projet qui stocke des données et des méta-informations sur les données.

• "Physiquement" le référentiel est un répertoire sur un disque.
• Le référentiel stocke les fichiers et les répertoires.
• Le référentiel stocke également un historique complet des modifications apportées à chaque fichier.

Le référentiel peut être stocké :

• Localement, sur votre propre ordinateur
• À distance, sur un serveur distant

Cependant, il n'y a pas de différence particulière entre les référentiels locaux et distants en ce qui concerne git.

Validation (Commit) est un état fixe du référentiel. Il est évident que si chaque commit stockait l'état complet du référentiel, notre référentiel deviendrait très gros, et très vite. C'est pourquoi un commit stocke un diff qui est une différence entre le commit actuel et son commit parent.

Le nombre de parents peut varier d'un commit à l'autre :

• 0 - le premier commit dans le référentiel n'a pas de parents.
• 1 - fonctionnement normal - notre commit a changé quelque chose dans le référentiel tel qu'il était lors du commit parent.
• 2 - lorsque nous avons deux états différents du référentiel, nous pouvons les réunir en un seul nouvel état. Cet état ainsi que ce commit auraient deux parents.
• >2 - peut se produire lorsque nous réunissons plus de deux états différents du référentiel en un nouvel état. Cela ne présenterait pas d'intérêt particulier pour notre discussion, mais cela existe.

Dans le cas d'un parent, chaque commit qui est différent de ce dernier est appelé un commit enfant. Chaque commit parent peut avoir n'importe quel nombre de commits enfants.

Branche est une référence (ou un pointeur) à un commit.  Voici à quoi cela ressemble :

Sur cette image, on peut voir le référentiel avec deux commits (cercles gris), le second est la tête de la branche master. Après avoir ajouté d'autres commits, notre référentiel prend l'allure suivante :

C'est le cas le plus simple. Un développeur ne peut travailler que sur une seule modification à la fois. Cependant, le plus souvent, de nombreux développeurs travaillent simultanément sur différentes fonctionnalités et nous avons besoin d'un arbre de commits pour montrer ce qui se passe dans notre référentiel.

Arbre de commits

Reprenons le même point de départ. Voici le référentiel avec deux commits :

Désormais, deux développeurs travaillent en même temps et, pour ne pas interférer l'un avec l'autre, ils travaillent dans des branches séparées :

Après quelque temps, ils ont besoin d'unifier les changements effectués et pour cela ils créent une demande de fusion (également appelée demande d'extraction) - qui correspond exactement à ce qu'elle ressemble - il s'agit d'une demande d'unification de deux états différents du référentiel (dans notre cas, nous voulons fusionner la branche de développement dans la branche master) en un seul nouvel état. Après avoir été dûment examiné et approuvé, notre référentiel se présente comme suit :

Et le développement continue:

Git 101 - Résumé

Concepts principaux:

• Git est un système de contrôle de version distribué et non linéaire.
• Référentiel stocke les données et les méta-informations sur les données.
• Commit est un état fixe du référentiel.
• Branche est une référence à un commit. 
• Demande de fusion (également appelée demande d'extraction) - est une demande d'unification de deux états différents du référentiel en un nouvel état.

Si vous souhaitez en savoir plus sur Git, vous pouvez vous procurer des livres.

Les flux Git

Maintenant que le lecteur est familiarisé avec la terminologie et les concepts de base de Git, voyons comment la partie développement du cycle de vie d'un logiciel peut être gérée à l'aide de Git.  Il existe un certain nombre de pratiques (appelées   flux) qui décrivent le processus de développement à l'aide de Git, mais nous allons parler de deux d'entre elles :

• Le flux GitHub flow
• Le flux GitLab flow

Le flux GitHub flow

Le flux GitHub est le plus simple possible. Le voici:

1. Créez une branche à partir du référentiel.
2. Validez vos modifications dans votre nouvelle branche.
3. Envoyez une demande d'extraction à partir de votre branche avec les modifications que vous proposez pour lancer une discussion.
4. Validez d'autres modifications dans votre branche si nécessaire. Votre demande d'extraction sera mise à jour automatiquement.
5. Fusionner la demande d'extraction une fois que la branche est prête à être fusionnée.

Il y a plusieurs règles à respecter :

• la branche master est toujours déployable (et active !)
• Il n'y a pas de développement en cours directement dans la branche master
• Le développement est en cours dans les branches de fonctionnalités
• master == environment** de production*
• Vous devez déployer la production aussi souvent que possible

* Ne pas confondre avec "Productions d'Ensemble", ici "Production" signifie LIVE.

** L'environnement est un endroit configuré où votre code s'exécute - il peut s'agir d'un serveur, d'une VM ou même d'un conteneur.

Voici à quoi ça ressemble:

Pour en savoir plus sur le flux GitHub, cliquez ici. Il existe également un guide illustré.

Le flux GitHub est intéressant pour les petits projets et il peut être essayé si vous commencez à utiliser les flux Git. Cependant, il est également utilisé par GitHub, ce qui signifie qu'il peut également être utilisé dans le cadre de grands projets.

Le flux GitLab

Si vous n'êtes pas prêt à déployer immédiatement en production, le flux GitLab offre le flux GitHub + environnements. Voici comment cela fonctionne : vous développez dans les branches de fonctionnalités, comme ci-dessus, vous fusionnez dans la branche master, comme ci-dessus, mais il y a une nouveauté : la branche master équivaut à l'environnement de test uniquement. En outre, vous disposez de "branches d'environnement" qui sont liées à plusieurs autres environnements que vous pourriez avoir.

En général, il existe trois environnements (vous pouvez en créer d'autres si nécessaire) :

• Environnement de test == branche master
• Environnement de préproduction == branche preprod
• Environnement de production == branche prod

Le code qui arrive dans l'une des branches d'environnement doit être transféré immédiatement dans l'environnement correspondant, ce qui peut être fait :

• Automatiquement (nous y reviendrons dans les parties 2 et 3)
• Semi-automatiquement (la même chose qu'automatiquement, sauf qu'il faut appuyer sur un bouton autorisant le déploiement)
• Manuellement

Le processus complet se déroule comme suit :

1. Les fonctionnalités sont développées dans la 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  
5. Pendant que nous fusionnions et testions, plusieurs nouvelles fonctionnalités ont été développées et fusionnées dans master, donc GOTO 3.

Voici à quoi ça ressemble:

Pour en savoir plus sur le flux GitLab, cliquez ici.

Conclusion

• Git est un système de contrôle de version distribué et non linéaire.
• Le flux Git peut être utilisé comme une ligne directrice pour le cycle de développement d'un logiciel, il y en a plusieurs que vous pouvez choisir.

Liens

• Git book
• GitHub flow
• GitLab flow
• Driessen flow (un flux plus complet, à titre de comparaison)
• Le code pour cet article

Les questions de discussion

• Utilisez-vous le flux git ? Lequel?
• Combien d'environnements utilisez-vous pour un projet moyen ?

Prochaine étape

Dans la prochaine partie, nous allons :

• Installer GitLab.
• Parler des ajustements recommandés.
• Discuter du flux GitLab Workflow (à ne pas confondre avec le flux GitLab).

Restez connectés.