DevOps et développement

continue

LAMALEM Yasser
 Développement

●
La phase de développement de DevOps est l’endroit où se produit
tout le travail de développement logiciel principal. En tant qu’entrée, il
prend des plans pour l’itération actuelle, généralement sous la forme
d’affectations de tâches. Ensuite, il produit des artefacts logiciels qui
expriment les fonctionnalités mises à jour. Le développement
nécessite non seulement les outils utilisés pour écrire du code, tels
que Visual Studio, mais également les services de prise en charge
tels que le contrôle de version, la gestion des problèmes et les tests
automatisés.
 Sélectionner un environnement de développement

●
Sélectionnez l’environnement de développement approprié pour
prendre en charge l’adoption et les performances de DevOps. Un
environnement de développement DevOps ne doit pas seulement
modifier et déboguer du code, mais s’intégrer au reste du cycle
DevOps, notamment les tests, le contrôle de version et la
surveillance de la production. Microsoft fournit deux environnements
de développement majeurs pour prendre en charge DevOps, Visual
Studio et Visual Studio Code.
 Qu’est-ce que la gestion de versions ?

●
Les systèmes de contrôle de version sont des logiciels qui permettent de
suivre les modifications apportées dans le code au fil du temps. Quand un
développeur modifie le code, le système de gestion de versions prend un
instantané des fichiers. Il enregistre ensuite cet instantané de manière
permanente afin qu’il puisse être rappelé ultérieurement si nécessaire.

●
Sans contrôle de version, les développeurs sont tentés de conserver
plusieurs copies de code sur leur ordinateur. Cela est dangereux, car il est
facile de modifier ou de supprimer un fichier dans la mauvaise copie du
code, ce qui risque de perdre du travail. Les systèmes de contrôle de
version résolvent ce problème en gérant toutes les versions du code, mais
en présentant à l’équipe une seule version à la fois.
 Pourquoi le contrôle de version est important

●
Il y a beaucoup de choses qui peuvent prendre du temps en tant que
développeur. La reproduction de bogues, l’apprentissage de
nouveaux outils et l’ajout de nouvelles fonctionnalités ou de contenu
ne sont que quelques exemples. À mesure que les demandes des
utilisateurs évoluent, le contrôle de version aide les équipes à
travailler ensemble et à expédier à temps.
 Avantages du contrôle de version

●
Créer des flux de travail
➔ Les flux de travail de contrôle de version empêchent tout le monde d’utiliser son
propre processus de développement avec des outils différents et incompatibles.
Les systèmes de contrôle de version fournissent les autorisations et l’application
des processus afin que tout le monde reste sur la même page.

●
Utiliser des versions
➔ Chaque version contient une description de ce que font les modifications de la
version, telles que la correction d’un bogue ou l’ajout d’une fonctionnalité. Ces
descriptions aident l’équipe à suivre les modifications apportées au code par
version au lieu des modifications de fichier individuelles. Le code stocké dans les
versions peut être affiché et restauré à partir du contrôle de version à tout
moment en fonction des besoins. Les versions facilitent la base de nouvelles
tâches sur n’importe quelle version de code.
 Avantages du contrôle de version

●
Coder ensemble
➔ Le contrôle de version synchronise les versions et garantit que les modifications
ne sont pas en conflit avec les modifications d’autres utilisateurs. L’équipe
s’appuie sur le contrôle de version pour aider à résoudre et à empêcher les
conflits, même lorsque les utilisateurs apportent des modifications en même
temps.
●
Automatiser des tâches
➔ Les fonctionnalités d’automatisation du contrôle de version permettent de gagner
du temps et de générer des résultats cohérents. Automatiser les tests, l’analyse
du code et le déploiement lorsque de nouvelles versions sont enregistrées dans
le contrôle de version sont trois exemples.
 Avantages du contrôle de version

●
Conserver un historique
➔ Le contrôle de version conserve un historique des modifications, car
l’équipe enregistre de nouvelles versions du code. Les membres de
l’équipe peuvent consulter l’historique pour savoir qui, pourquoi et quand
des modifications ont été apportées. L’historique donne aux équipes la
confiance à expérimenter, car il est facile de revenir à une version
correcte précédente à tout moment. L’historique permet à toute
personne de base de travailler à partir de n’importe quelle version du
code, par exemple pour corriger un bogue dans une version précédente.
 Git

●
Qu’est-ce que Git ?
➔ Git est un système de contrôle de version distribué, ce qui signifie qu’un
clone local du projet est un référentiel de contrôle de version complet.
Ces référentiels locaux entièrement fonctionnels facilitent le travail hors
connexion ou à distance. Les développeurs valident leur travail
localement, puis synchronisent leur copie du référentiel avec la copie sur
le serveur. Ce paradigme diffère de la gestion de version centralisée où
les clients doivent synchroniser le code avec un serveur avant de créer
de nouvelles versions du code.
 Git

➔ La flexibilité et la popularité de Git constituent un excellent choix pour

toute équipe. De nombreux développeurs et diplômés universitaires
savent déjà comment utiliser Git. La communauté des utilisateurs de Git
a créé des ressources pour former les développeurs et la popularité de
Git facilitent l’obtention de l’aide si nécessaire. Presque tous les
environnements de développement prennent en charge Git et les outils
en ligne de commande Git implémentés sur chaque système
d’exploitation majeur.
 Principes de base de Git

●
Chaque fois que le travail est enregistré, Git crée une validation. Une
validation est un instantané de tous les fichiers à un moment donné.
Si un fichier n’a pas changé d’une validation à l’autre, Git utilise le
fichier précédemment stocké. Cette conception diffère des autres
systèmes qui stockent une version initiale d’un fichier et conservent
un enregistrement des deltas au fil du temps.
 Principes de base de Git

●
Les validations créent des liens vers d’autres validations, formant un
graphique de l’historique de développement. Il est possible de rétablir
le code à une validation précédente, d’inspecter la façon dont les
fichiers ont changé d’une validation à l’autre et d’examiner les
informations telles que l’emplacement et le moment où les
modifications ont été apportées. Les validations sont identifiées dans
Git par un hachage de chiffrement unique du contenu de la validation.
Étant donné que tout est haché, il est impossible d’apporter des
modifications, de perdre des informations ou de endommager des
fichiers sans la détecter par Git.
 Git : Branches
●
Chaque développeur enregistre les modifications apportées à son
propre référentiel de code local. Par conséquent, il peut y avoir de
nombreuses modifications différentes basées sur la même validation.
Git fournit des outils permettant d’isoler les modifications et de les
fusionner ultérieurement. Les branches, qui sont des pointeurs légers
pour travailler en cours, gèrent cette séparation. Une fois que le
travail créé dans une branche est terminé, il peut être refusionné à
nouveau dans la branche principale (ou le tronc) de l’équipe.
 Git : Fichiers et validations
●
Les fichiers dans Git sont dans l’un des trois états suivants : modifié,
intermédiaire ou validé. Lorsqu’un fichier est modifié pour la première fois,
les modifications existent uniquement dans le répertoire de travail. Ils ne font
pas encore partie d’un commit ou de l’historique de développement. Le
développeur doit mettre en scène les fichiers modifiés à inclure dans la
validation. La zone de mise en lots contient toutes les modifications à inclure
dans la validation suivante. Une fois que le développeur est satisfait des
fichiers intermédiaires, les fichiers sont empaquetés en tant que validation
avec un message décrivant ce qui a changé. Cette validation fait partie de
l’historique de développement.
 Git : Fichiers et validations

●
La mise en lots permet aux développeurs de choisir les modifications
de fichier à enregistrer dans une validation afin de décomposer les
modifications volumineuses en une série de validations plus petites.
En réduisant l’étendue des validations, il est plus facile de passer en
revue l’historique des validations pour rechercher des modifications
de fichier spécifiques.
 Avantages de Git

●
Développement simultané
➔ Chacun possède sa propre copie locale de code et peut travailler
simultanément sur ses propres branches. Git fonctionne hors connexion,
car presque chaque opération est locale.

●
Versions plus rapides
➔ Les branches permettent un développement flexible et simultané. La
branche principale contient du code stable et de haute qualité à partir
duquel vous publiez. Les branches de caractéristiques contiennent des
travaux en cours, qui sont fusionnées dans la branche principale à
l’achèvement. En séparant la branche de mise en production du
développement en cours, il est plus facile de gérer le code stable et
d’expédier les mises à jour plus rapidement.
 Avantages de Git

●
Intégration intégrée
➔ En raison de sa popularité, Git s’intègre à la plupart des outils et
produits. Chaque IDE majeur prend en charge Git et de nombreux outils
prennent en charge l’intégration continue, le déploiement continu, les
tests automatisés, le suivi des éléments de travail, les métriques et
l’intégration des fonctionnalités de création de rapports avec Git. Cette
intégration simplifie le flux de travail quotidien.
●
Soutien de la communauté forte
➔ Git est open source et est devenu la norme de facto pour le contrôle de
version. Il n’y a pas de pénurie d’outils et de ressources disponibles pour
que les équipes tirent parti. Le volume de prise en charge de la
communauté pour Git par rapport à d’autres systèmes de gestion de
version facilite l’obtention de l’aide si nécessaire.
 Avantages de Git
●
Git fonctionne avec n’importe quelle équipe
➔ L’utilisation de Git avec un outil de gestion du code source augmente la
productivité d’une équipe en encourageant la collaboration, en appliquant des
stratégies, en automatisant les processus et en améliorant la visibilité et la
traçabilité du travail. L’équipe peut s’installer sur des outils individuels pour le
contrôle de version, le suivi des éléments de travail et l’intégration et le
déploiement continus. Ou bien, ils peuvent choisir une solution comme GitHub
ou Azure DevOps qui prend en charge toutes ces tâches à un seul endroit.

●
Stratégies de branche
➔ Teams peut configurer GitHub et Azure DevOps pour appliquer des flux de travail
et des processus cohérents au sein de l’équipe. Ils peuvent configurer des
stratégies de branche pour s’assurer que les demandes de tirage répondent aux
exigences avant la fin. Les stratégies de branche protègent les branches
importantes en empêchant les push directs, en exigeant des réviseurs et en
garantissant des builds propres.
 Avantages de Git

●
Demandes de tirage
➔ Utilisez des demandes de tirage pour discuter des modifications de code
avec l’équipe avant de les fusionner dans la branche principale. Les
discussions dans les demandes de tirage sont précieuses pour garantir
la qualité du code et accroître les connaissances au sein de votre
équipe. Les plateformes telles que GitHub et Azure DevOps offrent une
expérience de demande de tirage riche où les développeurs peuvent
parcourir les modifications de fichier, laisser des commentaires,
inspecter les validations, afficher les builds et voter pour approuver le
code.
 Utiliser l’intégration continue

●
L’intégration continue (CI) est le processus de génération et de test
automatique du code chaque fois qu’un membre de l’équipe valide
les modifications apportées au code dans le contrôle de version (Git).
Une validation de code dans la branche principale ou de jonction d’un
référentiel partagé déclenche le système de génération automatisé
pour générer, tester et valider la branche complète. CI encourage les
développeurs à partager leur code et leurs tests unitaires en
fusionnant leurs modifications dans le référentiel de contrôle de
version partagé chaque fois qu’ils terminent une tâche.
 Utiliser l’intégration continue

●
Les développeurs de logiciels travaillent souvent de manière isolée,
puis doivent intégrer leurs modifications au reste de la base de code
d’une équipe. Les jours ou semaines d’attente pour intégrer le code
peuvent créer de nombreux conflits de fusion, résoudre difficilement
les bogues, les stratégies de code divergentes et les efforts
dupliqués. CI évite ces problèmes, car il nécessite que le code de
l’équipe de développement se fusionne en continu vers la branche de
contrôle de version partagée.
 Utiliser l’intégration continue

●
CI conserve la branche principale à jour. Les développeurs peuvent
utiliser des systèmes de contrôle de version modernes tels que Git
pour isoler leur travail dans les branches de fonctionnalités de courte
durée. Une fois la fonctionnalité terminée, le développeur envoie une
demande de tirage de la branche de fonctionnalité à la branche
principale. Lors de l’approbation de la demande de tirage, les
modifications se fusionnent dans la branche principale et la branche
de fonctionnalité peut être supprimée.
 Utiliser l’intégration continue

●
Les équipes de développement répètent ce processus pour chaque
élément de travail. Teams peut établir des stratégies de branche pour
garantir que la branche principale conserve les critères de qualité
souhaités.

●
Les définitions de build spécifient que chaque validation dans la
branche principale déclenche le processus de génération et de test
automatisé. Les tests automatisés vérifient que chaque build
conserve une qualité cohérente. CI intercepte les bogues plus tôt
dans le cycle de développement, ce qui les rend moins coûteux à
corriger.