---

Août 2016

Volume 31, numéro 8

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

DevOps - mobile à partir de Code client : Exploration de Mobile DevOps

Par Kraig Brockschmidt | Août 2016

Normes de l’historique, l’écriture de code est facile. Aujourd'hui nous sommes ravis d’outils très puissants telles qu’IntelliSense, saisie semi-automatique, la coloration de syntaxe, mise en surbrillance de l’erreur et la prise en charge par les Communautés comme Stack Overflow. Nous sommes ravis également un référentiel croissant de bibliothèques extrêmement utiles et des outils, nombre d'entre eux libre. Mais il existe un grand écart — un véritable gouffre, vous pourriez dire, entre la simple agir de l’écriture de code et le développement d’applications mobiles qui offrent la plus grande valeur aux clients, et cela au coût plus bas pour votre entreprise.

Les différentes méthodes qui ont commencé à être appelés collectivement DevOps sont essentiellement ce que vous aider à combler ce gouffre. Je dis « pratiques différentes », car il existe de nombreuses façons de créer ce pont. Il existe différentes façons de définir les processus eux-mêmes, et il existe différents outils pour vous aider à communiquer et de gérer ces processus avec toutes les personnes impliquées, y compris les méthodes d’apprentissage directement à partir de vos clients. Par conséquent, tout l’espace DevOps semble souvent très chaotique, avec choix trop et trop peu de clarté.

Heureusement, comme je vais aborder dans cette série d’articles, Microsoft propose désormais une réponse : une pile complète de bout en bout qui permet de DevOps pour les applications mobiles et leur associé back-end. Cette pile illustrée Figure 1, se compose de Visual Studio et Visual Studio Team Services Team Foundation Server, ainsi que le Cloud de Test de Xamarin, HockeyApp, Application Insights et CodePush.

Figure 1 les principaux composants de la pile de DevOps Microsoft pour les applications mobiles et Services Back-End

Outil ou Service	Objectif avec DevOps
Visual Studio (bit.ly/25EVbAw)	Outil de développement central pour le code d’application, les services et les tests, ainsi que les diagnostics et l’intégration au contrôle de code source.
Visual Studio Team Services (bit.ly/1srWnp9)	Hébergé sur le nuage outils de planification Agile, contrôle de code source, créer des services, services de test et de gestion des versions. (Notez qu’outils de planification n’est pas traitée dans cette série).
Team Foundation Server (bit.ly/1TZZo9o)	Fonctionnalités locales équivalentes à Visual Studio Team Services, ce qui permet des personnalisations complètes de serveurs et de contrôle total sur ces machines physiques.
Xamarin Test Cloud (xamarin.com/test-cloud)	Automatisés et manuels de test de toutes les applications mobiles (y compris celles non écrites avec Xamarin) sur des milliers de périphériques réels, physiques accessibles via un portail Web.
HockeyApp (hockeyapp.net)	Lancez avant distribution d’applications directement aux périphériques de clients test (pas impliquant les magasins d’applications plateforme). Également lancer préalable et surveillance de la production avec télémétrie personnalisée, incident analytique et commentaires à l’utilisateur.
Application Insights (bit.ly/1Zk9Qd3)	Données de télémétrie, diagnostics et surveillance des services back-end.
CodePush (bit.ly/28XO7Eb)	Déploiement d’application des mises à jour pour Cordova et réagir natif applications directement sur les périphériques utilisateur sans passer par des magasins d’applications.

Cette pile est applicable à tous les types d’applications mobiles : écrites pour une plate-forme mobile, les applications hybrides écrites avec Apache Cordova des applications natives et des applications multiplateformes écrites avec réagir natif ou Xamarin. Mieux encore, DevOps n’est pas un engagement tout ou rien. Au lieu de cela, elle implique un système d’activités souples et pratiques, que vous pouvez générer de façon incrémentielle, à réelle valeur ajoutée pour votre entreprise de production des applications mobiles. Il est également possible avec les nouveaux projets à générer le pipeline DevOps entière avant une seule ligne de code est écrit.

L’approche que nous examinerons dans cette série consiste à se concentrer sur les différentes étapes du pipeline « version » et examinez les parties de la pile DevOps entrent en jeu. Dans cet article j’illustrerai, toutefois, j’ai devez d’abord établir certaines nécessaires en arrière-plan. Je commencerai par décrire ce qui est un pipeline de versions et identifier les activités, puis discuter global nécessaire pour DevOps et le rôle d’outils et d’automatisation. Ensuite, je vais examiner le projet MyDriving comme exemple DevOps en action (et vous pouvez rechercher un autre exemple dans ce numéro, dans l’article « Adoption DevOps lors de la construction une Extension Visual Studio Team Services »). Enfin, je vais examiner le central rôle Visual Studio Team Services (et Team Foundation Server) dans l’article DevOps globale, préparer le terrain pour les articles en continu.

Le Pipeline de versions

L’idée d’un pipeline est que pour une version particulière d’une application ou ses services back-end, son code et autres artefacts doivent d’une certaine manière de flux à partir du référentiel de code source du projet pour les périphériques clients et serveurs accessibles par le client. Une fois sur les périphériques et les serveurs, runtime problèmes (se bloque), aux analyses de télémétrie et de commentaires directs doivent tous les flux comme apprentissages qui libère de lecteur suivant.

Bien sûr, ceci ne se produit par magie. Il se produit via une séquence d’étapes distinctes après le code est validé dans le référentiel, comme indiqué dans Figure 2. Les étapes sont les suivantes :

• Génération/CI : Générez l’application et exécuter des tests unitaires ; intégration continue (CI) signifie que la validation du référentiel déclenche une build et la série de tests si ces processus sont automatisés.
• Assurance qualité interne : Effectuer des tests supplémentaires et acquérir les déconnexions approbateur.
• Assurance qualité externe ou avant son lancement : Mettez l’application entre les mains de clients réels avant leur commercialisation, testez l’application et des services dans des conditions réelles et collecte des commentaires. Cette étape peut également impliquer les déconnexions approbateur supplémentaire.
• Production d’analyse et de formation : Quel que soit le nombre de tests vous, clients rencontrerez presque certainement des problèmes une fois que l’application est rendue publique (autrement dit, « publié en production »). Clients fournit des commentaires sur ce qui fonctionne et ce qui ne, et leurs modèles d’utilisation sont révélées par les données de télémétrie.

Figure 2 les étapes d’un Pipeline de versions standard avec des activités associées DevOps

Vous remarquerez dans Figure 2 que j’ai qualifié la plupart des activités DevOps comme une forme de test. En fait, il n’est pas beaucoup d’une extension de considérer chaque activité comme une sorte de test. Exécution d’une build, par exemple, teste la structure du référentiel et si tous les autres artefacts sont là où ils doivent être. Outils de diagnostic en cours d’exécution est une forme de tests exploratoires. Rassembler et analyser les données de télémétrie consiste à tester vos hypothèses sur comment les clients utilisent réellement l’application. Et quelles sont les déconnexions approbateur, si n’est pas un contrôle direct par un être humain que tout est qu’elle doit l’être ?

Validation en continu des performances

En tant que formes différentes de test, toutes les activités qui se trouvent sous l’égide DevOps existent pour valider la qualité, la fiabilité et la valeur de l’application de remises. Autrement dit, les activités sont conçues pour intercepter ou l’identification des défauts, ce qui signifie que tout ce qui entraîne l’application de dévier de satisfaire les attentes des clients. Il va presque sans dire, puis qui le plus souvent vous exercer DevOps — en permanence, si possible, les chances de rechercher les problèmes avant la publication.

DevOps activités sont également conçues pour intercepter les erreurs dès que possible dans le pipeline lorsque le coût de leur résolution est la plus basse (indiqué par la ligne bleue dans Figure 2). Clairement, les coûts aller bien plus une fois que l’application est publiée et défauts sont les ouvrir, moment auquel le coût peut inclure des clients perdus, endommager votre réputation et les pénalités même !

Pour placer tous les cet ensemble, les applications qui procure aux clients et cela au coût plus faible, votre meilleure « intervenants » en raison de leur apportent en fin de compte à votre entreprise. Des applications exceptionnelles, autrement dits, sont des intervenants. Pour cette raison, j’aime considérer DevOps comme la validation continue des performances dans le sens le plus large du terme. DevOps est pour le développement de logiciels quelle formation, les pratiques, les répétitions, et après de performance est les musiciens professionnels athlètes et autres intervenants dans leurs champs respectifs. Il est comment vous connaissez et faites confiance et surveiller la valeur complète de ce que vous êtes offrant, à la fois pour les clients et pour votre entreprise.

Traiter tout d’abord, puis Outils et l’automatisation

Dans une série sur les outils de pile pour les opérations de développement mobiles de Microsoft, vous pouvez penser à que l’étape suivante consiste à accéder à ces outils et commence à faire » « DevOps. Mais DevOps ne démarre pas avec les outils, ou même avec l’automatisation de quoi que ce soit. La base de DevOps est claire sur les processus et les stratégies qui définissent la façon dont vos applications et services passant entre les mains de vos développeurs dans les mains de vos clients. Il est très simple ; Par conséquent, simple, en fait, que vous pouvez certainement définir un pipeline de versions entier en écrivant les étapes nécessaires sur le papier manuellement en effectuant chacun d’eux.

Cela est parfois les plus difficiles du lancement d’un voyage en déléguant efficace. Dans un environnement d’équipe, en particulier une équipe jeune qui tente de déplacer rapidement, un pipeline de versions peut consister en une série d’étapes qui ont évolué ad hoc que chacun de ses membres « n’oubliez pas « à faire. Voici quelques exemples :

• Exécuter une build
• Exécuter des tests
• Vérifiez que les artefacts de droit non code sont en place
• Collecter les commentaires des utilisateurs de test
• Valider le package d’application dans le magasin approprié
• Déployer le code de service sur le serveur approprié (développement, test, production, etc.)
• Modifier une clé d’API de développement à la production
• Disponibilité du tweet
• Mise à jour de la page de produit sur votre site Web

Avec des itérations courtes de développement, toutes ces activités peuvent facilement devenir donc enmeshed dans la routine quotidiennes de l’équipe que personne ne se rend compte que none de celle-ci est écrite vers le bas de n’importe où, jusqu'à ce que, bien sûr, quelqu'un part en vacances, obtient malade ou quitte l’entreprise ! De plus, si tous vos processus de publication et les stratégies existent uniquement dans les gens, il est difficile de les appliquer de manière cohérente. Ils obtient invariablement corrélées avec des centaines d’autres tâches non liées néanmoins importantes. Il s’agit clairement d’opération périlleuse, particulièrement dans les environnements dans lesquels une supervision unique peut être désastreuse.

En prenant le temps d’identifier clairement les étapes impliquées, vous définissez un processus prévisibles, reproductibles et contrôlables. Avoir tout énoncés dans un emplacement accessible à tout le monde facilite également le processus vérifier et modifier, car toutes les interdépendances sont visibles. Est à son tour, la base pour l’application des outils et l’automatisation. Sinon, il est comparable à un ensemble de machines industrielles pour créer des widgets sans savoir ce que c’est que vous essayez réellement créer en premier lieu.

Nous allons être très clair à ce sujet. Automation n’est pas réellement essentielle dans un pipeline de versions, chaque étape peut être effectuée manuellement si nécessaire. Cela inclut même trivial mais questions du temps comme l’envoi de courriers électroniques de notification. Mais les processus manuels sont coûteux à l’échelle, sujet à une erreur humaine, souvent fastidieuse (et par conséquent un peu ennuyeuse pour les humains) et menacée chaque étape de la concurrence à l’attention de vos employés avec leur autres travail humains. Les ordinateurs, sont quant à eux, très performants pour les tâches répétitives indéfiniment et spontanément triviales sans mise en route Consul ou négligente de ce dernier. Il est également beaucoup plus simple pour ajouter quelques machines si vous augmentent les demandes et les mettre hors service lorsque les demandes de tomber en panne, plutôt que d’engager (et déclencher) personnel qualifié.

Est l’objectif de l’automation, puis, pour réduire les coûts et augmenter la fréquence et la qualité de vos processus, tels qu’ils sont définis simultanément, séparer les outils. Autrement dit, lorsque votre processus et les stratégies sont en place, vous pourrez ensuite progressivement automatiser différentes parties, outils permettent d’appliquer des stratégies et obtenir tous les éléments dans un formulaire qui est transparente et contrôlable. Comme vous le faites, vous libérez humaines employés à se concentrer sur les zones qui ne sont pas facilement gérées par un ordinateur, telles que la révision et l’interprétation des commentaires des utilisateurs, conception des couches de télémétrie, déterminer les formulaires plus efficaces de tester et continuellement améliorer la qualité des activités DevOps qui sont en place.

Voici un exemple : le projet MyDriving

Nous allons maintenant voir comment tout ceci est fourni avec le Microsoft mobiles DevOps de pile en examinant le projet de travail déjà appelé MyDriving (aka.ms/iotsampleapp), introduite par Scott Guthrie à Microsoft Build 2016. MyDriving est un système complet qui collecte et traite l’Internet des objets (IoT) données via une sauvegarde Azure sophistiquée terminer et fournit la visualisation des résultats via Microsoft Power BI et une application mobile écrite avec Xamarin. Il a été créé en tant que point de départ pour les projets IoT similaire et inclut le code source complet, les scripts de déploiement Azure Resource Manager et un guide électronique de référence complète.

Pour mes besoins, les pipelines de lancement MyDriving sont particulièrement intéressantes. Utiliser l’ici au pluriel, car il existe quatre procédures : une pour le code principal qui est déployé sur Azure App Service et pour l’application Xamarin sur iOS, Android et Windows.

Voici une vue d’ensemble du flux de pipeline, y compris des activités qui ne sont pas actuellement mises en œuvre :

• Gérer le code source dans un référentiel GitHub (bit.ly/28YFFWg).
• Exécuter les builds à l’aide du code dans le référentiel, y compris les sous-étapes suivantes :
  • Remplacer les jetons avec les clés nécessaires en fonction de l’environnement cible (développement, test, production).
  • Restaurer les packages NuGet nécessaires et composants Xamarin.
  • Version mise à jour les noms et numéros.
  • Exécuter la build (en utilisant le service MacinCloud pour iOS).
  • (Application uniquement) Créer et signer le package d’application comme requis par la plateforme mobile.
  • (Non implémenté) Générez les unités disponibles de projet de test.
  • (Non implémenté) Exécuter des tests dans le projet de test, Échec de la build si les tests échouent.
• Pour le code de service :
  • Copier la sortie de la build testée avec succès sur un serveur intermédiaire.
  • Déployer à partir du serveur intermédiaire sur un serveur de test et exécuter des tests.
  • S’il réussit, déployez sur le serveur de production et répétez la série de tests.
  • Surveiller le service et obtenir des rapports de diagnostic à l’aide de Application Insights.
• Pour l’application mobile sur toutes les plates-formes :
  • Déployer l’application sur le Cloud de Test Xamarin et exécuter des tests de l’interface utilisateur, Échec de la build si tous les tests d’interface utilisateur échouent.
  • Si la build et les tests de l’interface utilisateur sont réussies, copiez le package d’application sur un serveur intermédiaire.
  • Déployer l’application à partir du serveur intermédiaire vers les testeurs alphanumériques via HockeyApp.
  • (Non implémenté) Fonction approbateur déconnexion, déployer l’application pour les bêta-testeurs via HockeyApp.
  • (Non implémenté) Fonction approbateur supplémentaire déconnexion, distribuer l’application vers le magasin d’applications approprié.
  • Surveiller l’application avec les données de télémétrie et de signalement via HockeyApp.

Comme vous pouvez le voir, il s’agit d’une liste simple de ce qui doit se produire pour chaque version. Mais notez en particulier qu’il décrit ce qui doit se produire et identifie les services concernés, mais ne spécifie pas qui effectue les étapes. Cela est très important, car un être humain peut toujours asseoir avec la liste et effectuer chaque étape manuellement. En fait, c’est exactement ce qui est arrivé au commencement de MyDriving — nous l’avons fait builds manuelles et ainsi de suite afin de nous aurions pu obtenir des applications de test dans les mains de personnes tout de suite. Mais, simultanément avec les efforts de codage de l’équipe de développement, d’autres concentré sur l’automatisation de façon incrémentielle des étapes différentes jusqu'à ce que l’ensemble automatisée pipeline de versions a été établie.

Un article similaire est informé dans un autre article de ce problème, « Application DevOps à un projet de développement logiciel. » Notez en particulier comment la section « Création et publication une Extension » fait exactement ce que j’ai abordé ici : Il écrit une liste des étapes exactes dans le processus de publication. Le reste de l’article puis explique en termes d’auteur, « Notre passage vers une build automatisée et le pipeline de versions ».

Le rôle Central de Visual Studio Team Services/Team Foundation Server

Dans le projet MyDriving, Visual Studio Team Services (Services d’équipe en abrégé) est le concentrateur pour la gestion et en automatisant les pipelines de lancement et les interactions avec divers services (voir Figure 3). Étant donné que MyDriving a été créée dans un projet open source à partir du début, à l’aide d’un service hébergé sur le nuage comme Team Services n’est pas un problème. Pour d’autres scénarios, les organisations ne peuvent pas être à l’aise ou autorisé à utiliser le cloud, dans lequel cas Team Foundation Server (TFS) fournit les mêmes fonctionnalités avec vos propres serveurs locaux. Dans Ma série, je vais travailler principalement dans le contexte de l’équipe Services, mais comprendre que tout s’applique également à TFS.

Figure 3 l’équipe Visual Studio Services du tableau de bord pour MyDriving

Ces fonctionnalités essentielles sont répertoriées ici (reportez-vous à Figure 4 pour la sélection élective dans l’interface utilisateur des Services Team) :

• Contrôle de code source : Héberger des référentiels illimitée source privés et publics à l’aide de Git ou le contrôle de Version Team Foundation (TFVC), ou utiliser facilement les référentiels sur GitHub.
• Planification Agile : Suivi des éléments de travail, les récits utilisateur et ainsi de suite à la collaboration sur les tableaux Kanban, reporting et ainsi de suite. (Notez à nouveau que les aspects de planification ne sont pas traités dans cette série).
• Génération : Créer des définitions de build pour le code de service et les applications mobiles (iOS, Android et Windows), à l’aide d’un large éventail de tâches disponibles, y compris la création et exécution de projets de test (pour l’intégration continue) et le déploiement pour le Cloud de Test de Xamarin (XTC).
• Gestion de la publication : Définir des séquences arbitraires avec des approbations manuelles facultatif pour toutes les tâches qui se produisent entre les générer et de version à un « environnement », telles que le déploiement HockeyApp, Azure ou un magasin d’applications. Gestion des versions est centrée sur les environnements que vous souhaitez définir, par exemple alpha, bêta, intermédiaire et de production.

Emplacement de la figure 4 des fonctionnalités de Visual Studio Team Services

La fin d’un pipeline qui concerne Team Services est le point auquel une application est envoyée à son environnement final attribué (voir Figure 5). Après cela, DevOps concerne principalement la surveillance active de l’application dans ces environnements. Cela est où HockeyApp et Application Insights entrent en lecture, ainsi que tout autre mécanisme vous établissez pour obtenir des commentaires des utilisateurs supplémentaires (également indiqué dans Figure 5).

Figure 5 le déroulement DevOps complet pour le projet MyDriving, où le référentiel du Code est sur GitHub

À l'horizon

Au début de cet article, j’ai dit que les différentes activités et pratiques appelées DevOps correspondent aux informations que comblent le fossé entre l’écriture de code et de fourniture de valeur pour les clients à moindre coût pour votre entreprise. Vous pouvez maintenant voir que la pile Microsoft pour les opérations de développement mobiles fournit tout ce dont vous avez besoin pour gérer la qualité, réduire les coûts grâce à l’automatisation, obtenir l’application et les services dans les mains de clients, les opérations et continue de surveiller l’intégrité et recueillir des commentaires des utilisateurs, tous les flux dans la file d’attente pour les versions ultérieures. C’est le cycle DevOps, à partir de la file d’attente de la validation de code, que je vais Explorer plus en détail dans les prochains mois.

---

Kraig Brockschmidt fonctionne 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 « Applications de programmation Windows Store avec HTML, CSS et JavaScript » (deux éditions) à partir de Microsoft Press et des blogs sur kraigbrockschmidt.com.

Remercie les experts techniques suivants d'avoir relu cet article : Donovan Brown, Jonathan Carter, Glenn Gailey et Karl Krukow