---

Janvier 2017

Volume 32, numéro 1

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

Mobile DevOps - Automatiser les déploiements complexes avec Release Management

Par Kraig Brockschmidt | Janvier 2017

La phrase heureux, « Expédition it, » déclare que le logiciel que vous produisez, telles que les applications mobiles et les services principaux associés, est maintenant prêt pour le déploiement de clients ou, comme il est dit, « en production. » Mais comment, exactement, logiciel obtient-il vers ce point ? Dans mon dernier article de cette série (msdn.com/magazine/mt742871), j’ai exploré comment Build génère les artefacts qui alimentent le pipeline de versions. Cette offre groupée d’artefacts, appelée la « version », est ce que subit puis n’importe quel nombre de tests et d’autres processus, comme indiqué dans Figure 1, sur son trajet en production. La majorité des activités DevOps, implique en fait, le déploiement d’une version dans n’importe quel nombre d’environnements où certains tests peuvent être exécuté et mettre cette version le long de l’étape suivante du pipeline.

Figure 1 la gestion d’une version qui se produit entre la génération et de déploiement Public

Un processus de lancement implique potentiellement d’un grand nombre de tests différents qui ne s’exécutent nécessairement simultanément, et qui peuvent également nécessiter différents ordinateurs et périphériques. Il peut également impliquer approbations directes par les êtres humains qui manger déjeuner et laisser leurs bureaux soir et les week-ends. Par conséquent, le temps que nécessaire pour une mise à jour obtenir via le pipeline entier peut facilement atteindre quelques jours. Pendant ce temps, votre équipe de développement continue à fonctionner leur backlog pour les versions ultérieures, la validation de code au référentiel source, déclenche plusieurs builds qui produisent des artefacts qui alimentent le pipeline approprié.

Gestion du flux de tous ces artefacts via plusieurs pipelines permettre facilement devenir une tâche complexe et exigeante, donc les outils de gestion des versions dans Visual Studio Team Services (VSTS) et Team Foundation Server (TFS) sont une partie essentielle de la pile Microsoft DevOps.

Sur la surface, gestion des versions principalement ressemble à la prise en charge administrative et ne peut par conséquent pas être aussi techniquement intéressantes que d’autres parties de la pile Microsoft DevOps. Mais comme tout le reste dans DevOps, gestion des versions est fondamentalement une pratique qui commence par une liste des étapes que vous pouvez exécuter manuellement, dans ce cas pour valider que les artefacts de l’étape de génération/CI sont prêtes à être déployées vers des environnements suivants. Une fois que vous avez ces étapes clairement définies, quand déployer les artefacts à un environnement particulier, les tests à exécuter et les critères pour transférer les artefacts vers l’étape suivante : outils permettent ensuite de façon incrémentielle automatiser ces étapes.

Bien des égards, la gestion d’une version ressemble beaucoup à configurer une build automatisée, sauf que la sortie de la gestion des versions est le déploiement des artefacts de build vers les emplacements où les employés puissent accéder à leur. Finalement, le déploiement est comment la valeur contenue dans votre code source est remise à vos clients, qui est, bien sûr, l’objectif du processus de développement de logiciels !

Environnements, Pipelines et la complexité de gestion

Bien que le diagramme de Figure 1 ne montre que deux étapes d’assurance qualité — une interne et une externe : il peut être fait de n’importe quel nombre d’étapes de. Il s’agit, car les différentes formes de test doivent être déployés dans des environnements spécifiques où ces tests peuvent être effectués. Un environnement est simplement une configuration particulière du matériel, logiciel et données qui convient pour le test de votre choix ou scénarios d’utilisation. Voici quelques exemples qui sont fréquemment abordés dans le cadre d’opérations de développement :

• Les ordinateurs qui sont capables d’effectuer des tests unitaires, des tests d’intégration et des tests d’interface utilisateur font généralement partie d’un environnement de test automatisé, généralement à l’aide des données fictives, les services de test et les serveurs configurés pour différents tests de charge et de contrainte.
• Un environnement de test manuel configurée de manière similaire est généralement dans une équipe de test dédié effectue son travail.
• Un environnement intermédiaire est utilisé pour déployer des applications et services pour les tests de pré-production à grande échelle (par exemple, les tests de mise à niveau) et notamment le déploiement vers les clients alpha et bêta-test. Cet environnement peut dessiner sur des données en direct et les services de manière en lecture seule, ou utiliser des versions intermédiaires pour simuler intégralement une activité dynamique. Il s’agit également où vous pouvez tester votre incident et le reporting des systèmes de télémétrie et assurez-vous qu’ils générez les données souhaitées.
• Votre environnement de production publique, enfin, utilise des données publiques en direct et des services, bien sûr et est où vous collectez les données de télémétrie en direct qui seront finalement flux dans les versions ultérieures.

Vous pouvez, bien sûr, définir les environnements souhaitée selon vos besoins de la validation. Quel que soit le cas, comment générer le déplacement des artefacts via ces phases et des environnements, et les tests sont appliqués où — est à nouveau pour définir un pipeline de versions, et vous pouvez avoir n’importe quel nombre d’itinéraires différents dans une opération à des fins différentes. Avec les applications mobiles et services back-end, vous aurez plusieurs cibles de déploiement tenté, émulateurs ou périphériques les batteries de serveurs, serveurs intermédiaires et ainsi de suite. Vous pouvez également disposer des versions ne parcourez qu’une partie du pipeline uniquement pour des tests. Avec la version publique, la fonctionnalité « suivi de la mise en œuvre » de Google Play (bit.ly/2b7lh8j) vous permet également de publier une nouvelle version d’une application à un pourcentage limité de clients, qui est essentiellement un autre environnement de production, vous devrez donc peut-être un pipeline de versions distincte pour cette piste.

Qu’est une version ?

Le terme « release management » implique clairement qu’une « libérer » est gérée d’une certaine façon. Une version est un ensemble spécifique d’artefacts de build que vous souhaitez parcourir une série de validations et le déployer vers un ou plusieurs environnements. Ces artefacts (ainsi que d’autres informations et métadonnées) toujours passer par le pipeline en tant qu’unité, indépendamment de toute modification ultérieure du référentiel source et les versions qu’ils peuvent déclencher, étant donné que chaque jeu d’artefacts de build est unique et identifiées par un numéro de version complet comme 1.2.8.12, où le dernier numéro de la build. Ces versions achetant complète de bout en bout l’audit, qui est la capacité de suivre tout ce qui se trouve dans le pipeline de version à la version exacte et donc à un ensemble de modifications dans le référentiel source exact.

Dans DevOps jargon, puis « démarrer une version » signifie acheminant une unité digne d’artefacts de build dans le pipeline de versions. Figure 2 montre à quoi peut ressembler le processus : À l’aide de la file d’attente pour la communication, l’équipe s’applique une série de vérifications de validation, quel que soit l’automatisation, soit rejeter la version ou lui permettre de passer à l’étape suivante, finit par atteindre production.

Figure 2 une unité d’artefacts de Build transite par différentes parties prenantes en cours de préparation à la Production

Comme mentionné précédemment, vous pouvez certainement avoir n’importe quel nombre d’intermédiaires des environnements et même de plusieurs environnements de production et de test (comme lorsque vous utilisez la fonctionnalité de déploiement Google). Car un processus de publication peut prendre beaucoup de temps, vous pouvez choisir de déployer en production uniquement une fois par semaine ou une fois par mois. En attendant, allez voulez-vous toujours exécuter d’autres versions via une partie du pipeline, peut-être de déploiement bêta-testeurs chaque semaine pour obtenir des commentaires pour chaque publication mensuelle de la production. Vous pouvez également vouloir des builds quotidiennes pour atteindre le Gestionnaire de tests et probablement sur chaque build passer par une série de tests rapides et automatisées pour fournir des commentaires en continu à l’équipe de développement. En bref, la fréquence des versions peut changer en haut et bas dans le diagramme de Figure 2.

Par conséquent, la gestion des versions est quelque chose qui peuvent démarrer simples et évoluer à partir de là. La forme la plus simple de cette application pratique, en fait, est quelque chose que vous avez probablement déjà fait : Vous générez un package d’application, déployez sur un périphérique (intermédiaire) et jouez avec l’application pour vérifier qu’il fonctionne comme prévu. Vous téléchargez le package dans un magasin, appuyez sur « Publier » et le tour est ! Vous venez de suivre un processus de lancement manuel pour mettre votre application en production.

Déploiement continu sous la forme d’une Culture

Comme expliqué dans le premier article de cette série, (msdn.com/magazine/mt767694), tous les processus DevOps commencent par été complètement clair sur ce qui doit se produire à chaque étape dans le pipeline de version, automatique ou non. Soyez à même de décrire l’ensemble de vos processus dans un document simple, tel que chaque étape peut être effectuée manuellement. Vous êtes alors prêt à appliquer l’automatisation pour réduire les coûts, améliorer la fiabilité et la cohérence et augmenter la fréquence de test et de déploiement.

Des principaux objectifs de DevOps consiste à chaque nouvelle version d’une application ou un service, y compris les versions avec quelques modifications mineures, aussi rapidement que possible à partir du référentiel source pour les clients de flux. Un flux entièrement automatisé est appelé déploiement continu (CD), qui va de pair avec une intégration continue (CI) : Chaque validation dans votre référentiel déclenche une nouvelle build CI et chaque build réussie, qui génère un nouveau lot d’artefacts avec un numéro de version spécifique : déclencheurs automatisé un nouveau processus de publication. Ce processus de publication exécute ensuite toutes les validations nécessaires avant de déployer ce groupe en production. CD, signifie en bref, continuellement fourniture de valeur à vos clients à moindre coût, avec une intervention humaine minimale (le cas échéant) le long du pipeline de versions.

Sachez, cependant, bien que CD optimise le pipeline de version entre la phase de génération/élément de configuration et le déploiement en production, elle nécessite toujours vigilant effort par des personnes à son fonctionnement :

• Votre équipe a besoin de processus fort-révision du code pour empêcher le code médiocre sa validation dans le référentiel pour commencer.
• Votre équipe doit avoir le niveau de confiance élevé que les tests automatisés, les utilisateurs créent, sont intercepter la plupart des erreurs et les empêchant d’atteindre les clients.
• Car aucune suite de tests n’est parfait, des erreurs seront passer en production, afin que votre équipe doit surveiller activement commentaires directement dans votre environnement de production et télémétrie, les rapports d’incidents.
• Votre équipe doit être validé rapidement triage et hiérarchiser les problèmes et nourrir dans la file d’attente dev afin que les corrections rapidement et dans les versions ultérieures.
• Problèmes également identifient les écarts dans votre processus de révision du code et couverture, en effectuant des améliorations à la fois dans des tests.

En bref, CD n’est pas simplement une question de l’automatisation de votre pipeline de versions : CD est une culture de l’utilisation de vos commentaires pour améliorer en permanence la façon dont vous êtes fourniture de valeur aux clients.

Par exemple, la documentation de Microsoft Azure, consultez azure.microsoft.com/documentation, est géré dans un référentiel open source sur GitHub, github.com/Azure/azure-content. Il est un système CI/CD complet en place telles que toutes les modifications acceptées dans le référentiel via des requêtes d’extraction rapidement atteindre production. Toutefois, les requêtes d’extraction, sont examinés avec soin par l’équipe de contenu Azure chez Microsoft, ce qui empêche la mise en route dans le référentiel à tous les modifications incorrectes ou inappropriées. Accepté des modifications puis passe à travers le pipeline CI/CD automatisé qui applique une variété de validation teste (par exemple, l’interception d’une mise en forme incorrecte et les liens rompus), puis publie le contenu sur le site. L’équipe surveille ensuite les rapports de télémétrie depuis Application Insights, ainsi que des commentaires des clients, à l’aide de ces informations pour améliorer le contenu, améliorer les tests de validation et améliorer le processus de révision proprement dit.

Gestion des versions de VSTS

Dans mon dernier article, j’ai examiné configuration automatisées avec VSTS en prenant un processus de génération connue, de création d’une définition de build à partir de celui-ci et de cette définition de l’alimentation à un agent de build qui est capable d’effectuer les tâches nécessaires pour produire un faisceau d’artefacts avec un numéro de version spécifique.

Gestion des versions de VSTS est un processus similaire : Vous créez une définition de version qui spécifie comment ce groupement à déployer sur différents environnements et des tests et validations qui doivent être appliqués à elle. Que définition de version est ensuite transmise à un agent de version, un ordinateur convenablement configuré, pour le traitement (version agents sont gérés de la même façon que les agents de build, consultez bit.ly/2coBQxx). Ceci dit, un certain nombre de différences significatives entre la build et version définitions :

• Une définition de build génère des artefacts testables et peut être déployées ; une définition de version Guide du déploiement réel pour un environnement et l’exécution de tests.
• Toujours une définition de build fonctionne à partir d’un référentiel source unique ; une définition de version peut dessiner à partir de n’importe quel nombre de définitions de build pour collecter les artefacts pour une mise à jour.
• Vous pouvez souvent configurer une build entièrement automatisée en quelques heures. un pipeline de versions entièrement automatisé se produit au fil du temps, car elle prend beaucoup plus d’efforts pour créer les tests automatisés sous-jacent et utiliser les détails pour les approbations et les déconnexions.
• Une génération classique se termine en quelques minutes. une version complète, avec plusieurs environnements et les étapes de l’approbation manuelle, prendra beaucoup plus de temps. Par conséquent, vous allez analyse et plusieurs versions d’audit dans votre pipeline à différents stades.
• Une définition de version prend en charge les approbateurs avant et après le déploiement, avec lequel vous injectez contrôle manuel aux deux extrémités d’une étape de la version, ainsi que des tâches explicite intervention manuelle. Un exemple simple utilise un ou plusieurs approbateurs avant le déploiement avant de passer en production. VSTS vous permet également d’utiliser un groupe en tant qu’approbateur, tel seulement une personne de ce groupe devra se déconnecter. En général, vous affectez un approbateur quand que vous le souhaitez un être humain à être impliqué dans le processus de publication, ce qui entraîne également conserver une piste d’audit.

Par exemple, supposons que j’ai une application Xamarin code principal dans un référentiel Git sur VSTS, avec quatre générer des définitions qui produisent des principaux artefacts et des packages d’application pour iOS, Android et Windows. Un processus simple de publication, qui reproduit en écho les étapes présentées dans Figure 2, peut être le suivant, où un échec à n’importe quel point dans le pipeline annulera la version :

1. Exécuter des tests unitaires et l’intégration de génération réussie.
2. Environnement de test
   • Déployez l’application sur Xamarin Test Cloud pour exécuter des tests sur des périphériques physiques.
   • Déployer le serveur principal vers un serveur local de test de charge.
3. Environnement intermédiaire
   • Déployer l’application pour les testeurs bêta à l’aide de HockeyApp.
   • Déploiement du composant principal sur un serveur intermédiaire (utilisé par les testeurs bêta) s’exécutant sur Azure App Service.
4. Fermeture de session requise par un approbateur qui passe en revue des commentaires testeur bêta et évalue la finalisation de la version.
5. Environnement de production
   • Déployez l’application sur Google Play, Apple App Store et Windows Store.
   • Déployer le serveur principal vers le Service d’application Azure de production.

Une fois encore, notez que ce processus ne dit rien automation : il se contente de décrire les étapes de fabrication. Pour cette raison, je peux commencer à créer des définitions de version avec des étapes simples comme le déploiement et approbateur des validations. Ensuite, que j’obtiens différents tests rassemblés, je peux ajouter progressivement comme suit pour augmenter l’automatisation. (À propos, ce processus est essentiellement ce qui a été configuré pour le projet MyDriving [aka.ms/iotsampleapp], bien qu’elle se termine à l’étape 3, car l’application est distribuée uniquement par le biais de HockeyApp.)

Techniquement parlant, vous pouvez inclure des tests et des étapes de déploiement directement dans un VSTS la définition de build. Cela est suffisant lors du déploiement vers et seulement un seul environnement de test. Lorsque plusieurs environnements, les approbateurs et les autres étapes spécifiques de version sont impliqués, toutefois, vous devez le contrôle précis de Release Management.

Procédure pas à pas : Déploiement dans des environnements Azure successives

Maintenant, je vais faire une procédure détaillée pour le processus principal de l’utilisation de Release Management, pour laquelle j’ai créé une application Xamarin et un service Node.js à partir de modèles dans Visual Studio. Dans VSTS, j’ai créé un projet d’équipe appelé MSDN Magazine Dec 2016 et ajouté les projets à son référentiel de code source. Configurer des définitions de build quatre pour générer des artefacts appropriés que je peux suivre via un pipeline de versions, même si ces artefacts ne faire quelque chose d’intéressant. (Pour créer des définitions de build pour différents principaux types de projets, consultez « Génération de votre application » [bit.ly/2cGbq7W] dans la documentation de VSTS, ce qui garantit que vous créez des artefacts déployables pour Azure et illustre les tâches de déploiement dans les définitions de build.)

Étant donné que j’ai quatre regroupements distincts d’artefacts va différentes cibles, je vais finalement avoir besoin quatre définitions de version, mais ici je vais commencer avec simplement le serveur principal. Sur le portail de Services de l’équipe, j’accédez au projet d’équipe, sélectionnez l’onglet version et le clic + la nouvelle définition de. Comme avec Team Foundation Build, ceci fait apparaître une boîte de dialogue (à ce jour) quelques modèles de version liées à Azure, pour n’importe quelle destination autre que Azure, y compris magasins d’applications, commencez avec une définition vide. Pour mon serveur principal, j’utiliser le modèle de déploiement de sites Web Azure et cliquez sur Suivant. Ceci fait apparaître une boîte de dialogue de configuration dans lequel je sélectionne définition de build de mon serveur principal comme source des artefacts (vous pouvez également utiliser Jenkins en tant que source). J’ai également sélectionnez une file d’attente de l’agent et définir une option pour le déploiement continu, lequel je reviendrai plus tard à.

VSTS ouvre ensuite la définition de version dans l’éditeur illustré Figure 3 (par défaut il y aura simplement un environnement unique). L’éditeur est organisé, de gauche à droite, dans les environnements, les tâches et les détails de la tâche. Le flux de travail général consiste à créer un environnement tout d’abord et puis de le remplir avec les tâches appropriées pour cet environnement. Étant donné que les environnements ont souvent des étapes similaires, vous pouvez créer des tâches pour un environnement et cloner l’environnement pour gagner du temps. Le + bouton de l’environnement d’ajouter vous donne cette possibilité. (Vous pouvez également créer meta-tâches, dans lequel vous regroupez une séquence de tâches pour créer une tâche unique, paramétrée avec des variables, qui peuvent être utilisés dans la build et définitions de version. Pour une vue d’ensemble complète, reportez-vous à la documentation de VSTS à bit.ly/2c1X3fP.)

Figure 3 modifier une définition de la version de Visual Studio Team Services

Comme avec les définitions de build, les onglets qui nécessitant une attention sont mis en surbrillance en rouge, dans Figure 3, j’ai besoin identifier la cible Azure App Service pour le déploiement. Ensuite, dans mon compte Azure, je crée des instances de Service d’application appelés kraigb-MSDN1216-test, intermédiaire-MSDN1216-kraigb et kraigb-MSDN1216-prod. J’ai ensuite dans VSTS et cliquez sur le lien gérer sur la droite en regard de l’abonnement Azure (classique), ce qui me mène vers l’onglet Services du Panneau de configuration de projet d’équipe. Sélectionnez + Nouveau point de terminaison de Service, sélectionnez Azure classique, une boîte de dialogue dans laquelle j’Entrez les informations de connexion. Le moyen le plus simple à utiliser avec ce consiste à sélectionner le lien de fichier de paramètres de publication dans la boîte de dialogue qui accède au portail et génère un fichier texte pour le télécharger, à partir de laquelle vous pouvez copier-coller les valeurs dans VSTS.

Avoir établi cette connexion, vous retournez dans la définition de la version, actualiser la liste des abonnements et sélectionnez Nouvelle connexion. À partir de là, je peux actualiser l’emplacement de l’application Web et les contrôles de nom d’application Web pour sélectionner l’instance de Service de l’application souhaitée.

Étant donné que la plupart des informations de connexion pour mon environnement de Test est le même pour mes environnements intermédiaire et de Production, je peux cloner Test deux fois et renommez les copies. Lorsque j’apporte le clone pour la Production, cependant, j’également moi-même défini comme un approbateur avant le déploiement et une case à cocher afin d’obtenir un message électronique lorsqu’une version est en attente. Ce faisant, j’ai injecté une pause entre les environnements intermédiaire et de Production.

Démarrage d’une version

Je dispose maintenant d’un pipeline de déploiement de base entre trois environnements : test, intermédiaire et production, où les deux premiers déploiements automatique et le troisième est soumis à une approbation manuelle. Pour démarrer une version manuellement, je cliquez sur + version dans la définition de la version et sélectionnez Créer de version. Cela m’invite dans la boîte de dialogue Figure 4 dans lequel je sélectionne la build à utiliser (à partir de n’importe quel build réussie qui se trouve toujours dans VSTS), et où je peux contrôler également la chaîne de déploiement entre les environnements. Notez comment, pour l’environnement de Test, déploiement se produit automatiquement lors de la création de la version, lorsque je clique sur le bouton Créer. Intermédiaire et Production, de la même façon, ont un déploiement automatique en fonction de l’environnement précédent, approbations soumises, bien sûr, à la réussite de toutes les autres étapes de version dans ces environnements (tels que les tests) et, le cas échéant.

Figure 4 démarrer une nouvelle version manuellement en sélectionnant une Build et en définissant des déploiements

Une fois que j’ai cliqué sur Créer et commence à la version, je peux parcourir dans cette version pour vérifier sa progression, comme indiqué dans Figure 5.

Figure 5 examiner l’état d’une version en cours

Je vais partager que lorsque j’ai créé ce pipeline de versions, à l’aide d’un back-end Node.js, ma définition de build n’a pas créer les artefacts réels et par conséquent, le lancement a échoué. J’ai coché ceci en accédant à mon build la plus récente et en cliquant sur l’onglet d’artefacts sur sa page de résumé. Une fois que j’ai ajouté la tâche de choses nécessaire pour créer une véritable de sortie, comme indiqué dans le guide sur bit.ly/2c1XhTY, ces artefacts sont en place.

Dans mon pipeline version simple, je n’ai pas défini tout test automatisé afin que les déploiements de Test et intermédiaire se produisent rapidement à la suite, et je peux accéder à ces sites Web et afficher les résultats. Avant tout être déployée en Production, toutefois, la version m’indique que « une approbation avant le déploiement est en attente pour l’environnement de « Production ». Approuver ou rejeter, » comme vous pouvez le voir dans Figure 6. J’ai également un e-mail me d’alerte pour l’approbation, avec un lien vers cette même page de version dans VSTS. Il, je clique sur le lien approuver ou rejeter pour indiquer ma décision, ajouter des commentaires, différer le déploiement à une date ultérieure ou réaffecter l’approbation à quelqu'un d’autre. Dans ce cas, je clique sur Approuver la version est terminée et je peux aller voir le déploiement sur l’instance de Service d’application kraigb-1216-prod.

Figure 6 l’approbation ou le rejet d’une étape d’approbation manuelle

Figure 6, comme vous pouvez le voir, indique l’état d’une seule version. En cliquant sur le nom de la définition de version dans le coin supérieur droit, je peux voir une page de résumé de toutes les versions sont toujours conservés dans VSTS. C’est là vous pouvez surveiller visuellement la progression de chaque version dans votre pipeline de cette définition, et une vue similaire est disponible en cliquant sur toutes les définitions de version dans l’arborescence de navigation sur le côté gauche du portail (non illustré).

Déploiement continu

Configuration du déploiement continu signifie démarrer automatiquement une version après une génération réussie à l’aide des artefacts générés par cette build. Pour ce faire, je modifier la définition de version et cliquez sur l’onglet de déclencheurs, où des options manuelles, déploiement continu et mises à jour planifiées. Lorsque je clique sur un déploiement continu, je puis sélectionnez la source des artefacts, qui est ma définition de build pour le serveur principal, et enregistrez la définition de version.

Maintenant je peux arrière à Visual Studio, apportez une modification dans le code principal et validation dans le référentiel. Cela déclenche une nouvelle build sur VSTS, car j’ai coché la case de l’intégration continue dans la définition de build du serveur principal. Une fois cette build est réussie, il déclenche automatiquement une nouvelle version, car j’ai vérifié dans la définition de la version de déploiement continu. Par conséquent, avec des options CI et CD, j’ai configuré le pipeline de la version complète entre les modifications dans le code et de déploiement en production, sujet uniquement pour l’approbation avant le déploiement manuelle que j’ai spécifié pour l’environnement de Production dans la définition de version.

Bien que ce pipeline est simple, j’ai maintenant une base solide sur laquelle je peux développer des étapes supplémentaires, telles que l’exécution de n’importe quel nombre de tests, simplement en ajoutant davantage de tâches dans l’environnement approprié dans la définition de la version et la configuration des approbations nécessaires avant et après le déploiement. Je peux également ajouter les nouveaux environnements pour diviser le pipeline en étapes distinctes encore plus. Mais quel que soit le nombre de tâches ou vous ajoutez des environnements, le processus de base sera le même comme vous l’avez vu ici.

Procédure pas à pas : Publier l’application.

Avec les définitions de la version du serveur principal en place, je peux désormais créer les définitions de trois version pour iOS, Android et Windows les versions de l’application Xamarin. Le processus est très similaire à avec le serveur principal, sauf que je démarre avec un modèle de version vide et sélectionnez la définition de build spécifique à la plateforme. Dans l’éditeur de définition de version, je n’ai pas toutes les tâches par défaut, afin de pouvoir une fois que j’ai défini les environnements souhaité (par exemple, Test, avant son lancement et lancez, à afficher que vous pouvez utiliser tous les noms), cliquez sur + Ajouter la tâche et sélectionnez-en un dans la boîte de dialogue qui s’affiche.

Dans le cas de l’application Android, mes déploiements sont les suivantes :

• Test : Utilisez une tâche de génération pour compiler le code de test, puis utiliser une tâche de Xamarin Test Cloud pour déployer le code de test et le fichier .apk pour exécuter ces tests automatiquement sur les périphériques que j’ai sélectionné. (Bien sûr, un compte Test Cloud est nécessaire pour utiliser le service.)
• Avant son lancement : Utilisez la tâche HockeyApp du marché de VSTS, lequel tout d’abord installer afin qu’il apparaisse dans la boîte de dialogue tâche Ajouter. J’ont également créé un compte avec HockeyApp et ses services permet de définir ma liste de clients d’avant son lancement.
• Launch : Pour Android, installer la tâche de Google Play à partir du marché et sélectionnez-le dans la boîte de dialogue tâche Ajouter (où vous pouvez consulter les tâches de version, de promouvoir et d’augmenter le déploiement séparément). Bien entendu, cela signifie que j’ai configuré moi-même en tant que développeur Google.

Pour mon iOS et Windows de version des définitions, je peux toujours utiliser un Cloud de Test Xamarin et HockeyApp, mais ces plateformes ne fournissent pas de déploiement automatisé de leurs magasins respectifs. Dans ces cas, mon environnement de démarrage n’a pas toutes les tâches. Au lieu de cela, j’ai attribué simplement un approbateur avant le déploiement de cet environnement. Cette personne est chargée d’évaluer les commentaires des testeurs avant son lancement et peut ensuite passer aux portails appropriés à télécharger l’application de production.

Distribution avant son lancement avec HockeyApp

HockeyApp (hockeyapp.net) est un puissant service DevOps pour iOS, Android et Windows applications avant et après le lancement d’un. Après lancement, HockeyApp fournit incident déclaration, l’utilisation des données et utilisateur des commentaires, seront abordées dans un prochain article. Avant son lancement, HockeyApp fournit les mêmes services, ainsi que la possibilité de déployer rapidement et facilement des applications de test à un nombre quelconque de testeurs, quel que soit les périphériques qu’ils utilisent et quelle que soit l’emplacement où elles se trouvent dans le monde. Il vous permet également d’organiser et gérer les testeurs de plusieurs façons afin de contrôler facilement les groupes sur lesquels obtenir les versions et le moment.

Avant de lancer distribution (bit.ly/2cxruZ8) fonctionne via le client de HockeyApp testeurs installer sur leurs périphériques. Lorsque vous avez un nouveau test version prêt, téléchargez-le sur le portail de HockeyApp que soit manuellement ou via un déploiement de l’étape dans VSTS. Les testeurs puis recevoir un message électronique indiquant que la nouvelle version est disponible, et le client HockeyApp montre les versions disponibles qui peuvent être installées à l’utilisation des fonctionnalités de chargement des plates-formes mobiles différentes.

À l'horizon

Dans cette série d’articles, j’ai examiné contrôle de code source, génération et gestion des versions, par le biais duquel vous pouvez créer un pipeline de la version complète dans des environnements qui prendront en charge les tests supplémentaires et des étapes d’approbation que peut être requise. Cette étape termine toutes les connexions de base entre votre code source et vos clients. Ce qu’il reste, est à présent, de comprendre comment les clients grâce à la surveillance des applications et services back-end, écouter et puis pour en savoir plus sur les diverses options de test vous pouvez utiliser, y compris Xamarin Test Cloud.

CodePush

Déploiement continu est plus couramment utilisé avec les applications et services Web, car le processus de déploiement est simplement de télécharger de nouveaux artefacts au serveur approprié. Pour les applications mobiles, le déploiement automatique est possible uniquement pour les applications publiées dans le magasin de Google Play, mais pas à l’heure actuelle pour iOS et Windows, car les deux nécessitent des étapes manuelles. En outre, l’approbation des mises à jour de l’application peut prendre jusqu'à deux semaines, ce qui rend difficile à atteindre des correctifs de bogues simples, beaucoup moins critique de clients. Heureusement, les applications créées à l’aide d’Apache Cordova et réagir natif peuvent tirer parti du service Microsoft CodePush (en version préliminaire au moment de la rédaction) au raccourci le processus. CodePush permet aux développeurs de déployer automatiquement HTML, CSS, JavaScript et les artefacts statiques comme des images directement vers les périphériques client. Le service fonctionne si la requête d’application CodePush les mises à jour qui sont ensuite appliquées à l’application en cours d’exécution, ce qui évite d’avoir à passer par l’application de stocker des processus d’approbation. (Cette pratique est autorisée par les stratégies app store, fournie par rôle initial de l’application ne change pas.) En savoir plus sur microsoft.github.io/code-push.

---

Kraig Brockschmidtfonctionne en tant que contenu développeur senior chez Microsoft et se concentre sur les opérations de développement pour les applications mobiles.  Il est l’auteur de « Programmation Windows Store Apps avec HTML, CSS et JavaScript » (deux éditions) à partir de Microsoft Press et des blogs sur kraigbrockschmidt.com.

Merci à l'expert technique suivant d'avoir relu cet article : Alex Homer
Alex Homer est un auteur technique de Microsoft qui a eschewed des boutons et menus de Redmond pour travailler à domicile dans merveilleux Derbyshire Dales en Angleterre. Divers caractères de ses articles sont des contributions de ses deux chats.