Les premiers pas

Dans cette page, nous allons commencer par présenter DevOps et donner un aperçu des différents principes DevOps. Ensuite, nous allons aborder les concepts clefs d'Azure DevOps et les différents services qu'offre Azure DevOps.

Présentation de DevOps

Pendant longtemps, le développement et les opérations ont été divisés en modules isolés avec à la fois des préoccupations et des responsabilités distinctes. Les développeurs ont écrit le code et se sont assurés qu'il fonctionnait sur leurs systèmes de développement, tandis que les administrateurs système étaient responsables du déploiement et de l'intégration réels dans l'infrastructure informatique de l'organisation.

Comme il y avait peu de communication entre ces deux modules isolés, les deux équipes ont travaillé la plupart du temps séparément sur leurs projets. Cependant, ils dépendaient fortement les uns des autres car il n'y avait pas de connaissances multiplateformes entre les différentes équipes.

Cela correspondait parfaitement à la méthodologie Waterfall utilisée pour la plupart des projets. La méthodologie Waterfall est basée sur le cycle de vie du développement logiciel (SDLC), ayant des processus clairement définis pour la création de logiciels. La méthodologie Waterfall est une décomposition des livrables du projet en phases séquentielles linéaires, où chaque phase dépend des livrables de la phase précédente. Cette séquence d'événements peut ressembler à ceci :

La méthodologie Waterfall est bien adaptée aux projets dans les circonstances suivantes :

• Au début du cycle de vie du développement, les clients et les développeurs conviennent de ce qui sera livré, avec peu ou pas de changements pendant le développement du projet.
• Pour l'intégration avec des systèmes externes, il est courant que plusieurs composantes du logiciel soient conçus en parallèle. Dans ces cas, il est souhaitable que le document de conception soit complet à un stade précoce du cycle de développement.
• Divers membres de l'équipe sont également impliqués dans d'autres projets simultanément. Par exemple, les analystes métier peuvent rassembler les exigences et créer la conception pendant que les développeurs travaillent sur un autre projet.
• Lorsqu'il n'est pas possible de décomposer la phase d'exigences, les clients ne sont pas pleinement engagés dans des livrables plus petits.

Cependant, les clients peuvent ne pas savoir exactement quelles sont leurs exigences avant de voir un logiciel fonctionnel. Cela peut entraîner une modification des exigences, entraînant ainsi une reconception, une réimplémentation et une revérification. Cela peut augmenter considérablement les coûts du projet.

Pour cette raison, Agile et DevOps ont été introduits en 2009 et ont lentement conquis le monde du développement logiciel. Ils ont remplacé la méthodologie Waterfall pour la plupart des projets existants. DevOps est une extension naturelle des approches Agile et de livraison continue, et il représente le développement et les opérations. Il s'agit d'une pratique fusionnant le développement, les opérations informatiques et l'assurance qualité en un ensemble unique et continu de processus.

Le diagramme suivant illustre les différentes parties composant DevOps :

Il s'agit d'une approche itérative et basée sur l'équipe du développement où toutes les parties prenantes, telles que les développeurs, les administrateurs, les testeurs et un représentant du client, font partie de la même équipe. Les applications sont livrées en composantes fonctionnels, et plutôt que de créer des plannings et des tâches au début du projet, le projet est divisé en phases plus petites, appelées sprints. La durée de chaque sprint est définie à l'avance et comporte une liste de livrables planifiés au début de chaque sprint. Tous ces livrables sont définis avec le client et hiérarchisés par valeur commerciale par le client. À la fin de chaque sprint, lorsque le travail est terminé, il est revu et évalué par l'équipe à travers des constructions quotidiens et des démonstrations de fin de sprint.

Cela se traduit par les avantages suivants :

• En travaillant directement avec l'équipe de projet tout au long du projet, le client ressentira un sentiment d'appartenance plus fort.
• Le client a la possibilité de voir le travail livré à un stade précoce du projet et peut prendre les décisions et les modifications appropriées.
• Le développement est davantage axé sur les affaires et la valeur. Ceci est le résultat d'une collaboration plus étroite avec le client et d'une meilleure compréhension de ses besoins.
• Une méthode de travail Agile nous permet de créer rapidement une version de base du produit, pouvant être développée dans les prochaines itérations.

Maintenant que nous avons couvert une très brève introduction à DevOps, nous allons examiner les différents principes DevOps.

Comprendre les principes DevOps

Il existe de nombreuses définitions différentes en matière de DevOps. La plupart d'entre eux sont doués pour expliquer les différents aspects de la recherche du bon flux dans la livraison de logiciels et de projets informatiques. Dans les sections à venir, nous mettrons en évidence six principes DevOps essentiels lors de l'adoption d'une méthode de travail DevOps.

Principe 1 : Action centrée sur le client

De nos jours, il est important que les projets de développement de logiciels aient des cycles courts et des boucles de rétroaction, avec des utilisateurs finaux et de vrais clients intégrés dans l'équipe. Pour répondre pleinement aux exigences des clients, toute activité autour de la création de logiciels et de produits doit impliquer ces clients. Les équipes et les organisations DevOps doivent investir en permanence dans des produits et services permettant aux clients de recevoir le maximum de résultats, tout en ayant une méthode de gestion Lean autant que possible pour innover en permanence et modifier la stratégie choisie lorsqu'elle ne fonctionne plus.

Principe 2 : Créer avec la fin en tête

Les organisations doivent agir davantage comme des entreprises de produits. Ils devraient se concentrer davantage sur la création de produits fonctionnels qui sont vendus à de vrais clients. Cet état d'esprit d'ingénierie doit être partagé par tous les employés. Ceci est nécessaire pour réaliser ces produits. Cela signifie qu'ils doivent abandonner l'approche où chaque unité se concentre sur un rôle particulier avec sa propre responsabilité.

Principe 3 : Responsabilité de bout en bout

Dans la plupart des projets de développement de logiciels traditionnels, les logiciels et les services développés sont remis aux opérations, où elles déploient et maintiennent ensuite ces solutions après le processus de développement initial. En adoptant une méthode de travail DevOps, les équipes DevOps deviennent pleinement responsables et imputables du projet qu'elles livrent. Cela signifie qu'une fois que le produit a été livré par l'équipe et qu'il doit être entretenu, il reste toujours sous la responsabilité de l'équipe. L'équipe assurera également le support du produit jusqu'à ce qu'il atteigne sa fin de vie. Cela augmente considérablement le niveau de responsabilité de l'équipe et la qualité des produits étant développés.

Principe 4 : Équipes autonomes interfonctionnelles

Les organisations qui travaillent avec des équipes verticales et pleinement responsables devront laisser ces équipes travailler de manière totalement indépendante tout au long du cycle de vie. Pour permettre à ces équipes de travailler en toute autonomie, un ensemble de compétences large et équilibré est nécessaire. Les membres de l'équipe doivent avoir des profils en forme de T au lieu de spécialistes informatiques de la vieille école n'étant qualifiés que dans leur propre rôle. Des exemples de compétences que chaque membre de l'équipe devrait avoir comprennent le développement, l'analyse des exigences, les tests et les compétences en administration.

Principe 5 : Amélioration continue

Une autre partie de la responsabilité de bout en bout est que, pour les organisations, il est important de s'adapter en permanence aux changements. Il peut y avoir un certain nombre de circonstances changeantes, telles que la sortie d'une nouvelle technologie, l'évolution des exigences des clients,... L'amélioration continue est une priorité dans DevOps lorsqu'il s'agit d'optimiser la vitesse et les coûts, de minimiser les déchets, de faciliter la livraison et d'améliorer en permanence les logiciels et les services en cours de construction et de publication. Une activité importante à intégrer dans ces cycles est l'expérimentation. Cela permettra aux équipes de développer une manière d'apprendre de leurs échecs, ce qui est essentiel à l'amélioration continue.

Principe 6 : Tout automatiser

Pour adopter pleinement et intégrer une culture d'amélioration continue au sein d'une organisation, la plupart des organisations ont beaucoup de gaspillage et de profondeur technologique à éliminer. Pour travailler avec des cadences élevées et traiter au plus vite les retours instantanés des clients et utilisateurs finaux, il est impératif de tout automatiser. Cela signifie que non seulement le processus de développement logiciel doit être automatisé à l'aide de la livraison continue (incluant le développement et l'intégration continus), mais également que l'ensemble du paysage de l'infrastructure doit être automatisé. L'infrastructure doit également être prête pour de nouvelles façons de travailler. En ce sens, l'automatisation est synonyme de volonté de renouveler la manière dont l'équipe délivre ses services à ses clients.

Dans cette section, nous avons couvert les six principes étant très importants lors de l'adoption ou de la migration vers une méthode de travail DevOps. Dans les prochaines sections, nous allons examiner ce qu'Azure DevOps a à offrir en tant qu'outil prenant en charge les équipes afin qu'elles puissent travailler de manière orientée DevOps.

Présentation des concepts clefs d'Azure DevOps

Azure DevOps fournit une grande variété de services aux équipes DevOps afin qu'elles puissent planifier, travailler, collaborer sur le développement de code et créer et déployer des logiciels et des services. La plupart des équipes DevOps s'appuient sur plusieurs outils et créent des chaînes d'outils personnalisées pour chaque phase du cycle de vie des applications.

Le schéma suivant montre les phases définies dans le cycle de vie de l'application :

Dans les sections suivantes, nous expliquerons plus en détail ces phases ainsi que les outils et produits Microsoft correspondants.

Plan

Pendant la phase de planification, les équipes peuvent utiliser des tableaux Kanban et des backlogs pour définir, suivre et organiser le travail devant être effectué dans Azure Boards. Ils peuvent également utiliser GitHub pour cela. Dans GitHub, un problème peut être créé en suggérant une nouvelle idée ou en indiquant qu'un bogue doit être suivi. Ces problèmes peuvent être organisés et attribués à des équipes.

Développement

La phase de développement est prise en charge par Visual Studio Code et Visual Studio. Le Visual Studio Code est un éditeur multiplateforme, tandis que Visual Studio est un IDE Windows et Mac uniquement. Vous pouvez utiliser Azure DevOps pour les tests automatisés et utiliser Azure Pipelines pour créer des constructions automatiques pour générer le code source. Le code peut être partagé entre les équipes avec Azure DevOps ou GitHub.

Livraison

La phase de livraison consiste à déployer vos applications et services dans des environnements cibles. Vous pouvez utiliser Azure Pipelines pour déployer automatiquement du code sur n'importe quel service Azure ou environnement local. Vous pouvez utiliser des modèles Azure Resource Manager ou Terraform pour créer des environnements pour vos applications ou composantes d'infrastructure. Vous pouvez également intégrer Jenkins et Spinnaker dans vos pipelines Azure DevOps.

Opération

Au cours de cette phase, vous implémentez une surveillance complète de la pile pour surveiller vos applications et services. Vous pouvez également gérer votre environnement infonuagique avec différents outils d'automatisation, tels qu'Azure Automation, Chef,... La sécurisation de vos applications et services fait également partie de cette phase. Par conséquent, vous pouvez utiliser des fonctionnalités et des services tels qu'Azure Policy et Azure Security Center.

Pour prendre en charge le cycle de vie complet de l'analyse, de la conception, de la création, du déploiement et de la maintenance des produits et services logiciels et d'infrastructure, Azure DevOps fournit des fonctionnalités intégrées accessibles via n'importe quel navigateur Web.

Azure DevOps offre une combinaison de solutions et d'outils pouvant être utilisés pour créer des flux de travail uniques et personnalisés tout au long de chacune des phases du cycle de vie de l'application. Ces solutions seront décrites dans les sections suivantes.

Intégration continue et livraison continue (CI/CD)

Vous pouvez automatiser chaque processus DevOps avec CI/CD (et déploiement continu) dans Azure DevOps. CI est utilisé dans la phase de développement d'un projet et fait référence à la construction et au test du code de manière entièrement automatisée. Chaque fois que vous validez des modifications dans la branche principale, les modifications sont validées, puis regroupées automatiquement dans un artefact d'une construction (build). Avec CD, la phase de livraison est automatisée. Chaque fois qu'un artefact de génération est disponible, l'artefact est automatiquement déployé dans l'environnement souhaité. Lorsque l'intégration continue et le déploiement continu sont tous deux utilisés par les équipes de développement, le code reste prêt pour la production à tout moment. La seule chose que les équipes doivent faire pour déployer une application fonctionnelle en production est de déclencher la transition du développement au déploiement. Cela rendra l'artefact de génération automatisé disponible pour le déploiement. Ce déclenchement peut être aussi simple que d'appuyer sur un bouton.

Avec Azure DevOps, vous implémentez également un déploiement continu. L'ajout de cela à votre cycle de vie de développement signifie que vous pouvez automatiser l'ensemble du processus, de la validation du code à la production. Le déclenchement entre la phase de développement et la phase de livraison est entièrement automatique. Ainsi, lorsque les modifications de code sont validées et passent tous les tests effectués pendant la phase de développement, les modifications seront également publiées automatiquement en production. Cela signifie que les clients recevront la nouvelle version, ainsi que ses améliorations, dès qu'elles seront disponibles.

Accompagnement au développement agile

Azure DevOps prend en charge les équipes adoptant les méthodes de développement Agile avec des fonctionnalités de planification, de suivi et de création de rapports. Cela se traduira par des cycles de publication plus courts et une visibilité totale dans le processus de développement logiciel. Vous pouvez utiliser Azure Boards, étant traité plus en détail dans la section suivante de ce chapitre, pour gérer les backlogs et définir, attribuer et suivre les éléments de travail. Vous pouvez également utiliser des analyses et des rapports avancés et créer des tableaux de bord personnalisés pour suivre les progrès.

Contrôle de version

Un système de contrôle de version, également appelé système de contrôle de source, est un outil essentiel pour les projets multi-développeurs. Il permet aux développeurs de collaborer sur le code et de suivre les modifications. L'historique de tous les fichiers de code est également conservé dans le système de contrôle de version. Cela permet de revenir facilement à une version différente des fichiers de code en cas d'erreurs ou de bogues.

Azure DevOps prend en charge deux types de contrôle de source différents : Git (distribué), et Team Foundation Version Control (TFVS). Avec Git, chaque développeur dispose d'une copie du référentiel source sur sa machine de développement. Toutes les informations de branche et d'historique sont incluses dans le référentiel source. Chaque développeur travaille directement avec sa copie du référentiel et toutes les modifications sont partagées entre les référentiels local et source dans le cadre d'une étape distincte. Les modifications peuvent être validées sur le système de fichiers local et les opérations de contrôle de version peuvent être exécutées sans connexion réseau. Les branches peuvent être créées facilement sur la machine de développement et plus tard, elles peuvent être fusionnées, publiées ou supprimées par le développeur séparément. Avec TFVC, les développeurs n'ont qu'une seule version de chaque fichier sur leurs machines de développement locales. Tous les autres, ainsi que les données historiques, sont conservés uniquement sur le serveur. Les branches sont également créées sur le serveur.

Infrastructure en tant que code

Les équipes peuvent également gérer l'infrastructure dans Azure DevOps. Les composants d'infrastructure utilisés dans un projet, tels que les réseaux, les machines virtuelles et les équilibreurs de charge, peuvent être gérés à l'aide des mêmes fonctions et capacités de gestion des versions que celles utilisées pour le code source.

Utilisé avec la livraison continue, un modèle Infrastructure as Code (IaC) génère le même environnement à chaque fois qu'il est déployé. Sans IaC, les équipes doivent configurer et gérer manuellement les paramètres de tous les environnements de déploiement individuels, ce qui est une tâche chronophage et sujette aux erreurs. Le résultat le plus plausible est qu'au fil du temps, chaque environnement devienne un flocon de neige, étant une configuration unique ne pouvant plus être reproduite automatiquement. Cette incohérence entre les environnements entraînera des problèmes lors de la phase de déploiement.

Gestion de la configuration

La gestion de la configuration fait référence à tous les éléments et artefacts pertinents pour le projet et la relation entre eux. Ces éléments sont entreposés, récupérés et identifiés et modifiés de manière unique. Cela inclut des éléments tels que le code source, les fichiers et les binaires. Le système de gestion de configuration est la seule véritable source d'éléments de configuration.

À l'aide d'Azure DevOps, la configuration des ressources sur l'ensemble du système peut être gérée par des équipes pour déployer des mises à jour de configuration, appliquer les états souhaités et résoudre automatiquement les changements et problèmes inattendus. Azure propose plusieurs outils et fonctionnalités DevOps pour la gestion de la configuration, tels que Chef, Puppet, Ansible et Azure Automation.

Surveillance

Vous pouvez utiliser Azure Monitor pour pratiquer la surveillance continue de la pile complète. La santé de votre infrastructure et de vos applications peut être intégrée dans des tableaux de bord existants dans Grafana, Kibana et le portail Azure avec Azure Monitor. Vous pouvez également surveiller la disponibilité, les performances et l'utilisation de vos applications, qu'elles soient hébergées sur site ou dans Azure. Les langages et cadre d'applications les plus populaires sont pris en charge par Azure Monitor, tels que .NET, Java et Node.js, et ils sont intégrés aux processus et outils DevOps dans Azure DevOps.

Découvrir les services Azure DevOps

Dans cette section, nous allons présenter les différents services proposés par Azure DevOps. Ces services peuvent être utilisés pour soutenir les équipes tout au long du cycle de vie de la création de valeur commerciale pour les clients.

Azure Boards

Les Azure Boards peuvent être utilisés pour planifier, suivre et discuter du travail entre les équipes à l'aide des outils de planification Agile disponibles. À l'aide d'Azure Boards, les équipes peuvent gérer leurs projets logiciels. Il offre également un ensemble unique de fonctionnalités, notamment une prise en charge native de Scrum et Kanban. Vous pouvez également créer des tableaux de bord personnalisables, et il offre des rapports intégrés et une intégration avec Microsoft Teams et Slack.

Vous pouvez créer et suivre des user stories, des éléments de backlog, des tâches, des fonctionnalités et des bogues associés au projet à l'aide d'Azure Boards.

Azure Repos

Azure Repos prend en charge l'hébergement de dépôt Git privé et Team Foundation Server Control (TFSC). Il offre un ensemble d'outils de contrôle de version pouvant être utilisés pour gérer le code source de chaque projet de développement, grand ou petit. Lorsque vous modifiez le code, vous demandez au système de contrôle de code source de créer un instantané des fichiers. Cet instantané est enregistré de manière permanente afin de pouvoir être rappelé ultérieurement si nécessaire.

Aujourd'hui, Git est le système de contrôle de version le plus utilisé par les développeurs. Azure Repos propose Git standard afin que les développeurs puissent utiliser les outils et les clients de leur choix, tels que Git pour Windows, Mac, des services Git tiers et des outils tels que Visual Studio et Visual Studio Code.

Azure Pipelines

Vous pouvez utiliser Azure Pipelines pour créer, tester et déployer automatiquement du code afin de le mettre à la disposition d'autres utilisateurs et de le déployer sur différentes cibles, telles qu'un environnement de développement, de test, d'acceptation et de production (DTAP). Il combine CI/CD pour créer et déployer automatiquement votre code.

Avant de pouvoir utiliser Azure Pipelines, vous devez placer votre code dans un système de contrôle de version, tel qu'Azure Repos. Azure Pipelines peut s'intégrer à un certain nombre de systèmes de contrôle de version, tels qu'Azure Repos, Git, TFVS, GitHub, GitHub Enterprise, Subversion et Bitbucket Cloud. Vous pouvez également utiliser Azure Pipelines avec la plupart des types d'applications, tels que Java, JavaScript, Node.js, Python, .NET, C++, Go, PHP et XCode. Les applications peuvent être déployées sur plusieurs environnements cibles, y compris les registres de conteneurs, les machines virtuelles, les services Azure ou toute cible sur site ou infonuagique.

Azure Test Plans

Avec Azure Test Plans, les équipes peuvent améliorer la qualité de leur code à l'aide de services planifiés et exploratoires dans Azure DevOps. Les plans de test Azure offrent des fonctionnalités pour les tests manuels planifiés, les tests exploratoires, les tests d'acceptation des utilisateurs et pour recueillir les commentaires des parties prenantes. Avec les tests manuels, les tests sont organisés en plans de test et suites de tests par les testeurs et les responsables de test. Les équipes peuvent commencer les tests à partir de leurs tableaux Kanban ou directement depuis le Work Hub. Avec les tests d'acceptation par les utilisateurs, la valeur fournie pour répondre aux exigences des clients est vérifiée. Ceci est généralement effectué par des testeurs désignés. Les tests exploratoires comprennent des tests exécutés par toute l'équipe de développement, y compris les développeurs, les propriétaires de produits et les testeurs. Le logiciel est testé en explorant les systèmes logiciels, sans utiliser de plans de test ou de suites de tests. La collecte des commentaires des parties prenantes est effectuée en dehors de l'équipe de développement par les équipes marketing ou commerciales. Les développeurs peuvent demander des commentaires sur leurs user stories et leurs fonctionnalités à Azure DevOps. Les parties prenantes peuvent alors répondre directement à l'élément de rétroaction.

Azure Artifacts

Avec Azure Artifacts, vous pouvez créer et partager des paquets NuGet, npm, Python et Maven à partir de sources privées et publiques avec des équipes dans Azure DevOps. Ces paquets peuvent être utilisés dans le code source et mis à disposition des pipelines CI/CD. Avec Azure Artifacts, vous pouvez créer plusieurs flux que vous pouvez utiliser pour organiser et contrôler l'accès aux paquets.

Extension Marketplace

Vous pouvez télécharger des extensions pour Azure DevOps à partir de Visual Studio Marketplace. Ces extensions sont de simples modules complémentaires pouvant être utilisés pour personnaliser et étendre l'expérience de votre équipe avec Azure DevOps. Ils peuvent aider en étendant la planification et le suivi des éléments de travail, les tests et le suivi du code, les flux de construction et de publication du pipeline et la collaboration entre les membres de l'équipe. Les extensions sont créées par Microsoft et la communauté.