Windows Azure3 LB 31/01/14 17:56 Page1download.microsoft.com/.../2014/Livre-blanc-Cloud-developpeur.pdf · Notre propos dans ce livre blanc est dillustrer comment le Cloud modifie

Windows Azure3_LB 31/01/14 17:56 Page1

2

SommaireRappelsCloud Computing ................................................................................................................3

Windows Azure ......................................................................................................................4

Impact du Cloud pour le développeur ......................................................................................................5

DevTests et DevOps ......................................................................................................9

Le Cloud Computing est sur toutes les lèvres. On enparle partout, tout le temps. Plus rarement, on évoque

l’impact du Cloud sur le développeur, qui est loin d’êtrenégligeable. En France, le marché du Cloud se rapprochedes deux milliards d’euros.

Deux approches sont à considérer : - Comment le Cloud modifie le modèle de développe-

ment des applications, l’architecture et la manière depenser l’application ;

- Comment le Cloud change les habitudes de travail dudéveloppeur.

Ces changements s’inscrivent dans un contexte particu-lier. Celui d’un marché dans lequel les entreprises ne sontplus en situation de pouvoir livrer des applications à unrythme ne prenant pas en compte la nécessité de s’adap-ter à des besoins et des conditions fluctuantes ; il leur estdevenu primordial de déterminer si les investissementsréalisés dans le développement d’une application porte-ront rapidement leurs fruits ou s’il faut les reconsidérer.

Pour mener à bien ces changements et réduire les délaisde livraison, il faut donc envisager de nouvelles pratiques,axées sur la mise en place d’itérations rapides, en modeagile, et ciblant le « continuous delivery », c’est-à-dire l’in-tégration, voire le déploiement continu des applicationsà livrer. Le « continuous delivery » se fonde sur l’approchehistorique de l’ALM (Application Lifecycle Management)en rationalisant, grâce au Cloud et à la mise en place descénarios « DevTests », le processus mais aussi l’infra-structure de développement. Tandis que la démarche « DevOps » apparaît de plus en plus incontournable enpermettant une accélération des déploiements tout en

réduisant les frictions opérationnelles entre les équipesde développement et d’infrastructure.

Notre propos dans ce livre blanc est d’illustrer commentle Cloud modifie le métier, le quotidien et les outils dudéveloppeur. Les changements sont profonds et repren-nent la philosophie du Cloud : flexibilité et élasticité à lademande.

Comme vous le verrez tout au long de ce livre blanc, nouspouvons aller très loin dans ces deux domaines, maisc’est à vous que revient la responsabilité de trouver lejuste équilibre. Comme avec une méthode agile, il ne fautpas appliquer strictement l’intégralité des pratiques as-sociées aux approches « DevOps » et « DevTests », maischoisir celles dont vous avez réellement besoin. n

Imprimerie Jaures, 10, rue Vicq d’Azir, 75010 ParisMICROSOFT France, RCS Nanterre 327 733 184, 39, quai du Président Roosevelt 92130 Issy Les Moulineaux

Ne pas jeter sur la voie publique © Microsoft 2014. Tous droits réservés - Document non contractuelCoordination : Marwan Elfitesse (Microsoft France).

Introduction

Stéphane Goudeau Cloud Architect – Microsoft France

François Tonic Rédacteur en chef de cloudmagazine.fr / Programmez!


3

Cloud Computing : rappels

Cloud publicUn Cloud public est un service déployé et gérépar le fournisseur (Microsoft déploie et adminis-tre Windows Azure) dans ses datacenters (ou desdatacenters loués, ou via des partenaires). L’infra-structure Cloud y est mutualisée pour être utiliséepar les clients. L’exploitation, dont le niveau varieselon le type de service (PaaS ou IaaS) est de laresponsabilité de l’utilisateur. On paie à l’usage.

Cloud hybrideLe Cloud hybride se caractérise par la mise enœuvre d’infrastructures distinctes. Elles sont liéespar des passerelles, des connexions pour faciliterle bon fonctionnement des applications et desdonnées : typiquement utiliser un Cloud publicet des ressources internes à l’entreprise. Un desscénarios les plus courants est le débordementde ressources sur un Cloud public (ou bursting) :une entreprise a besoin de ressources supplé-mentaires (serveurs, stockages, etc.) pour absor-ber un pic d’utilisation, elle utilise alors desressources d’un Cloud public. Autre scénario :connecter des applications mobiles à des servicesde Cloud. Enfin, l’infrastructure d’un Cloud hybridepeut résulter de la composition de multiples Clouds(cf http://nitaac.nih.gov/nitaac/cloud-computing).

Cloud privéLe Cloud privé est souvent synonyme de IaaS. Ils’agit d’utiliser et de déployer des couches de vir-tualisation, de provisionnement, d’automatisationet de catalogues de services pour une utilisationinterne à l’entreprise (sur un site ou sur l’ensem-ble des filiales). Le Cloud privé comprend des res-sources à la demande, un catalogue de services.Il peut être déployé et exploité soit directementpar l’entreprise, soit par un tiers. Il existe desclouds privés externalisés. Il est aussi possible decréer du PaaS privé (Private PaaS), par exempleles Web Sites du Windows Azure Pack.

Cloud communautaireL’infrastructure Cloud est configurée pour uneutilisation exclusive par une communauté d’uti-lisateurs, d’entreprises qui partagent les mêmespréoccupations (missions, exigences de sécurité,politiques et considérations de conformité). LeCloud communautaire peut être, ou non la pro-priété de l’entreprise, être déployé ou non à de-meure et être exploité soit directement par unou plusieurs des organismes de la communauté,soit par un tiers (ou une combinaison des deux).Exemple : UnivCloud (Cloud communautairepour les universités d’île de France).

1. Modèles de servicesLe Cloud Computing propose plusieurs modèlesde services : l’infrastructure as a service (IaaS), laplateforme as a service (PaaS) et le software asa service (SaaS). Le schéma suivant montre lesservices automatisés (dits managés) en gris etles services gérés par l’entreprise et les adminis-trateurs en bleu. Le PaaS permet aux dévelop-peurs de se concentrer sur les données et lecode. Le fournisseur de Cloud va gérer toutes lescouches « middleware » : moteurs de données,systèmes d’exploitations, runtimes, environne-ments de développeurs. En IaaS, il est possible de personnaliser les envi-ronnements (machines virtuelles) et de créer desworkloads dédiés. En IaaS, l’utilisateur garde le contrôle et la ges-tion de la couche opérationnelle (système, logi-ciels, logiciels serveurs…).

2. Modèles de déploiementLe Cloud Computing propose trois principauxmodèles de déploiement : privé, public et hybride. Chaque modèle peut avoir un impact sur le dé-ploiement et l’utilisation de vos services.

D’après la définition du NIST (National Institute of Standards and Technology), leCloud Computing présente cinq caractéristiques essentielles, trois modèles de serviceset quatre modèles de déploiement (cf Definition of Cloud Computing v15) que sont lamutualisation des ressources, l’accès aux ressources en mode « libre-service », leréseau ubiquitaire, l'élasticité, la facturation à l’usage (« je paie ce que j’utilise »).

Cloud computing


4

Windows Azure est l’offre deCloud Computing de Micro-

soft pour héberger les services, toustypes de données et les applicationsd’entreprise (quel que soit le lan-gage). Windows Azure propose à lafois du PaaS (développement, dé-ploiement d’applications, servicesmanagés) et du IaaS (pour exploiterdes machines virtuelles Windows,Linux).

1. Les services PaaSLe PaaS Windows Azure prend doncen charge un certain nombre deconcepts de l’infrastructure :• Modèles d’environnements prédéfinis ;• Approvisionnement sur demande, en libre-ser-

vice, et automatisé de ces modèles ;• Surveillance des ressources utilisées ;• Gestion élastique des ressources en fonction

de leur utilisation ;• Garantie de continuité de service pour les

applicatifs hébergés, même en cas de pannematérielle, de mise à jour du système d’exploi-tation ou de mise à jour de l’applicatif lui-même.

Son objectif est donc de faciliter le développe-ment, le déploiement et l’exécution d’applica-tions et services dans un modèle de libre-serviceà la demande. Pour ce faire, Azure propose audéveloppeur de bâtir son application en se fon-dant sur l’utilisation de modèles : les rôles.

Les différents rôles Il existe deux types de rôles : le WebRole (mo-dèle dédié à l’hébergement d’applicatif web) etle Worker Role (destiné à implémenter différentstypes de services). Les services et solutions sontconstruits avec une combinaison de Web Rolesou de Worker Roles, se répartissant les tâches àexécuter.

Les composants PaaSLa plateforme propose un ensemble de servicesdestinés à être utilisés individuellement ou demanière combinée par les développeurs. Nous ytrouvons : Service Bus, Media Services, un sys-tème de caching, Active Directory, SQL Data-base… et la liste s’allonge presque chaque mois.

Le packaging et déploiement des services PaaSPour implémenter une application Cloud, le dé-veloppeur dispose d’un type de projet Cloud. Ilva pouvoir développer avec les langages .net,mais aussi PHP, Java, Ruby, Python, etc.Visual Studio permettra d’éditer les deux fichiers

XML de définition : .csdef (la liste des rôles, lataille des machines virtuelles, les portsd’écoute…) et de configuration .cscfg (le nombred’instances de chaque rôle, la configuration descertificats…) devant être utilisés pour la topolo-gie du Cloud Service. Ces fichiers sont intégrésau package .cspkg (contenant les binaires) dedéploiement du service hébergé. Le déploiement du package peut être réalisé di-rectement depuis Visual Studio.

2. Les services IaaSLes services d’infrastructure Windows Azure per-mettent de créer, déployer, démarrer et gérerdes machines virtuelles Windows ou Linux (for-mat VHD). La virtualisation de l’infrastructurephysique, le stockage et le réseau sont directe-ment gérés par Windows Azure.Différents modèles de création et de déploie-ment sont proposés :• Création à partir d’une image proposée nati-

vement dans la galerie Azure ;• Création d’une machine virtuelle à partir d’un

disque VHD persisté dans le stockage Azure.On récupère alors le dernier état de la VMayant utilisé ce disque ;

• Création d’une image par capture et prépara-tion d’une machine virtuelle existante en vuede la rendre générique ;

• Téléchargement de machines virtuelles confi-gurées à demeure sur un serveur VHD.

Différentes tailles d’instances sont disponibles.Chaque instance correspond à une taille de res-sources : processeur, mémoire vive, stockages,entrées/sorties, bande passante. Les machinesvirtuelles sont persistantes, grâce à l’utilisationd’objets blobs, hébergés dans les services destockage Windows Azure. La fonction auto-sca-ling (montée en charge « automatique ») est dis-ponible sur le IaaS et le PaaS.

Windows Azure : rappels

3. Cloud Services et scénariosmixtes PaaS-IaaSSous Windows Azure, PaaS et IaaS ne sont pasisolés. Les machines virtuelles sont regroupéesau sein de Cloud Services. Un Cloud Service estun conteneur logique permettant de gérer la su-pervision, la configuration, la sécurité, le réseau,voire la topologie d’une collection de machinesvirtuelles. Un Cloud Service peut contenir desinstances de rôles PaaS ou des machines vir-tuelles IaaS, mais il ne peut pas héberger lesdeux types de machines virtuelles.

4. Sites Web : déployerdirectement votre site sur le CloudLes Azure Web Sites offrent un service d’héber-gement permettant la construction rapide deserveurs Web avec la possibilité d’utiliser desgestionnaires de contenu populaires tels queDrupal, Umbraco, .NetNuke, Joomla, Mojo,phpBB, WordPress... Ce service est fondé surl’utilisation du serveur internet IIS (Internet In-formation Server) et de son extension ARR (Ap-plication Request Routing). Ce service supporteASP.Net, Node.JS, PHP, Git, WebDeploy, TFS, FTP…

5. Windows Azure et lesterminaux mobilesL’objectif est d’utiliser un ou plusieurs servicesCloud en back-office couplés avec une applicationmobile. Ce service facilite l’écriture d’applicationsmobiles pour Windows 8, Windows Phone, HTML5Client, iPhone/iPad, Android ou Xamarin en accé-lérant la mise en place des services de notification,de stockage de données et d’authentification desutilisateurs entre l’application et Windows Azure.

Déploiement d’une application sous Windows Azure


5

Le Cloud est un accélérateur de déve-loppement :

• Rapidité de mise à disposition d'envi-ronnement d'exécution (mutualisationet disponibilité des ressources) ;

• Facilité de l'évaluation des technolo-gies via prototypage (Proof of Concept)sur des environnements disponibles àla demande ;

• Pré-installation d'environnements ser-veurs proposés par Microsoft (SQL Ser-ver, SharePoint Server, Biztalk Server,les solutions Oracle, Linux...) ;

• Partage et automatisation du déploie-ment de plateformes pour les tests, lesdéveloppements ou l'intégration ;

• Activation de services applicatifs liés àla solution cible (Azure SQL Database,Azure Active Directory, Azure ServiceBus, Azure Biztalk Services,...) ;

• Outillage Cloud avec Visual Studio Online ciblantla construction, l'observation du comportementet l'évolution des applications dans le Cloud ali-gnée sur les bonnes pratiques du « continuousdelivery » : agilité et industrialisation des déve-loppements, intégration continue, démarchedevOps.

1. Evolution des applicationsvers le PaaSAvec le PaaS, le développeur se concentre surl’application et sur son code. Le PaaS expose desAPI, des services, des SDK. Il inclut des runtimesd’exécution. Windows Azure est ouvert à demultiples environnements de développement :.Net, Java, PHP, Ruby, Node.js, Python… L'ouver-ture est une de ses forces.Adapter et migrer une application pour le Paasn’est pas toujours une tâche très aisée. Il fautsouvent modifier l’architecture logicielle, chan-ger les couches d’accès aux données, évaluer lasécurité. Techniquement, cette migration n’est pas insur-montable, mais le coût et la durée du redéve-loppement sont à considérer. Pour le développeur, le Cloud impacte le déve-loppement et sa façon de travailler. Pour bien utiliser Windows Azure, il doit connaî-tre et comprendre les différents services, les SDK

Impact du Cloudpour le développeur

et API, choisir ceux qui lui seront utiles, et inté-grer les bonnes pratiques. Mais fondamentalement, développer une appli-cation en mode Cloud (PaaS ou IaaS), par exem-ple, pour faire un service SaaS ou utiliser desservices Cloud, n’est pas plus compliqué qu’undéveloppement « classique ». Le développeur devra néanmoins être vigilantsur les points suivants :• Architecture logicielle (single-tenant ou multi-

tenant, architecture FailSafe) ;• Choix des API, frameworks et librairies du ou

des services : chaque fournisseur propose sespropres librairies et bonnes pratiques ;

• Optimisation du code, des accès, des données :toute ressource consommée est facturée ;

• Prise en compte des critères de disponibilité,de performance, de sécurité et d'autres as-pects critiques.

2. Gestion des montées de version du mode PaaSLes services Cloud sont déployés et exécutés surdes machines virtuelles. Il s’agit d'un systèmed'exploitation Windows Server optimisé pourfonctionner dans cet environnement. Ce sys-tème d’exploitation évolue régulièrement et faitdonc l’objet de mises à jour. Celles-ci sont né-cessaires pour s’assurer que les solutions déve-

loppées sur le PaaS Azure sont adossées à dessystèmes fiables et sécurisés, intégrant les der-nières innovations. Il est donc impératif pour ledéveloppeur comme pour le responsable sys-tème d’avoir une bonne compréhension de lafaçon dont les mises à jour sont appliquées, etcomment elles peuvent impacter la disponibilitéet la facilité de maintenance des applicationsdont ils sont responsables. Ce modèle délègue à Microsoft la responsabilitéde gérer l’infrastructure sous-jacente et notam-ment les mises à jour. Il serait inapproprié desupposer que cette délégation dispense lesclients de se préoccuper des mises à niveau dessystèmes d'exploitation hébergés. L’utilisateurd’Azure peut décider de contrôler la version deWindows Server déployée dans ses servicesCloud, en utilisant l'attribut « osFamily » dans lefichier de Configuration du Service (.cscfg). A cetattribut « osFamily » s’ajoute l’attribut « osVer-sion ».La configuration du service Cloud permet dechoisir la mise à jour automatique des versionsdu système d’exploitation hébergé en spécifiantl’attribut « osVersion » avec un astérisque « * »(mais pas la mise à jour automatique de la « fa-mille » du système d’exploitation, donc pas demise à jour automatique de Windows Server2012 à Windows Server 201X). Toutefois, sur leplan théorique, suivant la nature du service

Le PaaS et le IaaS impactent la manière de développer et de déployer aussi bien lesapplications que les sites web. Comment et pourquoi le Cloud révolutionne-t-il ledéveloppement ?

Impact du Cloud


6

Cloud, il faut envisager la possibilité qu’unsimple changement de version (par exem-ple un correctif de sécurité) puisse être incompatible avec le code qui s'exécutedans l’application déployée sur la machinevirtuelle.Si l’utilisateur de ces services est habitué àdéployer les patches de sécurité sur dessystèmes de test ou de pré-productionavant de les appliquer sur sa production, ilpréfèrera très certainement définir ma-nuellement l’attribut « osVersion » en cor-respondance avec ses processus internesde validation de version.Le développeur est également directementconcerné par cette gestion des versions dusystème d'exploitation des machines vir-tuelles hébergées. En effet, une correspon-dance est établie entre le Windows AzureSDK et certaines des versions du système d'ex-ploitation invité. C’est donc à lui qu’incombe laresponsabilité de choisir un SDK compatibleavec la cible de déploiement. Fort heureuse-ment, la probabilité qu’une prochaine version desystème d'exploitation hébergé (et potentielle-ment automatiquement mis à jour) ne supportepas le SDK avec lequel le code a été compiléreste extrêmement faible. Chaque nouveau système d’exploitation esttesté, lors de sa publication, avec les deux der-nières versions du SDK. Les compatibilités desfamilles de système d’exploitation et de SDKsont référencées dans la documentation en ligne :http://msdn.microsoft.com/en-us/library/windowsa-zure/ee924680.aspx. Lorsqu’une nouvelle versiondu SDK est publiée, les clients ont jusqu'à un anpour moderniser leurs solutions en la recompi-lant avec un SDK supporté.Les montées de versions manuelles imposent lesuivi et le test des versions de système d'exploi-tation hébergées qui doivent être « ciblées »avant d'être appliquées. Les montées de versions automatiques ne per-mettent pas le contrôle avant publication, maisdoivent être accompagnées de tests systéma-

tiques pour mieux les anticiper. Dans les deux cas, cette démarche sera facilitéepar la mise en place d'un environnement per-mettant de faire évoluer l’application à chaquenouvelle version de SDK, et de la tester pourchaque mise à niveau de système d’exploitationhébergé. D’où l’intérêt de l’automatisation destests de non régression sur un environnementdont on maîtrise la configuration. Le processus qui permet d’effectuer cette vali-dation comprend les étapes suivantes :• Compilation de l’application avec la dernière

version du SDK ;• Exécution des tests unitaires (s’il y en a) ;• Déploiement de l’application sur une machine

virtuelle de test déployée dans Azure ;• Exécution de tests supplémentaires (d’inter-

faces Web automatisées, par exemple).Ce processus devra être déclenché à chaquenouvelle publication de version. Une façon de se tenir à jour consiste à s'abonnerau flux RSS d’information sur les versions de sys-tème d’exploitation : http://sxp.microsoft.com/feeds/3.0/ msdntn/WindowsAzureOSUpdates.Pour la validation du fonctionnement du CloudService, il est préférable d’aller au-delà du sim-

ple démarrage de l’instance de chaquerôle. Par exemple, dans le cas d’un CloudService hébergeant un Web Role, il serautile de mettre en place un test permettantde reproduire le scénario de navigation surl’application ou le service Web.

3. Architecture logicielleLe multi-tenant, clé de voûte du Cloud ComputingPour bénéficier de toute la puissance duCloud, une application SaaS doit adopterune architecture spécifique : le multi-te-nant (ou architecture multi-tenancy) Fig.1et 2. Sans cette spécificité, l’applicationconsommera inutilement des ressources etne profitera donc pas des économiesd’échelle associées au Cloud.

Le multi-tenant a pour objectif de mutualiserune même application (un même code) entredifférents clients. Le multi-tenant s’appliqueaussi bien à l’application qu’aux données.Concrètement cela signifie pouvoir mutualiser 1application / 1 base de données pour N clients.Il existe des modes de multi-tenancy intermé-diaires (par exemple 1 application / N bases dedonnées pour N clients : ce mode est fréquem-ment utilisé par les éditeurs logiciels qui utilisentAzure SQL Database et paient donc le service enfonction de la taille de la base). Par opposition le single-tenant signifie : 1 appli-cation = 1 client. En multi-tenant, l’isolation des instances et desdonnées de chaque client est primordiale. Au-cune fuite ne doit exister. Le multi-tenant peut concerner les applicationscomme les services Cloud. Il permet d’utiliser laflexibilité des capacités du Cloud, d’assurer unemeilleure montée en charge, tout en optimisantles ressources utilisées. Il suppose la mise en place de mécanismes degestion d’identité (contrôle d’accès, annuaire,service de jeton, éventuellement fédération desidentités).

3

Vue logique d'une architecturesingle-tenant et d'unearchitecture multi-tenant

Exemple d'une architecture pour Windows Azure. Ce n'est pas l'unique design possible.Dans la pratique, une application Windows Azure se compose de nombreux services.Ces éléments peuvent être utilisés par des architectures single ou multi-tenant

1 2


7

Architecture FailSafeSi l’on patiente suffisamment longtemps ou sil’on lui applique une pression suffisammentforte toute application ou service finit par ren-contrer un dysfonctionnement. Il s’agit doncd’anticiper cette situation en définissant la façondont l’application doit se comporter, et notam-ment en proposant une gestion souple desmodes de défaillance afin qu’elle puisse conti-nuer à offrir une valeur ajoutée.Définir une architecture « FailSafe » requiert lacatégorisation des types d'échecs :• Transitoire - interruption de service tempo-

raire, d'auto-guérison• Enduring – intervention nécessaire• Périmètre de la défaillance – Région, Service,

Machine.Cela suppose également la prise en compte desSLAs liés aux divers composants de la solution,la mise en place de mécanisme de surveillanceet de télémétrie, la gestion des erreurs transi-toires, l’utilisation d’une solution de mise encache distribuée, et enfin un couplage faibleentre les principaux composants de la solution.Ce mode de conception d’une architecture dite « FailSafe » est décrit dans le whitepaper « Fail-safe: Guidance for Resilient Cloud Architectures »

de Marc Mercuri, Ulrich Homann, et AndrewTownhill http://msdn.microsoft.com/en-us/library/windowsazure/jj853352.aspx)

4. « Continous Delivery » :Intégration, déploiement, et suivi en continu desapplications Processus de « Continuous Delivery »Le « continuous delivery » est un processus re-groupant de multiples pratiques destinées à ap-porter de la valeur en continu, en déployant leplus fréquemment possible de nouvelles ver-sions d'une application ou d'un service. L’un desouvrages de référence est le livre de Jez Humbleet David Farley : « Continuous Delivery: ReliableSoftware Releases through Build, Test, and De-ployment Automation ».Le « continuous delivery » englobe :• L'intégration continue qui vise à réduire les ef-

forts d'intégration en assurant automatique-ment la génération, l'assemblage et les testsdes composants de l'application ;

• Le déploiement continu qui consiste à auto-

matiser le déploiement du logiciel construit surla plateforme cible (test, intégration, pré-pro-duction voire production) à chaque nouvellegénération de livrable ;

• Le suivi en continu du comportement de l'appli-cation sur le plan technique mais également dupoint de vue de son usage afin d'améliorer l'ef-ficacité de la solution Fig.3.

Intégration continueLe processus de développement démarre avecun outil de contrôle de version du code sourcede l’application, et s’achève par le déploiementdes binaires dans l'environnement de produc-tion. Dans l'intervalle, le code doit être compilé,les environnements doivent être configurés, denombreux types de tests doivent s’exécuter… En effet, dès qu’il y a plus d’un développeur quisera appelé à modifier le code source de l’appli-cation, il est crucial de valider fréquemment l’in-tégration du travail de chacun avec celui desautres. Pour cela, une validation manuelle localepar le développeur lui-même ne suffit pas. L’idéal est d’effectuer un ensemble de vérifica-tions sur un environnement dont on maîtrise laconfiguration et indépendant des postes del’équipe de développement. Chaque intégration

4

Impact du Cloud


8

est vérifiée par une génération automatisée (ycompris le test) pour détecter les erreurs d'inté-gration dès que possible. Le processus qui per-met d’effectuer cette validation est courammentappelé « Chaîne d‘intégration continue ». Ce processus comprend en général les étapessuivantes :• Le développeur fait évoluer le code et procède

à des tests localement sur son poste de travail.Cela inclut l'écriture de tests unitaires automa-tiques. Le code est archivé dans le contrôle decode source ;

• Un serveur de builds extrait la dernière versiondisponible du code depuis le contrôleur decode source. Il compile, exécute les tests uni-taires pour s’assurer de la qualité du code pro-duit et crée des packages de déploiementselon l'environnement de déploiement cible.

• Les packages sont déployés sur la plateformecible installée sur Azure ;

• Des tests supplémentaires sont automatique-ment lancés (tests d’interfaces graphiques au-tomatisés, tests de vérification du bondéploiement,…).

Généralement, ce processus, est déclenché leplus fréquemment possible : à chaque mise à jourdu référentiel de code source. Il peut cependantêtre effectué régulièrement sans pour autant lefaire à chaque archivage…. Idéalement, les phasesd’intégration explicite deviennent optionnellespuisque le code est toujours intégré. L'automati-sation du processus de génération des livrablesest un facteur déterminant de la mise en place dece workflow. Elle garantit le principe d'une opé-ration reproductible, fiable et prévisible.

Déploiement continuIl ne suffit pas d'automatiser le workflow lui-même, mais aussi la création des environne-ments, leur mise en service, et la maintenancede l'infrastructure. Cette automatisation permetde ne pas gaspiller du temps en tâches pouvantêtre directement réalisables par le système. Undes axes d’optimisation du développement surle Cloud va donc consister à personnaliser leworkflow de gestion des versions (« release pi-peline ») en utilisant les modèles de générationpar défaut fournis par Team Foundation Server(TFS) ou Visual Studio Online Fig.4. WindowsAzure offre de nouveaux scénarios de déploie-ment par rapport à une infrastructure à de-meure, avec la possibilité de tests dans unenvironnement de production, de déploiementcontinu des applications, et d’agilité accrue avecla facilité de déploiement. Dans le cas du PaaS,le scénario de déploiement dans Azure s’articuleautour d’un certain nombre d'étapes qui peu-vent s’orchestrer dans le processus de généra-tion et de déploiement :• Création du package pour le déploiement ;• Téléchargement du package dans le stockage

Azure ;• Création des instances de l'application dans le

nuage selon les directives de configuration ;

• Démarrage des instances déployées ;• La solution peut être déployée directement

dans une zone baptisée « Staging » dans leportail Azure avant d’être manuellement « bas-culée » en production. Il ne s'agit pas d'un en-vironnement de pré-production, mais plutôtd'une zone de « smoke tests ».

Suivi en continu du comportement de l’applicationL’application doit pouvoir s'adapter en perma-nence aux besoins de ses utilisateurs et il est né-cessaire de s'assurer que les services proposésfonctionnent comme prévu. La mise en place demécanismes de supervision technique et de té-lémétrie, permet de savoir comment les solu-tions sont utilisées et la façon dont ellesfonctionnent. Application Insights est une com-

posante de Visual Studio Online qui offre lesfonctions suivantes :• Définition de tableaux de bord pour avoir une

vue d’ensemble de l’application Fig.5 ;• Affichage des informations de performance et

de disponibilité des applications en considérantla connectivité à ces applications depuis despoints d’observation localisés dans le mondeentier et définition de seuils d’alerte Fig.6.

La collecte d'informations au moyen de mesuresexternes peut également être réalisée à l'aide deproduits tels que System Center Global ServiceMonitor. Ces mécanismes sont cruciaux pouraméliorer en permanence l'application. Ils per-mettent de garantir la qualité du service pro-posé tout en permettant de s’adapter àl'évolution du marché.

5

6


9

Le scénario « DevTests »En parallèle du « Continuous delivery », lesclients ont aujourd’hui la possibilité de tirer partides ressources dont ils disposent en interne oudans le Cloud pour déployer leurs environne-ments de développement et de test. WindowsAzure permet d’automatiser la mise à disposi-tion de ces environnements sur des servicesCloud (typiquement du IaaS et/ou sur des ser-vices à la demande) d’une manière fiable, sécu-risée et rapide. Ce type de scénario est baptisé« DevTests ». Pourquoi avoir recours à Azurepour les scénarios « Développement et Tests » ?

MotivationsLa première raison est de faire bénéficier les dé-veloppeurs d’une infrastructure à la demandecapable de rapidement monter en charge. Eneffet, avec ses services d’infrastructure , Win-dows Azure fournit une excellente plateformepour vite déployer des infrastructures de déve-loppement et de test. Celle-ci intègre :• Des services de stockage ;• Des services de réseaux virtuels avec en option

la possibilité d’établir des liens VPN pour offrirune connexion réseau sécurisée depuis l’infra-structure à demeure ;

• La possibilité de déployer des serveurs d’infra-structures dans le IaaS (gestion d’identité avec

Active Directory, Hyper-V Recovery Manager,Windows Azure Backup,…) ;

• Des machines virtuelles persistantes dans leCloud offrant un large choix de dimensionne-ment : jusqu’à 8 cœurs, 56GB de RAM et 16disques (max 1TB, soit 16 TB max) ;

• Des images fournies avec la plateforme Azure,proposant une liste croissante de produits Mi-crosoft et non Microsoft, nativement suppor-tés dans Azure ;

• La possibilité de construire des images person-nalisées ;

• La capacité à automatiser la création de VM viades commandes PowerShell ;

• L’intégration avec les services de la plateformeAzure.

Le scénario « DevTests » offre une solutionadaptée aux équipes géographiquement disper-sées et aux entreprises ne souhaitant pas dé-ployer des infrastructures dédiées, parfoislourdes à mettre en oeuvre et à maintenir.

PerspectivesLe « DevTests » peut être envisagé selon plu-sieurs scenarii :• Déploiement des environnements serveurs de

test d’intégration et de pré-production ;• Evaluation de logiciels ;• Installation de l’infrastructure ALM, Application

Lifecycle Management (contrôle de version,

gestion des builds, release management, etc.)qui peut être déployée dans un modèle deCloud, éventuellement hybride ;

• Fourniture de postes virtualisés pour le déve-loppeur ou le testeur.

Déploiement des environnements serveursde testLe « DevTests » permet de pré-packager desimages virtuelles contenant les environnementscibles. Ceci évite d’immobiliser des ressourcesdédiées à demeure. Un autre avantage est la ca-pacité de déployer directement dans l’environ-nement Windows Azure au cours du processusde génération, ce qui permet de tester les appli-cations dans le même environnement que celuisur lequel tournera l’application une fois en pro-duction; cela garantissant ainsi la compatibilitéentre les plateformes de test et de production.La notion de prêt à l’emploi est importante. Pourun développeur, un testeur, il s’agit de disposerdes bons outils et environnements le plus rapi-dement possible, sans avoir de contrainte de res-sources. Les environnements de tests et de LabManagement sont parfois très lourds à mettre enœuvre. La plateforme Windows Azure permet demettre à disposition autant d’environnements ci-bles que nécessaire. Vous les montez et démon-tez.. Et surtout vous payez à la demande.

Evaluation de logicielsUn service, ou une application, est fréquemmentamené à évoluer, soit parce qu’il faut procéder àune montée de version du système d’exploitationcible (de Windows Server 2008 à Windows Server2012 R2), soit parce qu’il intègre des dépen-dances par rapport à un composant système quel’on souhaite remplacer, soit encore parce quel’on souhaite associer un logiciel tiers à la solu-tion. Pour bien gérer ces évolutions, il convientde mesurer leur impact. La plateforme Azure per-met alors de réaliser les tests correspondantsdans les plus brefs délais et à moindre coût.

Mise en production d’une infrastructure d’ALMLe DevTests concerne aussi les outils. L’infra-structure requise pour le développement peut

DevTests et DevOps : profitez des avantages du CloudNous avons vu dans le chapitre précédent comment le Cloud, et particulièrementWindows Azure, impacte le développement et pas seulement l’architecture logicielle.Dans ce contexte, il est très important de comprendre les motivations et lesperspectives qu’offre le scénario « DevTests » ainsi que les principes de la philosophie« DevOps ». Comment et pourquoi utiliser ces deux approches ?

1

DevTests/DevOps


10

elle-même être déployée sur la plateforme Win-dows Azure, et proposer des services de gestiond’identité commune avec celle de l’infrastructureà demeure, de gestion des tests, de gestion ducycle de vie de l’application. Ceux qui ont déjàdéployé une infrastructure ALM savent que cen’est pas trivial, et que la maintenir ne l’est pasmoins. Team Foundation Server (TFS) est serveurde l’offre ALM Visual Studio (démarche agile,backlog, tâches, automatisation des builds, tests,gestion de configuration, portail d’équipe, re-porting, etc.). Il est également possible de dé-ployer TFS sur des VM sur Windows AzureMachines Virtuelles ou sur ses serveurs dansune démarche hybride. Le 1er schéma illustrecette approche Fig.1. TFS est aussi disponiblesous forme de services : Visual Studio Online.Vous pouvez aujourd’hui disposer rapidementd’un environnement ALM très complet,connecté à vos environnements de développe-ment. Vous n’avez plus à déployer sur votre in-frastructure : aucune maintenance, aucune miseà jour. Tout est géré par le service en ligne ! Ceservice Windows Azure propose un portail d’ac-cès aux différents projets de développementavec une page d’accueil personnalisable per-mettant d’avoir une vue complète sur les diffé-rents composants de son projet (sprint etbacklog, contrôle de code source TFS ou GIT,tests, builds, membres de l’équipe, team rooms,tableaux de bord,…) Fig.2.Visual Studio Online permet de choisir différentsmodèles associés à la méthodologie de déve-loppement (CMMI, MSF Agile ou Scrum). Lesméthodes agiles décomposent les actions enpetites étapes de planification (itération de 1 à4 semaines). Chaque itération cible un travaild’équipe, à travers un cycle de développementlogiciel complet. Cela permet de minimiser lerisque global et de s’adapter rapidement auxchangements. L’objectif est d’avoir une versiondisponible à la fin de chaque itération. Lorsquel’on développe une application, il est toujoursnécessaire d’avoir une liste de fonctionnalités àdévelopper. L’organisation de cette liste serafonction de la méthode adoptée par l’équipe. • Dans une méthode « classique », la liste des

fonctionnalités est découpée selon une arbo-rescence d’exigences ;

• Dans une méthode agile, on utilise une listeque l’on nomme « backlog ».

Le backlog est une pile des différentes fonctionsproposées par l’application. Cette liste est sus-ceptible d’être alimentée en continu. Elle évoluedonc sans cesse et permet de définir les délaisde mise à disposition d’une nouvelle fonction-nalité. Le Portail Visual Studio Online permet dedéfinir et faire évoluer cette liste Fig.3.Visual Studio Online offre des services de Build,qui, couplés avec un mécanisme de déclenche-ment automatique de déploiement, assurent lamise en place du processus d’intégration conti-nue Fig.4. Visual Studio Ultimate permet de gé-nérer des tests en simulant la charge utilisateur

2

3

4

sur les applications Internet et les serveurs pourdonner des informations précises sur le compor-tement de l’application ou du service Clouddans un mode de fonctionnement proche de laréalité. Les résultats permettent de connaître lesperformances de l’application, de dimensionnerles machines pour des performances optimales,en un mot d’anticiper. Visual Studio fonctionneavec toutes les technologies d’applications Web.Pour ce faire, il est nécessaire de mettre en place

un « rig de test » constitué d’au moins uncontrôleur de test et d’un agent. Un contrôleurde test est un service Windows qui a pour rôlede connaître un ensemble d’agents de tests etde les piloter. Les agents de tests sont égale-ment des services Windows qui, quant à eux, ontpour rôle d’héberger et de simuler les utilisa-teurs virtuels. Dans une telle configuration, Vi-sual Studio n’est plus là que pour piloter le tout.Le test de charge réside sur le client Visual Stu-


11

dio depuis lequel le testeur va configurer et lan-cer le test de telle sorte que les injecteurs (lesagents de charge) génèrent la charge depuis dif-férents emplacements sur l’application web.Avec Visual Studio Online, plus besoin de confi-gurer et de déployer ce « rig de test ». Il suffitd’indiquer au niveau de Visual Studio que lestests de charge seront réalisés depuis des injec-teurs s’exécutant sur la plateforme WindowsAzure. C’est donc beaucoup plus simplementque peuvent s’exécuter les tests de charge au-jourd’hui, et sans impact sur l’infrastructure in-terne : le Cloud offre une montée en chargequasi-illimitée…

Capacité à délivrer des environnements detravail pour les développeurs et testeursL’utilisation de système d’exploitation client n’estpas supportée aujourd’hui sur la plateformeAzure. Cette limitation contractuelle permetnéanmoins d’envisager des scénarios VDI (Vir-tual Desktop Infrastructure) fondés sur la miseen oeuvre du protocole RDP sur une machineWindows Server 2012 R2. En effet, l’accès au protocole RDP est activé pardéfaut sur toutes les images de Galerie de Win-dows et les paramètres RDP sont configurés au-tomatiquement pendant la configuration de laVM afin que le port local 3389 soit ouvert sur lamachine virtuelle ainsi qu’un port externe confi-guré de façon aléatoire dans la plage IANA49152 à 65535. Le fichier RDP peut ensuite êtretéléchargé à partir du portail de gestion ou viales cmdlets PowerShell Azure ou par API REST.La connexion RDP doit être réalisée sur le FQDNdu service Cloud associé à la VM de test/déve-loppement, ou sur son adresse IP publique(adresse VIP), en complétant l’un ou l’autre parle port externe configuré dans le portail. Pourles scénarios d’usage impliquant de multiplesconnexions sur la même machine, il est égale-ment possible de configurer RDS.L’utilisation d’une souscription Azure associée àun compte MSDN permet ainsi de disposerd’une image pré-installée avec VisualStudio2013 à destination des développeurs.

Implémentation d’une infrastructurede Développement et TestL’implémentation d’une infrastructure de déve-loppement et tests dans un Cloud public comme

celui proposé par la plateforme Windows Azuresuppose le respect, la planification et la mise enœuvre de bonnes pratiques de gouvernance quirecouvrent différents sujets.• Gestion des souscriptions ;• Facturation des ressources ;• Choix du type d’hébergement des services ;• Sécurité et gestion d’identité ;• Configuration des référentiels d’images.

Gestion des souscriptionsLorsque l’on décide de mettre en place une in-frastructure de développement et test à l’échelled’une entreprise, il est nécessaire de définir lespérimètres de responsabilité et l’organisationdes environnements projet par souscriptionAzure. Il est donc préférable :• De disposer de multiples souscriptions ;• De définir leur niveau de délégation et de l’au-

tomatiser ;• De leur appliquer des règles de nommages

précises et systématiques ; • Lorsque cela est possible, d’utiliser des

comptes dédiés pour y accéder et d’établir desrègles de création pour ces Microsoft Accounts(précédemment appelés Live IDs) ;

• De définir des groupes d’affinités pour optimi-ser les temps d’accès entre les ressources liéesaux mêmes plateformes ;

• D’administrer les certificats liés au contrôle dela publication et à l’utilisation de nouvelles res-sources.

Définition des unités de facturation(ChargeBack)Avec l’avènement de la virtualisation et de lamutualisation des ressources (machines vir-tuelles, réseau, stockage,…) la Direction des Sys-tèmes d’Information a tout intérêt à mettre enplace les outils lui permettant de savoir qui aconsommé quoi et le cas échéant, de lui refac-turer. C’est également un moyen permettant des’assurer que les ressources ne sont pas gaspil-lées. Il est fréquent de recevoir une demande decréation de machines virtuelles; il l’est beaucoupmoins de recevoir une demande de libérationdes ressources correspondantes. Avec le Cloud,et le portail en mode libre-service, cette bonnepratique devient une absolue nécessité.La plateforme Azure permet de définir des quo-tas de ressources au niveau de la souscription,

et d’obtenir une facturation détaillée à posteriori(certains outils complémentaires – comme Fo-glight - permettent de faire des projections surla consommation à venir). Les données deconsommation peuvent être téléchargées auformat Excel, et manipulées avec des tablespivot Fig.5. Des règles pourront également êtreédictées et automatisées pour limiter laconsommation (arrêt nocturnes des plate-formes,…).

Choix du type d’hébergement des servicesLe choix du type d’hébergement des servicespartagés (infrastructure ALM, annuaire, base dedonnées…) est un pré-requis à la mise en placed’une infrastructure « DevTests ». Différentes options sont à considérer : ServicesSaaS, Services déployés en IaaS ou Services àdemeure ? Les Solutions SaaS offrent souventmoins de possibilités de personnalisation maisproposent un SLA, des plans de support inté-grés, et sont supervisées (la gestion opération-nelle du service est incluse).

Sécurité et gestion d’identitéUne approche IaaS ou OnPremise pour les ser-vices partagés n’est pas neutre d’un point de vuesécurité et gestion d’identité. Les développeursdoivent être identifiés. En fonction du type desolution ALM utilisée (Team Foundation Serverà demeure ou en IaaS, Visual Studio OnLine), ilspeuvent l’être grâce à un compte Active Direc-tory, ou avec un Microsoft Account.Active Directory, ou une autre solution de ges-tion d’identité, peut être déployé en IaaS. S’ils’agit de s’appuyer sur une solution de gestiond’identité à demeure, il sera alors nécessaire demonter un VPN en mode site à site. Si les ser-vices correspondants sont déployés en IaaSdans Windows Azure, il faudra exposer des en-dpoints publics et les sécuriser par ACL.

Configuration des référentiels d’imagesComme nous l’avons déjà vu précédemment,Windows Azure propose une offre IaaS. Elle re-pose sur des machines virtuelles (VM). On dis-pose de trois types de VM : Windows Server,Linux, Workload pré-packagé. Par workload, ilfaut comprendre un environnement complet vir-tualisé avec le système serveur et l’ensemble despiles serveurs et applicatives nécessaires pourdéployer et mettre en production le workload.Pour un développeur attaché à la production,le workload est une notion importante. Il peutainsi rapidement déployer les environnementscibles de l’application pour tester et débugger.Il peut aussi juger de la pertinence du systèmecible. C’est un élément clé pour la mise enœuvre de prototype comme pour la mise enplace de l’application proprement dite.La configuration du référentiel d’images sup-pose la mise en place d’un processus de versio-ning des images, de définition de la stratégie de

5DevTests/DevOps


12

diffusion des images, et de déploiement desVM, de gestion du licensing des produits, de va-lidation des environnements (manuelle ou au-tomatisée), de choix des technologies et outilsd’automatisation (PowerShell, System Center,Puppet, Chef) Fig.6.

La démarche DevOps« DevOps » est un terme inventé par PatrickDesbois en 2009. John Allspaw et Jesse Robbinssont également à l’origine de ce mouvement quiest né d’un constat : la faible synergie deséquipes de développement d’application etd’administration des systèmes. Dans une récenteanalyse du mouvement « Devops » Andrew ClayShafer va même jusqu’à parler de sources detension qu’il associe à un « Wall of Confusion ».

Le « Wall of Confusion »Ce « mur » résulte des divergences d’objectifsentres développeurs et responsables opération-nels au sein d’une organisation. Souvent, les dé-veloppeurs se concentrent sur la réponse auxexigences fonctionnelles par la production d’unlivrable, mais pas du tout sur la maintenance dela solution en fonctionnement opérationnel. Deleur côté, pour limiter les risques de problèmesinattendus, les administrateurs système tententd’édicter des règles pour les déploiements quis’avèrent être des contraintes architecturalespour le développement d’applications. Chaquegroupe optimise ce qu’il considère être son pé-rimètre, ce qui crée des conflits. Le développeurest à l’origine de changements, que le respon-sable des opérations souhaite minimiser pourréduire le risque de dysfonctionnement Fig.7.

DevOps : Une philosophieDevOps est une philosophie. C’est une façon depenser. Dans ce modèle, développeurs et opé-rateurs doivent travailler ensemble pour s’assu-rer que tout nouveau déploiement d’applicationrespecte les besoins opérationnels. Selon GeneKim, CTO cofondateur de Tripwire, et auteur del’ouvrage « The Phoenix Project: A Novel AboutIT, DevOps, and Helping Your Business Win », ladémarche « DevOps » repose sur trois principesfondamentaux :• Acquérir une compréhension globale du sys-

tème afin d’optimiser les performances de l’en-semble de ses processus, en se focalisant surtoutes les chaînes de valeur métier reposantsur des services IT ;

• Mettre en place des systèmes de mesure etdes processus de remontée d’information sys-tématique ;

• Favoriser le développement d’une culture fon-dée sur l’expérimentation et l’apprentissage encontinu Fig.8.

Acquérir une compréhensionglobale du systèmeL’objectif est de parvenir à optimiser l’intégralitédes chaînes de valeur métier dépendant de ser-

vices IT, en résolvant les problématiques au plustôt afin de limiter leur impact sur le reste du sys-tème. Pour ce faire, chaque acteur du systèmese doit de penser globalement, au-delà de latâche qui lui est assignée ou du départementauquel il appartient, en vue de parvenir à unecompréhension profonde du système dans sonensemble. Concrètement cette démarche va se traduire parune évolution de l’organisation, de ses proces-sus, du rôle et des périmètres de responsabilitéde chacun, mais aussi en termes d’outillage etde technologie. Etablir une collaboration plus étroite et plus ef-ficace entre les équipes de développement et

d’administration système requiert la mise enplace de processus communs de déploiement(installation automatisée, configuration automa-tisée, vérification en mode « smoke-test » descomposants ou services déployés sur l’ensembledes plateformes cibles), de supervision (détec-tion et prévention d’incidents de performance,de sécurité, de disponibilité), de support et de

6

7

8

9


13

• Métriques de processus : nombre de nouvellesfonctions, délai de livraison d’une nouvelle ver-sion ;

• Métriques de disponibilité ;• Métrique d’usage : loyauté des utilisateurs,

pages les plus vues, types de devices utilisés.Par exemple, comme nous l’avons vu précédem-ment, Visual Studio Online offre au développeurla possibilité de lancer un test de charge en s’ap-puyant sur des injecteurs directement montésdans Azure. L’application déployée aura doncfait l’objet de mesures permettant de garantirson bon comportement en charge avant mêmed’être supervisée par les équipes système et ré-seaux. Autre exemple, avec Visual Studio OnlineApplication Insights, le développeur et le res-ponsable système vont pouvoir observer lecomportement des applications Azure dé-ployées en test, mais aussi en production, ce quipermet de constater le dysfonctionnement ou laperte de disponibilité, et de faire le lien avec laversion du Build correspondantFig.10.En cas de dysfonctionnement, Visual Studio On-line permet grâce à Intellitrace d’identifier trèsprécisément la ou les lignes à l’origine de l’erreurFig.11.Enfin il est possible d’accéder directement à laversion du code utilisée pour déployer cette ap-plication.Visual Studio Online Application Insights permetégalement d’obtenir des informations sur l’utili-sation d’une application ou d’un Cloud Service.Par exemple, il est possible d’avoir une vue trèsfine sur les pages les plus vues (et éventuelle-ment sur celles qui ne le sont jamais, ce quipourrait amener à reconsidérer certains choixfonctionnels…) Fig.12. Ce portail permet aussid’avoir des statistiques sur le nombre d’utilisa-teurs connectés Fig.13.Tout un ensemble d’informations concernant ledevice, le système d’exploitation, la résolutiond’écran,… sont également consolidées.

Culture « DevOps » :expérimentation et apprentissageen continuLa culture « DevOps » est un élément clé de ladémarche. Dotée de valeurs fondamentalescomme le respect mutuel, la confiance réci-proque, ou la systématisation du partage de l’in-formation et des outils, elle propose une visionpositive de l’échec. En effet, les organisationsdoivent apprendre de leurs succès, mais égale-ment de leurs échecs. Elles doivent donc accep-ter de prendre des risques. L’adoption de ce typede démarche offre la possibilité d’anticiper et dedéfinir de nouveaux besoins opérationnels ré-sultant de cette prise de risque. En outre, elle favorise le développement descompétences de l’ensemble des acteurs du sys-tème dans une recherche perpétuelle d’amélio-ration (« Kaizen »). La pratique systématique decette approche est la condition sine qua non decette progression. L’organisation devient ainsi

12

11

Mesures et processus de remontée d’informationLa mise en place de ces mesures et processus defeedback cible deux objectifs :• Il faut pouvoir corriger les dysfonctionnements

au plus tôt, identifier les limites en termes deperformance et de disponibilité ;

• En s’inspirant des principes d’une démarcheAgile, elle vise à obtenir les informations per-mettant au métier de comprendre et répondreaux besoins fluctuants des clients (« Data-dri-ven decision »).

Cela suppose la collaboration effective deséquipes de développement et de gestion opé-rationnelle afin de déployer ces systèmes demesure et de se les approprier :• Métriques de performance : succès de déploie-

ment, disponibilité du service, temps de réponse.

remédiation. Le « Continuous Delivery » pré-senté précédemment est un parfait exemple dece type de processus. • En effet, l’intégration continue, fondée sur une

configuration centralisée du code source, s’ins-crit dans une vision globale du système : l’in-tégrité de la totalité de la solution devientprioritaire vis-à-vis de ses composants ;

• Le déploiement continu, qui suppose la miseen place de modèles et de procédures auto-matisées, répétables et maîtrisées ;

• La nécessité de construire des tests de valida-tion permet de prévenir les défaillances dansla production, ou à minima, de les détecter etde les corriger rapidement ;

• L’automatisation de la totalité de la chaîne deproduction logicielle offre une vue de bout enbout sur le cycle de vie de l’application Fig.9.

DevTests/DevOps


14

plus prompte à s’adapter, et recherche le chan-gement plutôt que de le fuir. Un des exemplesde mise en place de ce type d’évolution organi-sationnelle est la démarche d’introduction vo-lontaire de défauts dans le système afin deconstater au plus tôt la capacité du système à seremettre en service après un dysfonctionne-ment. Cela permet également de définir et par-tager les plans d’escalade et processus internesassociés.

Automatisation de l’infrastructureLa démarche « DevOps » contribue à l’accéléra-tion des déploiements grâce à une automatisa-tion de l’infrastructure. De multiples exemplesillustrent l’intérêt de cette approche : • Gestion de multiples environnements de dé-

ploiement comme dans le scénario DevTestprécédemment présenté ;

• Contrôle du scale-out. Précisons que sur la pla-teforme Azure, cette gestion est maintenantnativement totalement automatisée (« autos-caling »)Fig.14.

Dans le monde Microsoft, les objets permettantde faciliter l’automatisation d’une infrastructuresont les suivants :• Orchestration: Runbooks, PowerShell ;• Format de déploiement de binaire : WebDe-

ploy, DACPAC… ;• Tests de vérification de déploiement: VS Web

Test ;• Modèles de configuration d’environnement:

Service Template ;• Agent de supervision : Management Pack ;• Descriptifs d’incident : logs Intellitrace.Windows PowerShell est un langage de scriptdéveloppé par Microsoft. Il est inclus dans Win-dows depuis la version 7.0 et propose un mo-dèle de programmation orientée objetextensible par de nouvelles fonctions baptiséesCmdLets. Dans le cas d'Azure, PowerShell peutêtre configuré pour importer ces CmdLets spé-cifiques avec la commande : « Import-Module C:\Program Files (x86)\Mi-crosoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1 ». Il est nécessaire d'obtenir les in-formations permettant d’authentifier les accèssur la souscription Azure (notamment la réfé-rence au certificat présent sur la machine clienteet déclaré dans le portail Azure) avec la com-mande « Import-AzurePublishSettingsFile "X:\[NomduRepertoire]\azure.publishsettings" ». Lefichier "X:\[NomduRepertoire]\azure.publishset-tings" quant à lui, est obtenu directement par unappel REST sur l’URL « https://manage.windowsazure.com/publishsettings/index?client=vs&schemaversion=2.0 » PowerShell est aujourd'huifourni avec un éditeur incluant des fonctions decoloration syntaxique et d'intellisense, WindowsPowerShell ISE Fig.15.De nombreux scripts Powershell sont disponi-bles pour automatiser le déploiement sur Azured’infrastructures cibles fondées sur des modèles(notamment

13

14

15


15

16

ture fondé sur un modèle » s’inscrit dans unedémarche que l’on pourrait comparer à celle quepropose le PaaS Azure avec les fichiers « AzureService Definition Schema (.csdef) » et « AzureService Configuration Schema (.cscfg) » ou les « Service templates » de System Center 2012.Afin d’éviter que le code d’une application soitétroitement couplé à un profil d’infrastructurespécifique, des «blueprints» sont associés auxapplications précisant les « règles », descriptivesou prescriptives, ainsi que les paramètres d’en-trée qui permettent aux services Cloud deconnaître les actions à effectuer au nom de l’ap-plication. Ces stratégies sont délivrées aux ser-vices Cloud via des API bien définies etdirectement corrélées aux profils de servicesd’infrastructure que propose Azure afin deconfigurer un ensemble d’instances et les diffé-rentes ressources connexes. Enfin, les DSC(« Desired State Configuration ») de PowerShell4.0 proposent un modèle de développementadapté au déploiement « continu » d’une appli-cation et de son infrastructure sous-jacente (àdemeure ou dans le Cloud), car il empêche tout« écart » par rapport à la configuration cible. Cemodèle de « provisioning » utilise les extensionsde langage PowerShell pour permettre des dé-ploiements de services déclaratifs, autonomeset reproductibles.

Visual Studio Online : la révolution est déjà làComme nous l’avons vu précédemment, VisualStudio Online est un complément indispensablepour le développement et la supervision d’uneapplication pour le Cloud, en cumulant de mul-tiples fonctions ALM, des fonctions de gestionopérationnelles (performances, disponibilité,diagnostic) et de télémétrie (grâce à ApplicationInsights).Cette solution d’APM (Application PerformanceManagement) va donc bien au-delà de ce quiétait proposé jusqu’à présent, en donnant réel-lement une vue de bout en bout sur le cycle devie d’une application (et pas uniquement surson cycle de développement). Elle offre doncune vraie passerelle entre le monde des déve-loppeurs et celui des responsables opération-nels. Cet outil s’intègre donc parfaitement dansune démarche DevOps appliquée à un proces-sus de « Continuous Delivery ».Visual Studio Online est disponible en trois édi-tions : basic, avancée et professionnelle, avecdes tarifs spécifiques. Il inclut Monaco. Il s’agitd’un environnement de développement dotéd’un éditeur de code (pour JavaScript, HTML,CSS) accessible dans son navigateur web etdédié au développement de sites Web. Il peut être utilisé pour éditer, coder, modifier un site web déployé sur Windows Azure WebSite, et permet d’établir des connexions avec les gestionnaires de source (Visual Studio Onlineou Git).

http://gallery.technet.microsoft.com/scriptcenter ethttps://github.com/windowsazure/azure-sdk-tools-samples)Ces scripts utilisent Windows Remote Manage-ment (WinRM) : implémentation Microsoft deWS-Management, protocole fondé sur SOAP etpassant les firewalls http://msdn.microsoft.com/en-us/library/aa384470(v=vs.85).aspxLa délégation des accès depuis la machinecliente pour permettre l’automatisation de laconfiguration des serveurs distants (« multi-hopWinRM ») requiert l’activation de l’optionCredSSP : « enable-wsmancredssp -role client -delegatecomputer "*.cloudapp.net" » ainsi quel’activation de la délégation d’identité dans l’édi-teur de stratégie de sécurité du PC, dans lemenu « Computer Configuration -> Administra-tive Templates -> System -> Credentials Dele-gation ». Enfin, il est nécessaire de sélectionnerl’option « Allow Delegating Fresh Credentialswith NTLM-only server authentication » etd’ajouter « AWSMAN/*.cloudapp.net » dans lasection « Add Servers ».L’automatisation du déploiement de l’applicationpeut être assurée par un outil comme « MicrosoftRelease Management ». Ce logiciel facilite la définition et la maintenancedes processus de gestion des versions d’appli-cation dans le Cloud ou à demeure :• Création des chemins d’accès de configuration ;• Définition des orchestrations de déploiement

(copie des fichiers, création de sites IIS, instal-lation des fichiers msi…) ;

• Réutilisation sur les différents environnementsde déploiement ;

• Planification de « builds » et déclenchementde la production d’une nouvelle version depuisVisual Studio ;

• Visualisation du pipeline des releases ;• Modélisation du processus de gestion des ver-

sions d’application, Fig.16.Autres exemples d’outils, les logiciels Chef ouPuppet, utilisés pour automatiser le déploie-ment d’une infrastructure sur la plateformeAzure en appliquant des « recettes » (recipes)qui se rapportent à des événements spécifiquesde la gestion du cycle de vie de l’application(http://forge.puppe tlabs.com/msopentech/window-sazure).Cette automatisation peut également être assu-rée par un développement spécifique visant às’assurer que les composants du Cloud Servicesont déployés avec une configuration appro-priée. En effet, les infrastructures commencentà dépendre du code, au même titre que les ap-plications qu’elles hébergent. Le Cloud ne faitqu’amplifier cette tendance.Le principe est d’intégrer les spécifications d’ex-ploitation dans celles de l’application, de sorteque l’automatisation du déploiement de l’appli-cation et de sa supervision puissent faire partiedes livrables. Puisque ces spécifications sont gé-néralement déclarées pour chaque applicationdéployée, leur définition fait partie de la concep-tion de l’application elle-même.Cette approche de « provisioning d’infrastruc-

DevTests/DevOps



Documents

Windows Azure3 LB 31/01/14 17:56 Page1download.microsoft.com/.../2014/Livre-blanc-Cloud-developpeur.pdf · Notre propos dans ce livre blanc est dillustrer comment le Cloud modifie