---

Août 2016

Volume 31, numéro 8

Cet article a fait l'objet d'une traduction automatique.

DevOps - Application de DevOps à un projet de développement de logiciel

Par Willy-Peter Schaub, Wouter de Kort , Mattias Sköld | Août 2016

« DevOps est l’union de personnes, processus et produits pour permettre la remise continue de valeur à nos utilisateurs finaux. » — Donovan Brown dans le livre, « DevOps sur la pile Microsoft » (Wouter de Kort 2016).

Chaque route DevOps commence avec une idée que vous souhaitez transformer en une solution basée sur une culture de l’apprentissage et continue la remise de valeur. L’objectif de cet article est de partager les connaissances acquises recueillies au cours de l’exploration de l’implémentation d’un pipeline de version automatisés de notre développement, environnements de production et de test d’acceptation utilisateur. Nous allons vous guider un pipeline de version automatisés, vous pouvez adopter « tel quel », ou évoluer pour répondre à vos besoins.

Donc pourquoi a-t-il nous avons décidé d’adopter DevOps ? Comme nous sommes devenus maîtriseront le « pourquoi » (objectif), les « quoi » (fonctions) et le « comment » (technologie, code) de la création d’extensions, nous avions besoin d’une culture et un environnement qui nous permet de générer, tester, version et surveiller la famille rapidement en constante évolution et croissance des extensions. La promesse de DevOps nous a encouragés à Explorer et adopter les processus et les outils offerts par Visual Studio Team Services (Services d’équipe en abrégé). Nos équipes auto- et autonomes ont été habilités à faire évoluer une culture et un pipeline qui réduit les cycles version de chaotique, sujette aux erreurs et intensive manuellement jours à quelques minutes. Un récit et une explication du pipeline similaires est informée dans un autre article de ce problème ( » à partir du Code client : Exploration des opérations de développement Mobile »).

Si vous n’êtes pas familiarisé avec les Rangers, nous sommes une Communauté d’ingénieurs internes et externes qui travaillent avec le groupe de produits pour fournir des conseils professionnels, une expérience pratique et les solutions de remplissage d’espaces à la Communauté des développeurs. La dernière — intervalles, qui nous a enthousiastes et validées dans les extensions.

Extensions de vous fournissent une expérience d’intégration et d’extensibilité pour les Services de l’équipe et Team Foundation Server (TFS). Points d’extension incluent le formulaire d’élément de travail, créent et libérer des tâches, widgets du tableau de bord, les actions de menu, Agile et autres concentrateurs. Ils vous permettent de fournir des solutions de remplissage d’espaces, fusionnant et d’améliorer le produit, l’expérience utilisateur et la productivité.

Une extension standard se compose d’un ensemble de fichiers JavaScript, HTML et CSS, comme indiqué dans le blog 2015 par Willy P. Schaub, « Extensions 101 : tentative de visualiser le flux de traitement principal » (bit.ly/28Yfj7A). Un ou plusieurs fichiers manifestes JSON décrivent les informations de base, les fichiers inclus avec et contributions fournies par l’extension. Reportez-vous à l’exemple d’extension de la gestion des dossiers open source, qui vous permet de créer rapidement un dossier dans vos référentiels de code source Team Services à partir du Web sans le clonage du référentiel local ou l’installation des outils supplémentaires.

Chaque extension est décrit dans le manifeste basé sur JSON, appelé vss-extension.json, par défaut. Pour des raisons de cohérence, nous avons apporté un choix pour toutes les extensions futures de base sur le modèle de projet d’équipe Services et machine à écrire pour tout notre code JavaScript. Gestionnaire de Package Node (NPM) est utilisé pour le téléchargement des dépendances externes, telles que la bibliothèque typages, requis pour qu’IntelliSense de la machine à écrire. Nous exploitons la capacité de NPM pour définir un ensemble de base de scripts pour l’initialisation de l’environnement de développement. Une dose de cohérence garantit que l’équipe les membres peuvent facilement déplacer entre les équipes et que les problèmes peuvent être étudiés et résolus beaucoup plus facilement. Il permet des cycles plus courts !

Publication d’une Extension manuellement

Si vous clonez le référentiel de gestion des dossiers sur votre ordinateur de développement local, vous pouvez rapidement empaqueter et publier manuellement sur votre compte marketplace. mon exemple d'application Dropbox :

• Utilisez l’exécuteur de tâches de Scripts NPM (bit.ly/28Qmktu) ou exécutez les commandes à partir de la ligne de commande.
• Ouvrez la solution et exécutez la tâche de configuration : npm exécuter le programme d’installation. Cela télécharge les packages NPM, initialiser le typages requis pour la machine à écrire et placer vos dépendances externes à l’emplacement approprié.
• Utiliser Visual Studio pour compiler les fichiers de la machine à écrire et générer la sortie de JavaScript.
• Exécuter la tâche NPM package pour créer un fichier VSIX de sortie basé sur le manifeste dans le projet.
• Télécharger l’extension VSIX généré sur le marché ou exécution npm exécuter la publication pour empaqueter et publier votre extension automatiquement.

Mais tout d’abord, certaines en arrière-plan. Services de l’équipe est constitué de comptes isolés. Le marché est global et composé de serveurs de publication, créés et gérés par le serveur de publication de la galerie (vous). Une extension est publiée comme privés et explicitement partagée avec les comptes de Services d’équipe. Vous pouvez également une extension peut être publiée comme public une fois qu’elle a été validée, rendre visible pour tout le monde. Nous vous recommandons vivement de publier jamais cela ou autres exemples d’extensions comme étant public afin d’éviter une confusion et mauvaises UX

Pour publier votre extension, vérifiez que le champ du serveur de publication dans le manifeste correspond au nom de votre serveur de publication Marketplace. Si votre serveur de publication n’est pas vérifiée par Microsoft, vous ne pouvez publier qu’une extension comme privé. Pour publier votre extension à partir de la ligne de commande ou de l’exécuteur de tâches NPM, vous devez également un jeton d’accès personnelles qui accorde l’autorisation de gérer votre serveur de publication Marketplace. Consultez l’article « Publier une Extension à Marketplace » (bit.ly/28SDsOM), pour plus de détails.

Une Build automatisée et le Pipeline de versions

À mesure que la famille des extensions et des révisions augmente, ces étapes manuelles apparemment simples deviendra rapidement fastidieuse et sujette à erreurs. Par conséquent, nous avons commencé à travailler sur le pipeline automatisé, à l’aide de scripts et les tâches de génération pour automatiser les étapes manuelles.

Vous pouvez utiliser Windows PowerShell et la ligne de commande Générer le manifeste de l’extension du package et modifiez le numéro de version, comme indiqué dans les tâches Figure 1. Cela est décrit plus en détail dans l’article, « Notre première étapes d’adoption DevOps lors de la construction Visual Studio Team Services Extensions » (aka.ms/t0wfh6), simple et efficace.

Figure 1 Windows PowerShell version tâche (en haut) et la commande Générer la tâche (en bas)

Outil	Windows PowerShell
Arguments	cha-commande "(Get-Content vss-extension.json).replace('0.0.1', ('%BUILD_BUILDNUMBER%').replace ('SampleData », »)) | Set-Content vss-extension.json » rt
Outil	TFX
Arguments	extension de publication : jeton $(PublishExtToken) – remplace-fichier $(ManifestOverrideFile) – partager-avec $(SharedAccounts)

Également, vous pouvez utiliser la Build et la version de tâches pour les Extensions pour optimiser votre processus de génération et de publication. Le reste de cet article est basé sur cette extension.

Examinons comment nous avons utilisé la Build et les tâches de la version des Extensions et implémenté un plan pour tous les autres projets d’extension. Chaque extension démarre son voyage dans un compte de Services de l’équipe isolé, qui est la première étape du déploiement d’une extension. Release Management fait référence à ces étapes comme environnements ; Par conséquent, nous allons l’appeler l’environnement de développement (DEV). Il parcourt ensuite une série de conception, codage, la fonctionnalité expérience utilisateur et les performances des validations dans un environnement d’acceptation (bêta) de propriétaire de produit et l’utilisateur. Comme pour l’environnement de développement, il s’agit d’un compte de Services de l’équipe isolé et la deuxième étape du déploiement de l’extension. Une fois que l’extension répond à notre définition de terminé (bit.ly/28PLYyi), il est déployé sur le marché et visibles par tous. Vous pouvez identifier les phases développement → bêta → PROD du pipeline de versions prenant la forme.

Pour préparer le projet d’extension pour le pipeline automatisé, nous recommandons les modifications suivantes au manifeste de l’extension, comme indiqué dans Figure 2:

• Définissez votre version 0.0.0 et votre serveur de publication vers une chaîne vide (« »)
• Marquer l’extension comme privé (public : false)
• Supprimez l’attribut galleryFlags

Extraction du fichier manifeste figure 2

{  "manifestVersion": 1,
  "id": "FolderManagement",
  "version": "0.0.0",
  "publisher": "",
  "name": "Folder Management",
  "description": "Quickly create a folder in your Visual Studio Team
    Services source repositories from the web. No need to clone the
    repository locally or install extra tools.",
  "public": false,
  "icons": {
    "default": "images/VSO-Folder-196x.png"
  },
  "categories": [
    "Code"
  ],
  snipped rest of manifest file ...
}

Ces valeurs seront verra lors du déploiement de la version et les valeurs par défaut garantit que l’extension n’est pas déployée ou rendue publique par accident.

 Adopter une convention d’affectation de noms cohérente simplifiera la traçabilité dans vos environnements différents. Si, par exemple, suffixe ID avec votre environnement lors de la publication, FolderManagementBeta serait l’extension de la gestion des dossiers en cours d’exécution dans l’environnement de la version bêta.

Intégration continue (CI) est une pratique qui vous permet d’avoir une build prêt pour la production du dernier code dans un référentiel de contrôle de code source (bit.ly/28OtZ8K). Pour cela, la génération automatique et les tests sont exécutés sur chaque validation.

Nos projets d’extension sont généralement stockés dans un référentiel de Git Team Services hébergé ou sur GitHub pour les projets open source, telles que l’extension de la gestion des dossiers. Le pipeline commence par une définition de build déclenchée à chaque validation effectuée au référentiel, puis il crée le package d’extension VSIX et déclenche la définition de version pour la déployer vers les environnements de développement, BETA et PROD.

Comme indiqué dans Figure 3, assurez-vous de vous permettre d’intégration continue et éventuellement des modifications par lots pour réduire le nombre de builds exécutées.

Déclencheur de Build figure 3

Le lecteur astucieux avez peut-être remarqué que notre Build CI génère uniquement un package VSIX et ne copie pas les fichiers source d’extension. La raison pour laquelle nous faisons cela figure parmi les principes fondamentaux d’un pipeline de remise : générer une fois et une seule fois. Au lieu de compiler et d’empaqueter les fichiers d’extension à chaque étape de déploiement, nous ne package qu’une seule fois au début du pipeline avec différentes configurations par environnement. Nous faisons cela pour être absolument certain que nous déployons exactement la même extension de chaque environnement différent. 

Le contrôle de version de vos tâches d’extension et de build est important. Dans les Services de l’équipe, le plus récent gagne. Si vous installez une publique et une version bêta de la même extension à un compte de Services de l’équipe, il doit être clair permet d’activer la version.

Quelles sont les options de contrôle de version ? Les outils de développement Team Services vous permettent d’utiliser n’importe quel numéro de version en trois parties en tant que votre extension. Avant tout, de la simplicité et la traçabilité clair, nous avons décidé à utiliser le Build.BuildNumber comme numéro de version, comme indiqué dans Figure 4.

Figure 4 Format du numéro de Build

Vous pouvez également utiliser la tâche de requête Extension Version, ce qui donne un contrôle supérieur sur les numéros de version que vous publiez à partir de la version actuelle à partir de marketplace incrémenter une partie spécifique chaque fois que l’extension est publiée. Tout en réduisant la traçabilité entre la version du marché et les artefacts dans Team Services, il fournit une numérotation séquentielle plus agréable à vos clients sur le marché.

Qu’en est-il des tests ? La Build CI est également un bon emplacement pour exécuter les éléments tels que des tests unitaires. L’extension de la gestion des dossiers n’utilise que les tests unitaires car logique de tous les appels à l’API REST de Services Team. Autres extensions, telles que le Widget du compte à rebours (bit.ly/28PTCag), incluez des tests unitaires qui valident la logique pour le calcul de la différence de temps. Ces tests unitaires sont exécutés dans le cadre de la build. Autres tests automatisés que nous souhaitons ajouter par la suite sont Selenium des Tests Web. Cela nous permet pas uniquement des tests unitaires d’exécution, mais également automatiser le test de l’interface utilisateur.

Figure 5 montre les étapes de génération. Les dépendances NPM sont installés avec l’installation npm (1) et traité par le script d’installation avec les tâches d’exécution npm. Comme alternative, vous pouvez utiliser NuGet et l’activité de restauration NuGet. La tâche de génération de Visual Studio (2) puis génère la solution, suivie de la tâche d’Extension du Package (3) qui génère le package d’extension VSIX.

Définition de Build de la figure 5

Si vous le souhaitez, vous pouvez configurer l’ID de serveur de publication et d’extension, balise et nom se substituer aux valeurs de manifeste. Le pipeline configure uniquement le numéro de version (4) dans le cadre de la build, la valeur le numéro de build pour vous assurer que chaque instance de pipeline peut être identifiée identifie de façon unique et suivie.

Qu’est la tâche de script PowerShell pour ? Au moment de la rédaction de cet article, le script suivant était nécessaire pour extraire les informations de version (les versions futures l’extension des outils de développement : tâches de génération [bit.ly/28R0oMh] rendra le script obsolète) :

$bldVerD =("$env:BUILD_BUILDNUMBER").replace("$env:BUILD_DEFINITIONNAME","").Trim();
Write-Verbose "Extracted buildVersion $bldVer";
Write-Host "##vso[task.setvariable variable=ExtensionVersion;]$bldVer"

Livraison continue est la possibilité d’utiliser la sortie de l’élément de configuration pour générer et déployer la nouvelle version de bonne connue à un ou plusieurs environnements automatiquement (bit.ly/28PWsfk). Il existe une différence subtile entre une livraison continue et un déploiement continu. Ce dernier est dans un environnement unique. Une petite équipe peut implémenter uniquement un déploiement continu, car chaque modification passe directement à la production. Livraison continue est déplacement du code dans plusieurs environnements, au final se retrouver en production, qui peut-être inclure automatisée de l’interface utilisateur, les tests de charge et les performances et approbations tout au long du processus.

Le déploiement dans l’environnement de développement est totalement automatisé et se produit fréquemment. Cela signifie que chaque élément de configuration de génération réussie est déployée de développement sans étapes manuelles. Comme indiqué dans Figure 6, après la réussite du développement, une approbation préalable est demandée avant le déploiement dans l’environnement de la version bêta. Cette étape est approuvée par le responsable de projet ou le responsable du programme. Enfin, il est une étape d’approbation préalable pour la version publique en production. Cette opération doit être approuvée par le responsable de projet et le responsable de programme. Pour plus de simplicité, nous avons choisi d’utiliser uniquement les étapes d’approbation préalable et d’automatiser l’étape après l’approbation, car il n’est pas nécessaire d’approuver une étape après le déploiement et déployer pas à l’environnement suivant.

Figure 6 un déclencheur

Figure 7 montre la définition de version, qui déploie le package d’extension VSIX sur trois environnements. Le premier environnement de développement (1), est possédé et géré par l’équipe qui génère l’extension. L’extension est déployée comme privés et partagés avec un compte de bac à sable de développement.

Figure 7 définition de la version

Une fois que la version est testée et approuvée, le déploiement se poursuit à l’environnement deuxième, bêta (2). L’extension est toujours déployée comme privés et partagés avec un compte de bac à sable d’acceptation utilisateur.

Une fois le test d’acceptation utilisateur est terminé et approuvé, le déploiement se poursuit en modifiant le serveur de publication, de définition de la visibilité au public et de déploiement de l’extension sur le marché (3).

La tâche de publier une Extension (4) est au cœur du processus de déploiement et la configuration du pipeline. Cette tâche met à jour le fichier VSIX décompresser le contenu, de mise à jour les valeurs de configuration et de compresser tous les fichiers. La tâche puis le déploie dans le compte de serveur de publication Marketplace configuré, tels que le serveur de publication alm rangers configuré pour l’environnement de la version bêta, comme indiqué.

L’extension de balise ID (5) et le nom sont substituées pour vous assurer qu’une instance unique de l’extension en cours d’exécution dans chaque environnement, que les extensions de développement et bêta sont automatiquement partagées avec les comptes de Services de l’équipe de test d’acceptation du développement et des utilisateurs, et que les développement et aux versions bêta sont privées.

Vous avez besoin d’un jeton d’accès personnelles (6) pour publier une extension à l’aide de la tâche de publier une Extension ou la ligne de commande. Pour stocker en toute sécurité le jeton, vous pouvez créer une connexion de l’équipe des services sur le marché. La connexion définit une paire clé/valeur, où la clé est le nom de votre connexion et la valeur est le jeton d’accès.

Parmi les autres tâches que vous devez Explorer :

• Version d’Extension de requête : Vérifie le marché pour le numéro de version d’une extension publiée. La version peut être stockée dans une variable et utilisée par le pipeline pour créer une nouvelle version, par exemple avec major, minor ou correctif de numéro de version.
• Installer l’Extension : Déploie une extension sur le marché sans l’installer dans un compte.
• Partager des Extensions : Partage une extension privée dans les comptes spécifiés.

À ce stade, le pipeline constamment génère des packages et mises à jour de l’extension et, plus important encore, protège l’environnement des erreurs courantes. Les échecs de génération sont lorsqu’il existe des erreurs dans le code machine à écrire ou si des fichiers sont manquants. Le déploiement échoue lors de l’extension VSIX n’est pas valide, si l’accès à des environnements est limité, ou si un des approbateurs rejette la version.

Synthèse

Maintenant que vous disposez d’un pipeline de génération et publication automatisé, vous pouvez accélérer votre processus de développement, réduire les erreurs introduites par une intervention humaine et, plus importants, faire évoluer vos solutions, ainsi améliorer en permanence par réflexion continue, de mesure et de formation.

Toutefois, qui est un sujet pour un autre jour.

Le pipeline CI et CD automatique a réduit notre processus de build-release extensions manuelles et sujette aux erreurs de jours à quelques minutes. Il est une expérience invigorating et permet à notre équipe de développement se concentrer leur temps et leurs efforts sur ce qui est vraiment important.

Les pratiques de DevOps illustrés ici peuvent être appliquées à vos projets. Équipe Services Active DevOps pour n’importe quel langage ciblant n’importe quelle plate-forme, y compris en local, cloud, cloud hybride et mobile. Avec des fonctionnalités qui vous permettent de planifier, version, générer, déployer et surveiller votre application, Team Services a tout ce dont vous avez besoin de transformer une idée en un élément de travail du logiciel. Grâce à ces informations, nous avons hâte de voir les extensions de que la Communauté crée pour améliorer les fonctionnalités des Services d’équipe que vous lancez dans votre démarche DevOps.

Ressources de DevOps

• Génération et les tâches de version pour les Extensions aka.ms/tasksforext
• Extension de la gestion dossier également disponible en tant qu’exemple de code sur GitHub aka.ms/foldermanagement
• Bibliothèque des solutions d’outils et conseils aka.ms/vsarsolutions
• Vue d’ensemble des extensions pour Visual Studio Team Services bit.ly/293YEOm
• Visual Studio Marketplace est de trouver des extensions, des outils, produits et services pour Visual Studio, Visual Studio Team Services, Code de Visual Studio et Team Foundation Server marketplace.visualstudio.com
• Modèle de projet Visual Studio Team Services contient tout ce dont vous avez besoin pour créer une extension de Visual Studio Team Services ou une tâche/version de build personnalisée.aka.ms/extensiontemplate
• Nouveautés des opérations de développement ?aka.ms/whatisdevops

 

---

Willy-Peter Schaub est responsable de programme senior dans Visual Studio ALM Rangers au Centre d’Excellence Microsoft au Canada.  Son blog est à blogs.msdn.microsoft.com/willy-peter_schaub, et vous pouvez également suivre sur Twitter : @wpschaub.

Wouter de Kort est le consultant principal Microsoft chez Ordina aux pays-bas, où il aide les entreprises à rester à la pointe du développement de logiciels.  À l’adresse wouterdekort.com. Vous pouvez le suivre sur Twitter : @wouterdekort.

Mattias Sköld est un entraîneur DevOps/ALM à Sogeti Suède, aidant les entreprises à améliorer de leurs logiciels pratiques et conduit l’adoption de pratiques ALM/DevOps en interne à Sogeti.  À l’adresse mskold.blogspot.com et vous pouvez le suivre sur Twitter : @mattiasskold.

Remercie les experts techniques Microsoft suivants pour avoir relu cet article : Donovan Brown, Jess Houwing et sera Smythe