Choisir une stratégie de flux de code
- 8 minutes
Il est important de choisir une stratégie de flux de code qui corresponde à la façon dont votre équipe travaille. Il existe plusieurs stratégies à prendre en compte. À la fin du module, vous pourrez explorer les options. L'équipe web de Tailspin décide de développer une stratégie de flux de code basée sur Git et GitHub.
Quand Mara a configuré Azure Boards, l’équipe et elle-même ont identifié quelques tâches initiales à traiter. Une tâche consistait à créer un workflow basé sur Git.
Écoutons l’équipe au fur et à mesure qu’elle cherche une meilleure façon de collaborer. Actuellement, elle utilise un système de contrôle de version centralisé, le but étant de passer à Git, un système distribué.
Alors que Mara travaille assidûment sur les fonctionnalités qui lui sont affectées, Andy entre.
Andy: Salut Mara. Ce matin, au cours de la réunion avec la direction, il a été signalé que notre équipe et l'équipe de développement de jeux utilisent des systèmes de gestion de versions différents. Pour simplifier la façon dont nous partageons les ressources entre les équipes, il nous a été demandé de passer à un système de gestion de versions distribué qui peut mieux gérer la collaboration.
Mara: C’est bon à savoir. Comme vous vous en souvenez peut-être, nous avions inscrit ce point dans notre tableau. Nous utilisons un système de gestion de versions centralisé. Il nous convient parfaitement, mais je suis d'accord avec le fait qu'un système de gestion de versions distribué est un choix plus approprié quand nous commençons à partager des ressources avec d'autres équipes et que notre équipe s'agrandit. Notre tableau comporte également une tâche visant à augmenter la visibilité afin que toutes les parties prenantes sachent ce que tout le monde fait. Je pense qu'un système de contrôle de code source distribué, comme Git, pourrait également s'avérer utile.
Andy: J’ai voulu essayer Git depuis un certain temps. Mais il semble que je n’en ai jamais eu le temps. Est-il difficile à apprendre ou à configurer ? Si cela semble raisonnable, peut-être pourrions-nous travailler dessus maintenant. Je suis fatigué de remettre systématiquement les choses à plus tard. Et il serait agréable de pouvoir voir ce que tout le monde fait et d’avoir accès à l’ensemble du dépôt. Bon, de quoi s’agit-il ?
Mara: Laissez-moi l’expliquer, puis vous pouvez décider s’il semble que quelque chose que nous voulons implémenter immédiatement.
Mara et Andy passent au tableau blanc afin de discuter de la gestion de versions.
Qu’est-ce que Git et la gestion de versions distribuée ?
Mara: Le dessin à gauche est le contrôle de version centralisé, comme ce que nous utilisons maintenant. Nous avons une version centrale du codebase 
dans TFVC (Team Foundation Version Control) que tout le monde utilise. Nous travaillons chacun sur les fichiers que nous devons changer, puis nous les fusionnons dans le dépôt principal quand nous avons terminé.
Andy: Oui, et ça marche pour nous. Bon, sauf quand j’ai été bloqué la fois où un changement cassant a été fusionné dans le dépôt central.
Mara : Oui ! Vous avez été bloqué 
. Nous pourrions utiliser une stratégie de branchement avec TFVC pour résoudre le problème de blocage, mais dans notre configuration actuelle, la fusion pourrait devenir un peu plus compliquée. À la suite de cette rupture 
, personne ne pouvait travailler tant que le problème n'était pas résolu. Ce problème est toujours latent, car nous utilisons tous la même copie du code.
À droite se trouve un dessin de contrôle de version distribué. Nous disposons toujours d'un référentiel central 
qui constitue la version stable de la base de code, dont chaque développeur dispose de sa propre copie 
pour travailler. Cela nous permet d’expérimenter et de tester diverses approches sans affecter le dépôt central.
La gestion de versions distribuée garantit également que seul le code de travail 
est fusionné dans le dépôt central. Nous pourrions même la configurer de manière à ce que le code ne puisse pas être fusionné tant qu’il n’a pas été revu.
La particularité d'Azure DevOps est qu'il fonctionne aussi bien avec des systèmes de contrôle de version centralisés qu'avec des systèmes de contrôle de version distribués.
Andy: Que se passe-t-il lorsque plusieurs personnes modifient le même fichier ?
Mara: Souvent, Git peut fusionner automatiquement plusieurs modifications. Bien entendu, nous voulons nous assurer systématiquement que la combinaison des modifications aboutit à du code opérationnel. Quand Git ne peut pas fusionner automatiquement les modifications, il marque les conflits directement dans les fichiers afin qu’un utilisateur puisse choisir les modifications à accepter.
Andy: À l’heure actuelle, notre code est stocké sur notre propre serveur. Si nous passons à l’utilisation du contrôle de version distribué, où le code sera-t-il stocké ?
Mara: Je suis contente que tu as demandé. C’est là qu’intervient l’hébergement.
Où héberger mon dépôt ?
Mara: Lorsque nous choisissons l’emplacement d’hébergement de nos dépôts, nous avons quelques options. Par exemple, nous pouvons les héberger sur un serveur local, dans Bitbucket ou dans GitHub. Bitbucket et GitHub sont des solutions d’hébergement basées sur le web. Nous pouvons y accéder depuis n’importe où.
Andy: Avez-vous utilisé l’un d’eux ?
Mara: J’ai utilisé GitHub dans le passé. Il présente des caractéristiques importantes pour les développeurs, comme un accès facile aux journaux des modifications et aux fonctions de contrôle des versions, que ce soit à partir de la ligne de commande ou du portail en ligne.
Andy: Comment Fonctionne Git ?
Comment faire pour utiliser Git ?
Mara: Comme je l’ai mentionné précédemment, avec les systèmes distribués, les développeurs sont libres d’accéder à tout fichier dont ils ont besoin sans affecter le travail d’autres développeurs, car ils ont leur propre copie du référentiel. Un clone est votre copie locale d’un référentiel.
Quand nous travaillons sur une fonctionnalité ou un correctif de bogue, nous voulons généralement essayer différentes approches jusqu’à ce que nous trouvions la meilleure solution. Cependant, il n'est pas conseillé d'essayer du code sur votre copie de la base de code principale, car vous ne voudrez peut-être pas conserver les premiers essais.
Pour vous offrir une meilleure option, Git dispose d’une fonctionnalité appelée branchement, où vous pouvez conserver autant de copies que vous le souhaitez et fusionner uniquement celle que vous souhaitez conserver. Ainsi, la branche primaire demeure stable.
Andy: Je comprends les concepts pour l'instant. Comment faire pour archiver mon code ?
Comment mes modifications locales sont-elles répercutées dans le codebase principal ?
Mara: Dans Git, la branche par défaut ou la jonction est généralement appelée main.
Lorsque vous estimez que votre code est prêt à être fusionné dans la branche du référentiel central main partagé par tous les développeurs, vous créez ce qu’on appelle une pull request. Quand vous créez une demande de tirage, vous indiquez aux autres développeurs que vous avez du code prêt à être revu et que vous souhaitez le fusionner dans la branche main. Quand votre demande de tirage est approuvée et fusionnée, elle est intégrée au codebase central.
À quoi ressemble un workflow de branchement ?
Étape 1 : Lorsque vous commencez à travailler sur une nouvelle fonctionnalité ou un correctif de bogue, la première chose que vous souhaitez faire est de vous assurer que vous commencez par la dernière base de code stable. Pour ce faire, vous pouvez synchroniser votre copie locale de la branche main avec la copie du serveur. Cette opération permet de récupérer dans votre copie locale toutes les autres modifications des développeurs qui ont été envoyées à la branche main sur le serveur depuis votre dernière synchronisation.
Étape 2 : Pour vous assurer que vous travaillez uniquement sur votre copie du code, vous créez une nouvelle branche uniquement pour cette fonctionnalité ou correctif de bogue. Comme vous pouvez l’imaginer, il peut être difficile de retenir toutes les branches créées pour toutes les tâches en cours. Il est donc essentiel d’utiliser une bonne convention de nommage.
Avant d’apporter des modifications à un fichier, vous pouvez extraire une nouvelle branche afin de savoir que vous travaillez sur les fichiers de cette branche et non d’une branche différente. Vous pouvez changer de branche à tout moment en extrayant la branche concernée.
Étape 3 : Vous êtes maintenant sûr d’apporter les modifications souhaitées, car ces modifications ne se trouvent que dans votre branche. Au fur et à mesure que vous travaillez, vous pouvez valider vos modifications dans votre branche pour vous assurer que vous ne perdez pas de travail. Cela permet également de restaurer les modifications apportées aux versions antérieures. Avant de pouvoir commiter des modifications, vous devez indexer vos fichiers afin que Git sache quels sont celles que vous êtes prêt à commiter.
Étape 4 : L’étape suivante consiste à envoyer (push) ou à charger votre branche locale vers le référentiel distant (par exemple, GitHub) afin que d’autres personnes puissent voir ce que vous utilisez. Ne vous inquiétez pas, cette opération ne fusionne pas encore vos modifications. Vous pouvez pousser votre travail aussi souvent que vous le souhaitez. En réalité, c'est un bon moyen de sauvegarder votre travail ou de vous permettre de travailler à partir de plusieurs ordinateurs.
Étape 5 : cette étape est une étape commune, mais pas obligatoire. Lorsque vous êtes convaincu que votre code fonctionne comme vous le souhaitez, vous pouvez extraire ou fusionner la branche distante main dans votre branche locale main . Des modifications y ont été apportées, dont ne dispose pas encore votre branche main locale. Une fois que vous avez synchronisé la branche main distante avec la vôtre, fusionnez votre branche main locale dans votre branche de travail et retestez votre build.
Vous pouvez ainsi vous assurer que votre fonctionnalité marche avec le code le plus récent, et que votre travail s’intègre correctement quand vous envoyez votre demande de tirage.
Étape 6 : Votre code local doit maintenant être validé et envoyé vers le référentiel hébergé. Cette étape est identique aux étapes 3 et 4.
Étape 7 : Vous êtes enfin prêt à proposer vos modifications à la branche distante main . Pour ce faire, vous commencez une demande de tirage. Quand elle est configurée dans Azure Pipelines ou un autre système CI/CD, cette étape déclenche le processus de génération et vous pouvez observer le déplacement de vos modifications dans le pipeline. Une fois la génération réussie et votre demande de tirage approuvée par d’autres personnes, votre code peut être fusionné dans la branche main distante. (Il revient toujours à une personne de fusionner les modifications.)
Andy: Tout cela semble compliqué et difficile à apprendre.
Mara: Git peut sembler intimidant parce qu’il est si puissant, mais après avoir compris le fonctionnement, il commence à sembler naturel.
Au quotidien, vous vous servez seulement de quelques commandes. Voici un résumé :
| Catégorie | Pour effectuer cette tâche | Utiliser cette commande |
|---|---|---|
| Gestion du référentiel | Créer un dépôt Git | git init |
| Télécharger un dépôt distant | git clone |
|
| Branche | Créer une branche | git checkout |
| Indexer et commiter des modifications | Voir quels fichiers ont été modifiés | git status |
| Indexer les fichiers à commiter | git add |
|
| Commiter les fichiers dans votre branche | git commit |
|
| Synchronisation à distance | Télécharger une branche à partir d’un dépôt distant | git pull |
| Charger une branche sur un dépôt distant | git push |
Andy: Ça ressemble à un bon point de départ. Je peux sans aucun doute m’en occuper. Je peux apprendre des commandes plus avancées quand j’en ai besoin.