Gestion du contrôle des sources avec Azure DevOps
La gestion du contrôle des sources (SCM) est un élément essentiel de toute entreprise développant des logiciels de manière professionnelle, mais aussi de tout développeur souhaitant disposer d'un moyen sûr d'entreposer et de gérer son code.
Lorsque vous travaillez en équipe, il est absolument nécessaire d'avoir un dépôt central sécurisé où tout votre code est entreposé. Il est également nécessaire d'avoir un système garantissant que le code est partagé en toute sécurité entre les développeurs et que chaque modification est inspectée et fusionnée sans générer de conflits.
Dans cette page, nous allons découvrir comment Azure DevOps peut vous aider à gérer le code source de manière professionnelle et sécurisée. Dans cette page, nous aborderons les sujets suivants :
- Comprendre la gestion du contrôle des sources
- Aperçu des stratégies de branchement
- Gestion du contrôle de source avec Azure DevOps et Azure Repos
- Comment travailler avec les commits, les pushs et les branches
- Travail sur les pull requests
- Traitement d'une pull request
- Comment marquer une version de code particulière.
À la fin de cette page, vous aurez découvert tous les concepts que vous pouvez utiliser pour appliquer les techniques SCM à votre équipe à l'aide d'Azure DevOps.
Les prérequis techniques
Pour suivre cette page, vous devez avoir une organisation Azure DevOps active et Visual Studio ou Visual Studio Code installés sur votre machine de développement.
Comprendre la SCM
Le contrôle de code source (ou contrôle de version) est une pratique logicielle utilisée pour suivre et gérer les modifications apportées au code source. Il s'agit d'une pratique extrêmement importante car elle permet de maintenir une seule source de code entre différents développeurs et aide à collaborer sur un seul projet logiciel (où différents développeurs travaillent sur la même base de code).
Le SCM est une pratique essentielle dans tout processus DevOps. Pour adopter une stratégie de contrôle des sources, vous devez procéder comme suit :
- Sélectionnez un système de gestion du contrôle des sources à adopter (par exemple, installez Git sur un serveur ou utilisez un SCM basé sur l'infonuagique tel qu'Azure DevOps Repos ou GitHub).
- Entreposez votre base de code dans un dépôt géré par votre système de gestion du contrôle des sources.
- Cloner le dépôt localement pour le développement en prenant la dernière version de code (pull) entreposée dans le dépôt central.
- Validez et poussez votre code publié vers le dépôt central.
- Utiliser différentes copies du dépôt pour développer en parallèle (branches)
Un flux SCM peut être vu dans le diagramme suivant :
Git est l'un des systèmes SCM les plus populaires sur le marché. Git a été créé en 2005 par Linus Torvalds pour aider au développement du noyau Linux. Git est gratuit, open source et entièrement basé sur des fichiers, donc aucun logiciel supplémentaire n'est requis pour gérer SCM, à l'exception du moteur Git lui-même.
Le Git a un flux de travail pouvant être résumé comme suit (et pouvant être représenté à l'aide du schéma précédent) :
- Vous créez un dépôt pour votre projet sur votre système d'hébergement Git.
- Vous copiez (ou clonez) le dépôt sur votre machine de développement locale.
- Vous créez un nouveau fichier dans votre dépôt local puis vous enregistrez les modifications localement (stage et commit).
- Vous poussez les modifications vers le dépôt à distance (push).
- Vous récupérez les modifications du dépôt à distance vers le dépôt local (pour aligner votre code avec le dépôt à distance si d'autres développeurs ont apporté des modifications).
- Vous fusionnez les modifications avec votre dépôt local.
Lorsque vous utilisez Git en tant que système SCM, vous devez mémoriser certains concepts clefs :
Les instantanés (Snapshots) sont la façon dont Git garde une trace de l'historique de votre code. Un instantané enregistre essentiellement à quoi ressemblent tous vos fichiers à un moment donné. Vous décidez quand prendre un instantané et de quels fichiers.
- Commit est l'acte de créer un instantané. Dans un projet, vous créez différents commits. Un commit contient trois ensembles d'informations : Détails sur la façon dont les fichiers ont changé depuis la version précédente, un dépôt au commit parent (commit survenu précédemment) et un nom de code de hachage.
- Les dépôts sont des collections de tous les fichiers nécessaires et de leur historique. Un dépôt se trouver sur une machine locale ou sur un serveur à distance.
- Un Clone consiste à copier un dépôt à partir d'un serveur à distance.
- Un Pull est le processus de téléchargement de commits n'existant pas sur votre machine à partir d'un dépôt à distance.
- Un Push est le processus d'ajout de vos modifications locales à un dépôt à distance.
- Les Branches sont des "versions" de votre base de code. Tous les commits dans Git vivent dans une branche et vous pouvez avoir différentes branches. La branche principale d'un projet est connue sous le nom de master.
Un flux Git est composé des actions suivantes :
Regardons comment un flux de validation se produit avec Git. Pour créer un commit sur Git, vous apportez quelques modifications à vos fichiers, puis vous utilisez la commande git add pour placer ces fichiers dans l'environnement de staging. Après cela, vous utilisez la commande git commit pour créer un nouveau commit. Ce flux peut être représenté comme suit :
À titre d'exemple, voici quelques commandes git que vous pouvez utiliser pour activer le processus SCM décrit précédemment :
- Clonez un dépôt à distance localement :
- Travaillez sur votre projet.
- Enregistrez votre travail localement :
- Vérifiez s'il existe des mises à jour du serveur à distance :
- Enregistrez votre travail sur le serveur à distance :
| git clone https://github.com/user/yourRemoteRepo.git |
|
git add . git commit -m "Mon message de commit" |
| git pull |
| git push |
Pour travailler avec des branches, procédez comme suit :
- Créez une nouvelle branche et basculez vers celle-ci :
- Travailler sur les nouvelles fonctionnalités.
- Enregistrez votre travail localement :
- Enregistrez votre travail sur le serveur à distance :
git push
- Basculez vers la branche où vous souhaitez fusionner votre travail :
- Fusionnez branch1 dans la branche master et enregistrez-la sur le serveur à distance :
| git checkout -b "branch1" |
|
git add git commit -m "Mise à jour de la branch1" |
| git checkout master |
|
git merge branch1 git push |
Une fois que vous aurez maîtrisé ces commandes, vous serez prêt à commencer à utiliser Git. Dans la section suivante, nous vous donnerons un aperçu des branches et des stratégies de branchement possibles que vous pouvez utiliser.
Explorer les stratégies de branchement
Une branche est une version de votre code entreposée dans un système SCM. Lorsque vous utilisez SCM avec Git, le choix de la meilleure stratégie de branchement à adopter pour votre équipe est crucial car cela vous aide à disposer d'une base de code fiable et d'une livraison rapide.
Avec SCM, si vous n'utilisez pas de branche, vous avez toujours une seule version de votre code (branche master) et vous vous engagez toujours sur cette branche (un seul flux) :
Cette méthode de travail "à flux unique" n'est pas recommandée car elle ne garantit pas la stabilité de la branche principale, en particulier si plusieurs développeurs travaillent sur le même code.
Il existe différents flux de travail de branchement (stratégies) que vous pouvez adopter pour votre équipe, et la recommandation que je suggère normalement est de commencer simplement. Avec Git, il existe trois principales stratégies de création de branches que vous pouvez adopter :
Dans les sections suivantes, nous allons explorer chacune de ces stratégies.
Flux GitHub
Le flux GitHub est l'une des stratégies de création de branches les plus utilisées et est assez simple à adopter.
Selon ce flux de travail, vous partez d'une branche master (contenant toujours le code déployable). Lorsque vous commencez à développer une nouvelle fonctionnalité, vous créez une nouvelle branche et vous vous engagez régulièrement dans cette nouvelle branche. Lorsque le travail de développement est terminé, vous créez une pull request pour fusionner la branche secondaire avec la branche master :
Ce flux de travail est simple à adopter et bon si vous avez besoin de maintenir une seule version de votre code en production. Les seuls inconvénients sont que vous devez vérifier attentivement ce que vous engagez dans la branche master. Ceci n'est pas recommandé si vous avez besoin de plusieurs versions de votre application en production.
Flux GitLab
Le flux GitLab est une autre stratégie de branchement populaire largement utilisée, en particulier lorsque vous devez prendre en charge plusieurs environnements (tels que la production, le staging, le développement,...) dans votre processus SCM. Le schéma suivant représente ce flux :
Selon ce flux de travail, vous devez avoir au moins trois branches :
| Branches | Description |
|---|---|
| master | Il s'agit de la version locale du code pour tout le monde. |
| staging | Il s'agit de la branche dans laquelle la branche principale est branchée à des fins de test. |
| PRODUCTION | Il s'agit du code de production publié (où la mise en scène est fusionnée). |
Ceci est utile si vous souhaitez conserver une version de production stable, travailler séparément sur de nouvelles fonctionnalités pouvant être déplacées vers un environnement de test (afin d'être testées), puis fusionner cet environnement dans la version de production une fois les tests terminés.
Flux Git
Le flux Git est un flux de travail utilisé lorsque vous avez un cycle de publication planifié. Le schéma suivant représente ce flux :
Selon ce flux de travail, vous avez une branche principale et une branche de développement étant toujours actives, puis quelques autres branches n'étant pas toujours actives (peuvent être supprimées). La branche master contient le code publié, tandis que la branche develop contient le code sur lequel vous travaillez.
Chaque fois que vous ajoutez une nouvelle fonctionnalité à votre base de code, vous créez une branche de fonctionnalité, à partir de la branche de développement, puis vous fusionnez la branche de fonctionnalité dans develop lorsque l'implémentation est terminée. Ici, vous ne fusionnez jamais dans la branche master.
Lorsque vous devez publier un ensemble de fonctionnalités, vous créez une branche de publication, à partir de la branche de développement. Le code de la branche release doit être testé (peut-être avec des correctifs de bogues fusionnés), puis lorsque vous êtes prêt à publier le code, vous fusionnez la branche release dans la branche master, puis dans la branche develop.
Si un bogue grave se produit en production, ce flux indique que vous pouvez créer une branche de correctif à partir du master, corriger le bogue, puis fusionner à nouveau directement cette branche dans le master. Vous pouvez également le fusionner dans la branche release si elle est présente, ou développer dans le cas contraire. Si vous avez fusionné le code dans la branche release, la branche develop aura le correctif lorsque vous fusionnerez la branche release.
Gérer le contrôle de code source avec Azure DevOps
Azure DevOps prend en charge les types de gestion de contrôle source suivants :
- Git : il s'agit d'un système de contrôle de version distribué et est le fournisseur de contrôle de version par défaut dans Azure DevOps lorsque vous créez un nouveau projet.
- Team Foundation Version Control (TFVC) : Il s'agit d'un système de contrôle de version centralisé où les développeurs n'ont qu'une seule version d'un fichier localement, les données sont entreposées sur un serveur et des branches sont créées sur le serveur (basées sur le chemin).