Developpez.com

Télécharger gratuitement le magazine des développeurs, le bimestriel des développeurs avec une sélection des meilleurs tutoriels

Le déploiement d'applications pour les Nuls

Dans ce cours de Erick Minick, Jeffrey Rezabek, et Claudia Ring, vous aurez l'occasion d'apprendre à :

  • évaluer et améliorer vos méthodes actuelles de livraison des logiciels ;
  • adopter des normes de déploiement pour une livraison rapide d'applications de qualité ;
  • réussir la mise en œuvre de solutions de déploiements d'applications.

Vous pouvez tester le déploiement de vos applications web, mobile, big data sur IBM Bluemix.

N'hésitez pas à commenter cet cours sur le forum : Commentez Donner une note à l'article (5)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

1. Introduction

Image non disponible

Vous apprendrez à :

  • évaluer et améliorer vos méthodes actuelles de livraison des logiciels ;
  • adopter des normes de déploiement pour une livraison rapide d'applications de qualité ;
  • réussir la mise en œuvre de solutions de déploiements d'applications.

Les applications logicielles génèrent d'importants revenus pour les entreprises, et le déploiement rapide de ces applications est devenu un élément essentiel du cycle de vie d'une entreprise. En effet, quel intérêt y a-t-il à créer une application innovante si vous ne pouvez pas la déployer rapidement dans des environnements de test, ou la proposer aux utilisateurs dans les délais prévus ?

Généralement, le déploiement se définit comme la promotion de composants d'un environnement vers le suivant. La gestion du déploiement englobe le déploiement de toute une application ou de plusieurs applications intégrées dans l'environnement de production.

La coordination des déploiements et les déploiements proprement dits ont des objectifs similaires. Les termes sont souvent utilisés indifféremment. Nous vous indiquons comment tirer profit des solutions de déploiement pour aider votre entreprise à accélérer la mise sur le marché, abaisser les coûts et réduire le risque.

À propos de cet ouvrage

Nous avons rédigé cet ouvrage pour fournir une introduction relativement simple à ce qui peut constituer un sujet très complexe. Utilisez-le comme une référence, et non comme un manuel. Si certains sujets vous intéressent plus que d'autres, n'hésitez pas à lire seulement certains chapitres. N'hésitez pas également à feuilleter l'ouvrage. Vous n'avez pas besoin de lire les chapitres dans l'ordre.

Au-delà de l'ouvrage

Tout au long de cet ouvrage, nous évoquons les avantages des solutions de déploiement, automatisation et coordination du déploiement des applications. Nous incluons quelques témoignages de clients du secteur ainsi que des bonnes pratiques.

Vous trouverez également plus d'informations sur le lancement et le déploiement d'applications en visitant les pages Web sui­vantes :

Enfin, vous pouvez lire les autres ouvrages pour les Nuls en édition limitée IBM :

2. Quels éléments permettent un déploiement et une livraison efficace ?

Dans ce chapitre

  • Suivre le cycle de vie du développement logiciel
  • Comprendre les bénéfices métier d'une livraison efficace des logiciels
  • Présentation des pratiques techniques qui pilotent le développement d'applications

Une application suit une longue série d'étapes avant d'être pro­posée aux utilisateurs en production. Ce processus est connu sous le nom de cycle de vie du développement logiciel (Software Development Life Cycle). Dans ce chapitre, nous passons en revue les étapes de ce cycle. Puis nous examinons les enjeux métier et techniques du déploiement et de la livraison de logiciels.

2-1. Suivre le cycle de vie du développement logiciel

Le SDLC peut intégrer tous les aspects du cycle de vie d'une applica­tion, de la planification initiale jusqu'à son retrait de la production. Dans cette section, nous examinons une partie importante du SDLC que nous appelons le pipeline de livraison, qui est généralement composé de plusieurs environnements, c'est-à-dire des cibles de déploiement pour un ensemble d'éléments, qui travaillent ensemble à la réalisation d'un objectif commun. L'enchaînement des environne­ments permet d'améliorer et de vérifier la qualité d'une application avant qu'elle ne devienne accessible par les utilisateurs. Il n'y a pas un nombre idéal d'environnements, mais nous avons identifié quatre grands types d'environnements.

  • Développement (DEV) : dans l'environnement de Développement, les développeurs créent et déploient du code dans un laboratoire où l'application est testée au niveau le plus élémentaire. Lorsque l'application satisfait certains critères de qualité, elle passe à l'environnement suivant.
  • Test d'intégration système (SIT) : dans l'environnement Test d'intégration système, l'application est testée pour garantir qu'elle fonctionne avec les applications et systèmes existants. Lorsque l'application réussit les tests d'intégration, elle est déployée dans l'environnement suivant.
  • Test d'acceptation des utilisateurs (UAT) : dans l'environne­ment test d'acceptation des utilisateurs, l'application est testée pour s'assurer qu'elle fournit les fonctionnalités requises pour les utilisateurs finals. Cet environnement est généralement proche de celui de la production (voir Chapitre 4). Lorsque l'application répond à ces exigences, elle est promue vers l'envi­ronnement final.
  • Production (PROD) : dans l'environnement Production, l'appli­cation est mise à la disposition des utilisateurs. L'analyse du comportement utilisateur de l'application (voir l'encadré) est obtenue en surveillant la disponibilité et la fonctionnalité de l'application. Tous les mises à jour ou correctifs sont intro­duits dans l'environnement DEV et suivent le même cycle.

La Figure 1-1 montre un simple diagramme de ces quatre environne­ments.

Image non disponible
Figure 1-1 : Les quatre environnements élémentaires du SLDC

Un déploiement se définit comme la promotion de composants d'une application depuis un environnement vers le suivant. Une release comprend le déploiement de toute une application ou de plusieurs applications intégrées dans un environnement de production.

La Figure 1-2 illustre la différence.

Image non disponible
Figure 1-2 : Visualisation de la différence entre une livraison et un déploiement

Exécution d'une boucle de rétroaction

Certaines pratiques de livraison de logiciels impliquent la surveillance de l'ap­plication dans tous les environnements puis le renvoi des analyses à l'équipe de développement. En fonction des nouvelles exigences, l'équipe de déve­loppement déploie l'application modifiée dans l'environnement DEV, et le cycle démarre à nouveau. Après la promotion vers chacun des environnements suc­cessifs, l'application est supervisée, et les réactions des utilisateurs sont ren­voyées à l'équipe de développement. Ce processus est connu sous le nom de boucle de rétroaction (ou feedback loop).

2-2. Tirer profit d'un déploiement efficace

Le besoin de fournir des logiciels qui s'adaptent et répondent aux attentes des entreprises et des clients renforce la nécessité de dis­poser de meilleures méthodes de lancement et de déploiement des applications. L'IBM Institute of Business Value signale que le nombre d'entreprises qui valorisent la livraison efficace des logiciels dépasse largement le nombre d'entreprises qui fournissent réellement une livraison efficace des logiciels. Consultez la Figure 1-3 pour plus d'informations.

Dans les sections suivantes, nous examinons certains des avantages d'une livraison efficace des logiciels.

Image non disponible
Figure 1-3 : La valeur ajoutée d'une livraison efficace des logiciels

2-3. Accélérer la mise sur le marché

Le temps d'attente que les clients sont prêts à accepter pour obtenir un nouveau service ne cesse de diminuer. Les clients s'attendent à une disponibilité instantanée. Songez à la fréquence à laquelle vos applications mobiles nécessitent des mises à jour demandées par les clients. Si un service n'est pas disponible au moment exact où le souhaite un client, ce client peut passer en un clic sur la page Web d'un concurrent.

Avec les méthodes adaptées de lancement et de déploiement des applications, aussi bien les entreprises qui démarrent que celles qui sont déjà établies peuvent fournir rapidement les services qu'attendent les clients. La livraison efficace des logiciels constitue un élément essentiel du succès de l'entreprise. Fournir à vos équipes de gestion du déploiement des processus et outils adéquats peut faire la différence entre une réussite sur du long terme et un échec.

2-4. Réduire les pannes coûteuses

Le coût d'un échec du déploiement dépend de l'environnement dans lequel l'échec a eu lieu. Dans l'ensemble, les échecs dans les environnements tels que DEV et SIT (voir la Figure 1-1 plus haut dans ce chapitre) sont beaucoup moins coûteux que les échecs en production. Déceler une erreur d'application dans ces environnements vous permet d'effectuer une correction qui peut empêcher une interruption critique en production ou pire, une panne pour les utilisateurs. Forbes.com a remarqué qu'au cours de l'été 2013, Amazon a connu une panne de 30 minutes qui a entraîné une perte estimée à 66 240 $ par minute, soit près de 2 millions de $ de perte de chiffre d'affaires totale.

2-5. Estimation du coût d'une panne

Une panne peut non seulement provoquer une perte de chiffre d'af­faires, mais peut également engen­drer des coûts supplémentaires pour corriger le problème. Vous pouvez commencer l'estimation en calcu­lant le salaire horaire d'un ingénieur chargé de corriger le problème. Les coûts supplémentaires représentent de 20 % à 40 % environ du salaire. Voici la formule :

Salaire annuel estimé / 52 semaines par an / 40 heures par semaine * 1,3

Si vous avez un ingénieur qui touche 80 000 $ par exemple, une estimation raisonnable du coût total horaire est :

80 000 / 52 / 40 * 1,3 = 50 $

Utilisez maintenant cette formule pour toutes les personnes de l'équipe qui tentent de régler le problème, et multipliez le résultat par le nombre d'heures moyen passées à entre­prendre les actions correctives. Si une équipe de six personnes passe dix heures à régler le problème lié au déploiement d'une version, le coût est de 3 000 $ pour cette seule version. Toutefois, ce coût est sim­plement un coût de productivité ; il ne tient pas compte du coût d'oppor­tunité : la perte de chiffres d'affaires ou la perte potentielle intangible de crédibilité due à la panne.

Le coût de la panne renforce la nécessité de meilleures pratiques de déploiement des applications. Dans les derniers chapitres, nous étu­dions les moyens de prévenir la venue de ces pannes.

2-6. Effectuer des déploiements complexes

Les entreprises ont désormais de plus en plus de cibles de déploie­ment sur de nombreux serveurs : en local, sur le cloud, ou sur des machines physiques et virtuelles. Il est difficile de faire évoluer un processus principalement manuel en un système efficace de gestion de mises en production d'applications interdépendantes à l'échelle de l'entreprise, tout en maintenant la sécurité, la visibilité et la traçabilité.

Le nombre d'étapes manuelles contenues dans le déploiement d'une seule application peut constituer un processus laborieux, mais l'application finit toujours par se retrouver en production.

Avec des déploiements plus importants et complexes, le risque augmente avec le nombre d'applications interdépendantes en cours de déploiement. Les processus manuels associés aux solutions de suivi des versions, telles que les feuilles de calcul, favorisent l'erreur humaine et inévitablement, les échecs de déploiements coûteux.

À mesure que les applications évoluent pour s'adapter à la com­plexité de l'entreprise, les équipes de déploiement s'agrandissent pour comporter des dizaines ou des centaines de personnes, ajou­tant alors une couche de complexité supplémentaire. Lorsque les équipes informatiques évoluent pour gérer la complexité des appli­cations, les responsabilités et spécialités de chaque intervenant deviennent plus divisées, et la communication devient moins fré­quente lorsque les équipes réalisent leurs processus respectifs. Les divisions en silos se produisent en raison de la spécialisation des postes, ainsi que des différents fuseaux horaires et emplacements géographiques. Des équipes dispersées qui utilisent des solutions et processus différents, découvrent souvent que ces différences doublent ou triplent leurs efforts et les empêchent de livrer à temps.

La coordination de chaque déploiement, chaque processus et chaque ensemble d'étapes manuelles est presque impossible à exécuter sans l'utilisation d'un outil spécialisé. Ce dernier peut vous aider à coordonner chaque déploiement, chaque processus et chaque ensemble d'étapes du déploiement, et les rend visibles à chaque personne impliquée.

Si vous avez dix étapes pour déployer un composant sur un serveur, et que vous passez d'un à dix serveurs, vous passez de dix étapes manuelles à 100. Puis, si vous passez d'un composant de déploie­ment à dix composants, vous avez un autre facteur multiplicateur de dix, produisant ainsi 1000 étapes manuelles. Les processus manuels ne pourront pas évoluer à mesure que ces trois niveaux de complexité (nombre d'éléments déployés, nombre de serveurs, et nombre d'étapes par déploiement) s'associent pour provoquer une croissance exponentielle.

Les entreprises capables de mettre en place un processus efficace de déploiement peuvent suivre le rythme des équipes de dévelop­pement tout en lançant de petites mises à jour d'applications, voire de nouvelles versions. Définir un processus efficace réduit le risque d'erreur et permet à l'entreprise de se concentrer sur la satisfaction rapide des besoins métier.

2-7. Identifier les pratiques de livraison de logiciels

De nombreuses pratiques et méthodologies de livraison de logi­ciels permettent aux entreprises d'accélérer la mise sur le marché, de réduire les erreurs, et de changer d'échelle efficacement. De nombreuses entreprises utilisent une combinaison de plusieurs approches. Parmi les pratiques les plus populaires se trouvent Agile, l'intégration continue, la Livraison continue et ITIL, autant d'approches que nous examinerons dans les sections suivantes. Les pratiques Agile, Intégration continue et Livraison continue reposent les unes sur les autres pour aider à pousser les applications vers la production.

2-7-1. Agile

À mesure que la technologie fait de grandes avancées, les clients deviennent moins patients et plus exigeants. Le rythme de change­ment nécessaire pour rester compétitif a motivé l'adoption des pra­tiques Agiles.

La méthode Agile met l'accent sur les besoins du client, les petits déploiements fréquents, l'intégration du changement, et la collabo­ration entre les membres de l'équipe de développement. Contrai­rement à la méthode de développement logiciel traditionnelle en cascade, Agile met moins l'accent sur la planification précise, afin que les développeurs ne restent pas enfermés dans des plans impossibles à modifier. Agile se concentre sur des livraisons plus petites qui per­mettent aux développeurs d'apporter des modifications au besoin.

Pour plus d'informations, voir Agile For Dummies (Agile pour les Nuls), une édition limitée IBM, sur ibm.co/agilefordummies.

2-7-2. Intégration continue

L'Intégration continue (Continuous Integration) est dérivée du prin­cipe Agile consistant à intégrer le code et tester les développements régulièrement pour valider ces modifications intégrées. À l'aide de la CI, les développeurs s'engagent en faveur d'une ligne de développement commune et intègrent leurs modifications à celles des autres membres d'équipe et au code existant. En partageant le code rapidement, ils évitent les difficultés de la phase d'intégration tardive de la méthodologie en cascade, et détectent les problèmes plus tôt. Les développeurs doivent s'engager à chaque fois qu'un petit bloc de code est terminé, et généralement, au moins une fois par jour.

La CI est facilitée par l'utilisation d'une solution qui intègre automa­tiquement les nouvelles modifications lorsqu'elles sont enregistrées. Le test de vérification automatique accompagne souvent le dévelop­pement automatique afin que les défauts puissent être détectés et corrigés plus rapidement. Cette fonctionnalité est particulièrement puissante lorsqu'elle est associée à la « Livraison continue », examinée dans la section suivante.

Combinée aux pratiques de développement Agiles, la CI constitue une autre étape vers des déploiements à grande fréquence et de meilleure qualité. Elle permet aux équipes de développement de produire des développements (builds) testables à un rythme très élevé. Elle fait également peser une plus grande pression sur les équipes des opérations pour déployer plus fréquemment vers des environnements de production.

2-7-3. Livraison continue

La livraison continue (Continuous Delivery) est la dernière amé­lioration de CI et permet de déployer automatiquement des builds successifs qui ont été qualifiés pour des environnements de tests, déclenchant ainsi des tests automatisés. Les tests qui mettent en œuvre la CD visent à toujours faire tester les builds, afin de per­mettre à l'entreprise de choisir de déployer des fonctionnalités à tout moment, en toute confiance.

La livraison continue tient son nom du Manifeste Agile et a été créée en réponse aux goulots d'étranglement que les pratiques Agile et CI exposaient aux équipes des opérations. À mesure que les équipes de développement ont commencé à évoluer rapidement et à produire un grand volume de builds, les équipes des opérations ont été sou­mises à des pressions d'accélération des déploiements qu'il fallait promouvoir vers la production. Des différences en termes de lan­gage, plateforme , environnement et test ont accentué la pression sur les équipes des opérations, qui recherchaient des moyens de garantir les déploiements des applications.

Le simple fait qu'un professionnel de l'informatique affirme prati­quer la Livraison continue (CD) ne signifie pas qu'il effectue tout le déploiement jusqu'à la production. Il peut avoir mis en œuvre des pratiques de CD, mais peut se heurter à des blocages ailleurs dans le SDLC. Ces blocages contribuent à une augmentation expo­nentielle du risque, car des modifications plus nombreuses s'accu­mulent dans des lots toujours plus volumineux qui attendent d'être déployés en une seule fois. La pratique idéale de la CD utilise l'au­tomatisation pour transférer une application jusqu'à la production, mais il y a beaucoup d'obstacles à surmonter avant d'en tirer des bénéfices pour toute l'entreprise. Nous traitons ces obstacles dans le Chapitre 3.

2-7-4. ITIL

L'ITIL (Information Technology Infrastructure Library) est un ensemble de bonnes pratiques et processus qui aident à la gestion des services informatiques. L'ITIL est composée de cinq principaux cycles de vie qui conseillent les professionnels sur les bonnes pra­tiques pour fournir des services spécifiques aux utilisateurs.

Les concepts de l'ITIL fournissent des pratiques non prescriptives et non propriétaires pouvant être utilisées dans n'importe quel secteur. La plupart des entreprises qui utilisent l'ITIL le font, car elles ont besoin de gouvernance, de gestion du risque et de contrôle de leurs lancements et déploiements.

Certains fournisseurs ITIL sont réticents à automatiser, car ils pensent qu'aller plus vite les expose à un risque accru de commettre des erreurs. En fait, l'automatisation peut réduire les risques et amé­liorer le contrôle, la visibilité et l'auditabilité.

2-8. Adopter une approche DevOps pour la livraison de logiciels

DevOps est une approche visant à délivrer les logiciels en continu. Elle permet aux clients de saisir plus rapidement les opportunités du marché et d'accélérer la prise en compte des retours clients. DevOps applique les principes Agile et lean tout au long de la chaîne de fabrication des logiciels pour supprimer les pertes de temps et les goulots d'étranglement. DevOps est composée de quatre fonc­tionnalités majeures dans tout le SDLC :

  • la fonction Planifier et mesurer se concentre sur les divi­sions commerciales et leurs processus de planification. Cela implique la compréhension et l'augmentation des mesures d'efficacité de ces processus et du portefeuille d'applications qu'ils couvrent ;
  • la fonction Développer et tester se concentre sur le développe­ment collaboratif, la CI et le test continu. Elle se concentre sur la rationalisation des fonctionnalités des équipes de dévelop­pement et de test ;
  • la fonction Déployer permet la création du Pipeline de déploie­ment dans le cadre du déploiement continu ;
  • la fonction Surveiller et optimiser inclut les pratiques de surveillance continue, retours clients et optimisation pour surveil­ler les performances des applications après leur déploiement en production, permettant ainsi aux entreprises de faire évoluer leurs exigences si nécessaire.
    Pour plus d'informations sur Dev Ops, voir DevOps For Dummies (DevOps pour les Nuls) sur ibm.co/devopsfordummies.

La mise en œuvre de solutions de coordination des versions et d'automatisation du déploiement sont des éléments clés pour résoudre un problème DevOps dans votre entreprise, comme nous l'évoquons dans les Chapitres 4 et 5.

3. Normaliser le processus de déploiement

Dans ce chapitre

  • Présentation des trois piliers du processus de déploiement
  • Observation des impacts d'un processus de déploiement

Dans ce chapitre, nous mettons l'accent sur les enjeux des métiers et technologiques (voir Chapitre 2) en appliquant un processus de déploiement normalisé. À la fin du chapitre, nous indiquons comment l'application d'un processus de déploiement peut affecter de façon positive une mise en production.

3-1. Les trois piliers du déploiement

Pour garantir un lancement d'application réussi, commencez par mettre en œuvre les trois piliers du processus de déploiement :

  • utiliser le même processus ;
  • automatiser ;
  • effectuer des modifications incrémentielles.

Nous examinons ces piliers en détail dans les sections suivantes.

3-1-1. Utiliser le même processus

L'un des principaux problèmes concernant l'évolution de déploie­ments d'application vers des volumes plus importants et plus com­plexes, réside dans le fait que les équipes divisées en silos créent des processus personnalisés pour s'adapter à leurs propres besoins. Le déploiement doit varier en fonction des équipes.

  • Les développeurs veulent effectuer le déploiement et les tests rapidement pour proposer davantage de modifications d'application. Ils créent souvent des raccourcis dans le processus de déploiement en rédigeant des scripts ou en éludant certaines étapes fastidieuses qui peuvent être néces­saires aux performances de l'application en production.
  • Les équipes de test luttent pour suivre le rythme des équipes de développement, mais elles sont également conscientes de la nécessité de prendre leur temps pour tester à la fois le processus de développement et les applica­tions. Ces équipes créent souvent leurs propres processus de déploiement pour parvenir au test plus rapidement et éviter les retards.
  • Les équipes des opérations peuvent accepter un rythme plus lent. Étant chargées de garantir que les systèmes stratégiques restent en bon état de fonctionnement, elles ne peuvent assumer les risques associés à des déploiements rapides. Leur processus de déploiement est conçu pour garantir le bon fonctionnement de l'environnement de production.

Lorsque les processus de déploiement diffèrent entre les équipes et environnements cibles, le risque d'erreurs augmente. Les étapes non documentées, les différences environnementales et le manque de contribution de toutes les équipes augmentent le risque d'échec du déploiement.

Pour réduire le risque provenant de l'utilisation de processus de déploiement différents, utilisez le même processus de déploiement lors de la promotion d'un environnement à l'autre tout au long du cycle de développement de logiciels (SDLC) et dans l'ensemble du pipeline de livraison continue jusqu'à la production.

Lorsque vous utilisez le même processus de déploiement dans tout le SDLC, vous pouvez tester à la fois l'application et le processus de déploiement.

La méthode préférée de standardisation du processus de déploiement consiste à commencer votre conception dans la production, puis à travailler à reculons. Bien que cette pratique exige plus de réflexion, de temps et d'effort en amont, si vous concevez d'abord le processus pour le transfert en production, vous pouvez supprimer toutes les étapes inutiles à mesure que vous reculez vers les environnements précédents. Nous examinons ce sujet plus en détail au Chapitre 5.

3-1-2. Automatiser

Les étapes manuelles ou semi-programmées d'un processus de déploiement augmentent le risque d'échec du déploiement. Même les opérateurs qualifiés commettent des erreurs, et l'erreur est plus probable lorsque les humains doivent exécuter une longue série d'étapes manuelles. Un processus de déploiement (automatisé ou manuel) doit inclure des passerelles ou approbations prédéfinies qu'une équipe doit passer ou obtenir pour que le déploiement entre dans la phase suivante. Toutefois, l'automatisation du processus de déploiement vous aide à évoluer, accélérer la mise sur le marché, et réduire le risque.

En automatisant ce que vous pouvez du processus de déploiement, vous gagnez en conformité et en auditabilité grâce à une meilleure visibilité des éléments suivants :

  • quels composants sont inclus dans le déploiement ;
  • qui a déployé quelle application ;
  • où l'application a été déployée ;
  • quelle version de l'application a été déployée ;
  • quand l'application a été déployée.

La traçabilité et la visibilité sont deux éléments clés d'un processus de lancement et de déploiement rationalisé, et vous pouvez les obtenir grâce à une automatisation adaptée, comme nous l'exami­nons dans le Chapitre 5.

Il existe une différence entre l'automatisation et la rédaction de quelques scripts qu'un expert doit ensuite lancer. La véritable automatisation supprime les risques de modification d'éléments, et permet aux intervenants en ayant l'autorisation de lancer un déploiement d'un simple clic. En outre, la véritable automatisation offre des fonctionnalités de déploiement en libre-service, de visibilité et de traçabilité.

L'automatisation du déploiement est un facteur d'une telle importance dans le déploiement réussi d'applications, que lorsque nous mentionnons le déploiement d'applications dans cet ouvrage, nous faisons référence au déploiement d'applications via l'automatisation.

3-1-3. Effectuer des modifications incrémentielles

Le pilier final d'un processus de déploiement consiste à effectuer des modifications d'application incrémentielles. Idéalement, votre solution d'automatisation déploie uniquement les composants qui ont besoin d'être modifiés et laisse les autres intacts, car le redéploiement de composants inchangés comporte un risque. Le déploiement de ce qui a été modifié uniquement permet de déployer plus souvent et à la demande. Quand vous connaissez les modifi­cations apportées à l'application, vous avez une véritable gestion des versions : qu'est-ce qui est déployé, quand, où et par qui. Vous pouvez déployer plus souvent et à la demande lorsque des actions très répétitives sont automatisées, et lorsque des barrières de niveau de qualité (critères que doit respecter une application avant d'avancer vers les environnements suivants) sont créées. Si vous utilisez le même processus pour chaque déploiement, il est plus facile et rapide d'effectuer des petits changements d'application. Les petites modifications d'application sont plus faciles à promouvoir vers les environnements de test puis dans les environnements de production.

Lorsque vous effectuez des modifications incrémentielles, vous n'utilisez pas nécessairement le processus de déploiement complet. Pour effectuer des modifications incrémentielles, configurez simple­ment le processus de déploiement et utilisez uniquement la partie du processus qui est nécessaire au déploiement des modifications incrémentielles.

3-2. Les bénéfices de la normalisation du déploiement

L'utilisation des trois piliers d'un processus de déploiement (voir la section précédente) peut vous aider à aligner les besoins métier de votre entreprise avec ses besoins techniques, ce qui peut avoir des effets positifs sur le déploiement des applications. Cette section examine certains de ces effets.

3-2-1. Automatiser et utiliser le même processus de déploiement

Lorsque vous utilisez le même processus de déploiement automatisé sur plusieurs cycles de vie applicatifs, vous affectez considérablement l'ensemble du déploiement. Le déploiement est moins propice aux erreurs et son exécution prend moins de temps.

Éviter l'Effet du lundi matin

L'Effet du lundi matin se produit le lundi suivant un week-end de déploiement majeur, lorsque l'équipe de déploiement fait face à de nombreux problèmes après un déploiement, tels qu'une interruption de la production ou des défauts dans l'application. L'équipe de déploiement doit prendre des mesures correctives immédiates et difficiles. Le redémarrage du déploiement, la correction de l'erreur ou des erreurs, et l'exclusion d'autres possibilités sans entraîner de période d'arrêt importante sont presque impossibles. Si la restauration ne se produit pas immédiatement ou si la solution ne s'avère pas immédiatement évidente, le résultat est l'Effet du lundi matin. Pour éviter l'Effet du lundi matin, les déploiements doivent être automatisés, les équipes doivent utiliser des processus de déploiement similaires, les modifications doivent être introduites de façon incrémentielle, et l'activité de lancement doit être visible de toutes les personnes concernées par le lancement.

3-2-2. Effectuer des changements incrémentiels

L'exécution d'un déploiement majeur est risquée, mais le déploiement d'un lancement majeur de plusieurs applications est encore plus dangereux. Le déploiement de petits lots de modifications est moins risqué et plus facile à gérer.

En outre, la gestion des défauts dans un petit déploiement et leur correction sont beaucoup plus faciles dans des lots réduits (voir la section suivante).

Pour lancer et déployer à la demande, vous devez disposer d'un processus rationalisé. Pour cette raison, l'amélioration continue de votre processus de déploiement standard et l'automatisation des tâches propices aux erreurs sont les clés de déploiements incrémentiels réussis et de lancements rapides.

3-2-3. Gérer les défauts

Les petits déploiements sont moins risqués que les grands, car ils réduisent le nombre d'anomalies potentielles pouvant provoquer une erreur ou une panne. Trois éléments peuvent contribuer à l'apparition d'anomalies : le code, la configuration et la complexité. La complexité fait ici référence au nombre d'interdépendances ou de relations dans le déploiement.

Alors que les défauts du code et de la configuration augmentent les risques linéairement à mesure que la taille des lots augmente, les défauts liés à la complexité augmentent les risques de façon exponentielle. Comme l'indique la Figure 2-1, si vous avez trois composants en cours de déploiement, vous avez trois relations à gérer, mais si vous ajoutez un seul composant supplémentaire lors du déploiement, vous avez six relations à gérer. Vous pouvez observer que l'ajout d'une application supplémentaire double encore les relations et crée davantage de complexité, et par conséquent, de risque.

Image non disponible
Figure 2-1 : Compréhension des relations et de la complexité

Pour les entreprises qui utilisent des processus de déploiement manuel ou des déploiements lents pour obtenir un meilleur contrôle de la qualité, le risque de défaillance augmente de façon exponentielle. Les phases de déploiements importants chargés d'interdépendances comportent le risque de multiples erreurs. Toutefois, l'utilisation du même processus de déploiement, l'automatisation des tâches manuelles, et l'exécution de modifications incrémentielles permettent de rationaliser le processus de déploiement.

Pour plus d'informations sur la gestion des risques et échecs de déploiement, rendez-vous sur http://ibm.co/UCVlog4.

4. Choisir des solutions pour le déploiement d'applications

Dans ce chapitre

  • Préparer votre entreprise au changement
  • Évaluer les solutions de déploiement
  • Rechercher une solution de coordination des déploiements

Gérer votre application au moyen du pipeline de développement et de livraison, tout en coordonnant le processus global de déploiement automatisé exige des solutions spécifiques. Les solutions d'automatisation du déploiement d'applications et les solutions de coordination des mises en production sont conçues pour déployer des applications de qualité le plus rapidement possible.

Dans ce chapitre, nous examinons comment préparer votre entreprise aux changements que ces solutions impliquent. Nous présentons ensuite des critères élémentaires pour évaluer ces solutions.

4-1. Se préparer aux changements

Avant de commencer à rechercher une solution, souvenez-vous des objectifs des outils d'automatisation et de coordination du déploiement d'applications :

  • accélérer la mise sur le marché : augmenter la fréquence de livraison et la conformité des logiciels avec à une transparence de bout en bout, une meilleure auditabilité, et une réduction des délais de retours clients ;
  • réduire les coûts : réduire la quantité de travail manuel, le temps d'attente des ressources, et la répétition des tâches en éliminant les anomalies et en fournissant des déploie­ments en libre-service ;
  • réduire le risque : fournir des applications de bonne qualité au moyen de processus de déploiements automatisés et reproductibles dans les environnements de développement, test et production.

Habituer vos collaborateurs aux changements peut constituer l'étape la plus longue et la plus difficile dans le processus de mise en œuvre, mais cela est indispensable pour rationaliser les pratiques et automatiser entièrement les déploiements.

4-1-1. Modifier les rôles

Certains des changements les plus importants que vous ferez concernent les tâches individuelles des membres des équipes et les interactions entre ces membres. Avec la méthode Agile, les membres de vos équipes devraient être prêts à ajuster la façon dont ils interagissent ainsi que la fréquence de ces interactions. Ils doivent également être prêts à accepter les solutions d'automatisation et les nouveaux rôles qu'ils joueront au sein de l'organisation.

Examinez avec la direction comment les rôles des collaborateurs vont évoluer afin de garantir aux employés que les solutions d'automatisation les aideront à accomplir leurs tâches quotidiennes. Ces solutions n'ont pas vocation à remplacer la compétence humaine ; elles permettent plutôt de réduire la quantité de tâches manuelles répétitives et risquées. En permettant aux collaborateurs de se concentrer sur les tâches qui exigent davantage de réflexion, elles facilitent le résultat que l'entreprise souhaite obtenir.

Essayez de trouver un sponsor interne qui perçoit les bénéfices associés au changement. Celui-ci peut apporter un éclairage et un point de vue sur les effets à long terme de la solution. Un sponsor au niveau de l'équipe, qui utilise déjà la nouvelle solution, donne à ses pairs une occasion de découvrir les avantages de la part d'une personne confrontée aux mêmes difficultés.

Vous devez introduire ce changement culturel le plus tôt possible. Le chapitre 5 vous donne une estimation générale du temps que peuvent prendre plusieurs changements.

4-1-2. Changer les processus et les solutions

À mesure que les personnes et interactions changent pour répondre aux besoins et objectifs de l'entreprise, il en va de même des fonctions quotidiennes de l'entreprise. Lors de l'introduction de la solution que vous souhaitez utiliser, sachez que vous rencontrerez une certaine résistance. Maintenez votre équipe motivée, et préparez-vous à une période de résolution de problèmes. La réalisation du premier projet important va obliger tout le monde à se confronter à la solution, au nouveau processus, et à découvrir le moyen le plus efficace d'interagir.

Si vous apportez simplement les nouvelles solutions sans préparer votre équipe de façon adéquate, vous avez peu de chance de réussir à les mettre en œuvre. Des changements en matière de processus, de personnes et d'interactions sont également nécessaires pour atteindre votre objectif.

4-2. Évaluer les solutions de déploiement

Les solutions d'automatisation du déploiement d'applica­tions gèrent les composants d'application et leurs versions.

Elles assurent le suivi de l'environnement de chaque version déployée. Ces solutions sont essentielles aux pratiques de déploiement d'applications, comme nous l'expliquerons plus loin dans ce chapitre.

Lorsque vous recherchez une solution d'automatisation du déploiement, selon les objectifs de votre entreprise, vous devez rechercher une solution dotée des fonctionnalités suivantes :

  • réutilisation des processus de déploiement dans les différents environnements ;
  • coordination des déploiements d'application sur plusieurs environnements ;
  • intégration aux technologies existantes ;
  • gestion de la sécurité basée sur les rôles ;
  • gestion des logs de toutes les commandes exécutées lors des déploiements ;
  • traçabilité sur qui a déployé quelle version d'un artefact sur quelle cible.

Priorisez les fonctionnalités dont votre entreprise a le plus besoin pour atteindre les objectifs. Votre entreprise souhaite peut-être garantir l'auditabilité et la gouvernance ou minimiser l'effort requis pour réussir les audits. Dans ce cas, la capacité de la solution à fournir une sécurité basée sur les rôles et à offrir des logs de déploiement est plus importante que ses autres fonctionnalités.

Déploiement réussi avec IBM UrbanCode Deploy

Un organisme financier développait une nouvelle plateforme de transac­tions ayant vocation à être l'élé­ment vital de l'organisation. L'équipe de développement a utilisé les pratiques de développement agile pour produire des résultats plus rapidement, mais le processus de déploiement des applications sur des centaines de serveurs constituait une opération principalement manuelle, avec une personnalisation nécessaire pour chaque application. L'introduction des pratiques de développement agile a en fait provoqué une accumulation des changements pour l'équipe des opé­rations, dont le processus de déploie­ment n'était pas équipé pour gérer des changements fréquents. Ce problème a finalement abouti à l'interruption du développement.

L'institution financière souhaitait tout de même obtenir les bénéfices liés aux méthodologies de développement agile. Après avoir évalué soigneusement les nombreuses solutions, l'entreprise a remplacé ses méthodes de déploiement manuelles par IBM UrbanCode Deploy, qui a apporté de nombreux avantages :

  • les délais de déploiement sont passés de trois jours à deux heures ;
  • l'entreprise a économisé plus de 2 millions de dollars au cours de la seule première année en éliminant le coût des déploiements manuels ;
  • l'entreprise a développé des applications conformes et a donné à ses équipes une option libre-service pour leur déploiement.

4-3. Évaluer les solutions de coordination des déploiements

Planifier, gérer et exécuter un déploiement d'application important s'effectue généralement à l'aide de feuilles de calcul ou de documents texte qui décrivent les tâches, leurs propriétaires et la séquence requise pour un déploiement réussi. Le problème avec cette méthode est qu'il n'existe aucun moyen de suivre qui a fait quoi, quel code a été déployé, où et quand il l'a été.

Les solutions de coordination des déploiements (release management) sont conçues pour aider à planifier et exécuter le déploiement d'une version en planifiant de façon collaborative les changements dans l'application ainsi que dans l'infrastructure. Idéalement, une solution doit fournir une visibilité complète sur le processus de déploiement, ainsi que des fonctionnalités de planification et d'exécution de bout en bout.

Vous devez rechercher une solution capable de réaliser les actions suivantes :

  • rationaliser le lancement de plusieurs applications à la fois ;
  • mettre à jour le plan de déploiement au fur et à mesure ;
  • afficher la progression du déploiement en temps réel ;
  • suivre les modifications dans les applications et l'infrastruc­ture ;
  • notifier les parties prenantes de l'évolution des mises à jour des versions ;
  • séquencer et coordonner les activités automatiques et manuelles dans le workflow de déploiement, toutes les dépendances au sein des activités, et toutes les communications associées aux personnes ;
  • promouvoir automatiquement les applications qui remplissent les critères d'admission de qualité des environnements précédents.

Déploiement réussi avec IBM UrbanCode Release

Une organisation à but non lucratif consacrait beaucoup trop de temps à la planification et la coordination du déploiement de ces applications. Les membres de l'équipe utilisaient des feuilles de calcul pour suivre les activités de lancement et se réunissaient de nombreuses fois pour passer en revue les plans et les modifications des plans. L'organisation souhaitait obtenir une meilleure visibilité sur les efforts liés au déploiement et réduire les temps de réunion lors du processus de déploiement. Elle a finalement sélectionné IBM UrbanCode Release, la première solution conçue spécialement pour la coordination des déploiements d'applications complexes. IBM UrbanCode Release a permis à l'organisation de réduire de 50 % le nombre de réunions lors du lancement, réduire la durée de chaque réunion de 50 %, et d'ajouter de la visibilité à l'ensemble du déploiement. Avant la fin du deuxième déploiement, les membres de l'équipe disposaient d'un bon processus de lancement. Avant la fin de la troisième exécution, le chef d'équipe qui avait mis en œuvre la solution maîtrisait tellement la solution qu'il est parti en vacances pendant la phase de déploiement.

Bien que cela ne soit pas nécessaire, il est conseillé d'utiliser une solution d'automatisation du déploiement avec votre solution de coordination des déploiements. Ensemble, elles permettent de lancer et suivre les déploiements automatisés de plusieurs applications.

5. Mettre en place la solution

Dans ce chapitre

  • Mettre en œuvre une solution d'automatisation du déploiement d'applications
  • Mettre en place une solution de coordination des déploiements

Une fois que votre société a sélectionné les meilleures solutions de coordination et de déploiement d'applications pour répondre à ses besoins (voir Chapitre 4), il vous faut mettre en œuvre ces solutions. Ce chapitre vous donne quelques indications.

5-1. Mettre en œuvre une solution d'automatisation du déploiement d'applications

Comme nous l'évoquons dans le Chapitre 3, les objectifs de l'auto­matisation incluent la traçabilité et la visibilité via une solution qui assure le suivi d'un build (développement) à travers les phases du cycle de développement logiciel (SDLC). Les principaux composants d'un processus de développement robuste dans ce contexte sont un référentiel d'artefacts versionnés pour les builds terminés, et la gestion des dépendances pour les projets liés.

Un des moyens de conserver ces deux composants est de disposer d'un moteur d'intégration continue (CI) ; l'autre moyen consiste à intégrer et suivre les builds manuellement. Avec une méthode d'intégration manuelle, vous devez versionner et conserver les builds dans un référentiel d'artefacts. Lorsque vous avez la visibilité sur ce que contient chaque build, et sur le moment où chaque artefact doit se redéployer si un problème survient dans un environnement, vous avez défini les exigences minimales pour la mise en œuvre de votre solution d'automatisation du déploiement d'applications.

Pour réussir la mise en œuvre d'une solution d'automatisation du déploiement, vous devez disposer d'un processus de développement cohérent et fiable. Si vos builds sont incohérents ou peu fiables, l'automatisation du déploiement peut déceler plus tôt les défaillances de ce processus, mais le problème de qualité intrinsèque persiste.

5-1-1. Choisir le moment idéal pour le déploiement

Lorsque vous progressez dans la mise en œuvre, vos deux principaux défis consistent à faire face à la résistance de votre équipe et à trouver le projet ou l'application qui possède les qualités dont vous avez besoin pour l'automatisation. Ces deux défis sont liés. Le choix de la mauvaise application pour l'automatisation crée de la résistance, et une automatisation mal planifiée ou documentée a de fortes chances d'échouer.

La meilleure pratique, par conséquent, consiste à choisir le bon moment pour déployer l'application ou le projet en question.

Le contexte d'un projet entièrement nouveau constitue un moment idéal, lorsqu'une nouvelle application possède un plan de déploiement qui nécessite une automatisation. Un autre moment idéal potentiel est celui pour un projet existant, qui est déjà en cours, mais se trouve également prêt pour l'automatisation. Choisir le bon projet, qu'il soit entièrement nouveau ou existant, exige un examen approfondi.

Vous devez examiner de près la situation pour déterminer si votre projet ou application est prêt(e) pour l'automatisation. Les applications qui demandent une automatisation possèdent un processus de déploiement bien documenté et (idéalement) une série de tâches répétitives. Si vous considérez un projet entièrement nouveau, celui-ci peut utiliser une application similaire à une appli­cation lancée précédemment, ou son plan de déploiement existant peut simplement être transféré vers la solution d'automatisation. Les mêmes règles s'appliquent à un projet existant. Si vous avez mis en place un processus de déploiement manuel et que vous ressentez une pression à délivrer plus rapidement, vous pouvez transférer le processus vers une solution d'automatisation.

Pour choisir le projet nouveau ou existant adéquat, vous devez savoir comment vos équipes travaillent habituellement et où intervenir. Si vous effectuez généralement des déploiements gérés par le développement, par exemple, vous devez transférer le processus de déploiement et la conception aux équipes des opérations. Si ce processus se termine généralement par la création d'un « mur » entre le développement et les opérations, l'équipe effectuant le déploiement en production devrait être responsable de ce processus et de l'automatisation. Savoir où le processus comporte généralement des interruptions peut être un atout dans la mise en œuvre de la solution, et la chronologie doit aller de pair avec les bons personnes, processus et solutions (voir Chapitre 4).

La Figure 4-1 montre les tâches que vous devez envisager pour savoir la manière de planifier et déployer vos solutions.

Image non disponible

5-1-2. Créer un environnement semblable à la production

Dès que vous avez votre projet à l'esprit, vous devez concevoir un environnement semblable à la production, comme point de départ pour le développement. Cet environnement sera probablement plus petit, mais il doit utiliser les mêmes systèmes d'exploitation, solutions d'infrastructure et configurations que l'environnement de production. Comme nous l'avons vu au Chapitre 2, UAT est l'un des quatre environnements traditionnels du SDLC, et il offre une opportunité de test dans un environnement semblable à la production. Les ressources de production qui ne sont pas disponibles dans les environnements de test doivent être simulées via la virtualisation des services, si possible.

Pour plus d'informations sur la virtualisation des services, voir Service Virtualization For Dummies (Virtualisation des services pour les Nuls), une édition limitée d'IBM, sur ibm.co/servicevirtualization.

Un environnement semblable à la production améliore la précision de vos tests, aussi bien pour les processus applicatifs que de déploiement. Vous pouvez simplifier vos environnements à mesure que vous travaillez à reculons vers les environnements de DEV et TEST et supprimez les composants inutiles.

Impliquez vos équipes des opérations le plus tôt possible au lieu de garder le déploiement final critique en production pour la fin, et espérer que cela se passe au mieux. Donner la possibilité à ces équipes d'intervenir au début du SDLC permet aux équipes de développement de développer et tester leurs builds, et laisse les équipes des opérations libres de tester et déployer les applications. Cela garantit également un environnement conçu par les intéressés, pour maintenir une application en bon état de fonctionnement. Le transfert de certaines responsabilités métier au développement améliore la coordination entre le développement et les opérations et crée un processus bénéfique pour toutes les équipes.

Ce changement dans la façon de penser et dans les processus est l'objectif essentiel de DevOps. Il oblige le développement à prendre en considération les problèmes des opérations tout au long du SDLC, et non pas simplement au moment du déploiement. À leur tour, les équipes de développement ont accès à des environnements semblables à la production qui leur permettent d'effectuer des développements et tests sur un système plus réaliste, comme celui que les utilisateurs utilisent. Les équipes des opérations tirent également des avantages grâce à un aperçu de la façon dont leur environnement réagira à l'application et des endroits où des améliorations de support peuvent être apportées.

5-1-3. Déployer comme s'il s'agissait de la production

Si l'état idéal que vous souhaitez atteindre est un lancement rationalisé composé de déploiements automatisés, vous avez besoin d'un processus cohérent et reproductible. Pour parvenir à ce pro­cessus, commencez par pratiquer des déploiements comme s'il s'agissait de la production, qui peuvent être simplifiés pour les envi­ronnements antérieurs. Les environnements eux-mêmes doivent également être le plus similaires possible à la production. Dans une nouvelle mise en œuvre, trouver un projet capable de s'adapter à ce critère constitue un élément clé.

5-1-4. Concevoir d'abord pour la production

La production étant l'environnement le plus complexe, les déploiements dans les environnements antérieurs doivent être conçus comme des versions plus simples des déploiements de production. L'augmentation de la complexité des déploiements, du développement jusqu'à la production, ne fonctionne pas, tout comme l'augmentation de la taille d'un carré ne crée pas un cube. Les dimensions et la complexité de la production n'ont pas de cadre adéquat dans le développement, par conséquent si vous créez un processus de déploiement basé sur le développement, vous devez finalement le remodeler considérablement en production.

La conception du processus pour la production en premier offre plusieurs avantages :

  • cela permet aux équipes de pratiquer avant le déploiement final critique (voir la section précédente) et fournit le modèle pour les processus restants jusqu'au début du SDLC ;
  • cela permet aux équipes d'affiner et de rationaliser davantage le processus. L'automatisation contribue à cet objectif en stabilisant les étapes qui étaient auparavant manuelles dans un processus complexe, et réduit les efforts nécessaires pour les futurs déploiements ;
  • cela élimine les écarts de complexité des processus de déploiement, entre les premiers et les derniers environnements. Commencer le processus de conception au niveau du développement empêche en réalité l'alignement sur les objectifs des équipes des opérations, car un processus conçu et testé de manière indépendante ne peut pas atteindre le niveau de complexité exigé par les équipes des opérations.

Les développeurs se concentrent sur le test de leurs contributions individuelles et de la partie représentative de l'application complète qui s'applique à leur fonction dans le projet. C'est pour cette raison que bien souvent, les développeurs ne prennent pas en compte ou ignorent ce qui est nécessaire pour maintenir des environnements de production stables et fonctionnels. Du fait de l'ampleur et de la portée de ce qui doit être testé en production, le processus de déploiement ne doit pas être conçu par des équipes qui ne maîtrisent pas l'environnement de production. Ainsi, si l'on permet aux développeurs de concevoir un processus de livraison continue comme extension de l'intégration continue, cette démarche s'arrête inévitablement avant la production et se heurte au mur des opérations.

Pour aligner complètement vos équipes et faciliter la collaboration dès le démarrage d'un projet, vous devez reconnaître l'importance de commencer par les processus les plus compliqués et de suppri­mer des étapes pour les simplifier. il est plus facile de supprimer des étapes que d'en ajouter au cours d'une crise, ou lorsqu'un déploiement a échoué en production.

5-2. Mettre en œuvre une solution de coordination des déploiements

La coordination des déploiements est idéale pour les entreprises qui déploient plusieurs applications en même temps ou qui désirent plus de visibilité sur un processus de déploiement complexe. Comme nous le mentionnons au Chapitre 4, vous pouvez utiliser une solution de coordination des déploiements avec ou sans solution d'automatisation du déploiement.

Si votre processus de lancement est une longue liste de tâches manuelles contenues dans une feuille de calcul, vous devez évaluer des solutions qui contribuent à ce processus. Toutefois, si vous souhaitez mettre en œuvre une coordination associée à une automatisation du déploiement, vous devez avoir mis en place de bonnes pratiques supplémentaires en matière d'automatisation.

5-2-1. Identifier un modèle de déploiement réaliste

Pour tirer pleinement profit d'une solution de coordination des déploiements, vous devez maîtriser votre processus actuel, les applications lancées, et la complexité de ces applications. Vous devez commencer par un déploiement réduit, puis progresser vers le déploiement de multiples applications. Même dans un déploiement réduit où, à titre d'exemple, vous devez tout de même connaître les applications en cours de déploiement, et les personnes impliquées dans le processus traditionnel.

La clé de ce concept est l'échelle. Vous devez commencer par le modèle logique le plus petit d'un processus de déploiement traditionnel. Vous devez utiliser un déploiement qui, bien que réduit, soit utile au moment de l'évolution vers de futurs déploiements en représentant votre processus idéal depuis le début, ce qui implique d'inclure les personnes qui feront partie des déploiements les plus complexes.

Ne vous perdez pas dans des scénarios de simulation, car vous ne pourrez pas tout prévoir avant de commencer réellement à utiliser la solution et à découvrir les domaines susceptibles d'amélioration. Vous et/ou votre équipe devez trouver le moyen de mettre en œuvre la solution de coordination des déploiements qui fournit la plus grande valeur ajoutée.

5-3. Choisir un chemin de mise en œuvre

Après avoir choisi un déploiement comme base de référence pour les futurs déploiements, vous devez identifier une approche vers la mise en œuvre. Trois principales approches assurent une transition en douceur vers une solution de coordination des déploiements :

  • utiliser la nouvelle solution en parallèle avec le processus existant. La première approche consiste à utiliser la solution en parallèle avec un processus de déploiement existant. Ce chemin permet à l'équipe qui gère les déploiements de mapper un processus existant vers le processus de la solution de déploiement, pendant que les deux processus sont en cours d'exécution. En pratique, cela revient à effectuer un déploiement selon la méthode traditionnelle, tout en exécutant le déploiement dans la nouvelle solution pour voir en quoi les tâches diffèrent avec cet outil. Cette pratique aide non seulement l'équipe à s'habituer à l'idée du nouveau processus, mais elle fournit également un exercice sans danger pour la première utilisation, ce qui permet de réduire l'anxiété à propos du déploiement suivant, de faire la démonstration des tâches parallèles dans chaque méthode de déploiement, et de fournir une comparaison de la situation avant-après concernant le processus ;
  • réaliser une exécution après déploiement. La deuxième approche consiste à réaliser une exécution après déploiement, en utilisant la solution pour modéliser un déploiement terminé récemment. Autrement dit, il s'agit de déployer une application à l'aide du processus standard actuel, puis d'utiliser le même processus pour déployer une application avec une solution de coordination des déploiements. Tout comme l'exécution de la solution en parallèle d'un déploiement en cours, cette pratique fournit à l'équipe une comparaison de la situation avant-après du processus, ainsi qu'un moyen d'utiliser la solution pour la première fois en toute sécurité. Les deux premières approches sont des exercices qui fournissent des cas d'utilisation réalistes de la solution, et donnent aux membres d'équipe la possibilité de réaligner leurs attentes et interactions ;
  • se jeter à l'eau. La troisième approche, moins conservatrice que les deux premières, consiste à se jeter à l'eau et à utiliser simplement la nouvelle solution pour un déploiement en direct. Vous devez préparer vos équipes au succès en choisissant un petit déploiement, que vous savez qu'elles pourront exécuter avec la solution. Réduisez le déploiement sélectionné à son état de complexité représentatif minimum, et donnez-le à votre équipe comme première utilisation en direct à faible risque de la solution.

6. Dix mythes à propos du déploiement d'applications

Dans ce chapitre

  • Observez pourquoi l'automatisation est une aide, et non une entrave
  • Découvrez ce qu'une solution spécifique peut et ne peut pas faire

Parfois, la meilleure façon de comprendre ce qui est vrai à propos d'un concept est de comprendre ce qui est faux. Dans cet esprit, il existe dix mythes à propos du déploiement d'applications.

6-1. L'automatisation du déploiement implique la rédaction de scripts

Bien que le lancement de scripts de déploiement individuels puisse fonctionner pour de petits déploiements sur quelques serveurs, cette technique ne saura résister à l'ampleur et à la complexité du déploiement d'applications d'entreprises interdépendantes.

Le fait de reposer sur des experts pour lancer des scripts de déploiement exerce une contrainte sur l'ensemble de l'équipe de déploiement et en particulier sur la personne qui possède cette responsabilité. Si l'expert n'est pas disponible pour lancer le script (ou n'appartient plus à l'organisation lorsqu'une modification est prête au lancement), vous pouvez manquer des échéances, voire toute l'étape. En outre, si l'expert est responsable de l'exécution des scripts pour de multiples déploiements, la probabilité d'erreurs augmente tout comme celle de bogues avec la taille des lots (voir Chapitre 3). De même, les contraintes humaines telles que la fatigue, l'anxiété et la nervosité affectent les performances lorsqu'une personne exécute une longue série de tâches répétitives et à forte pression.

La meilleure solution consiste à laisser une solution d'automatisation du déploiement d'applications d‘exécuter les déploiements, idéalement à l'aide d'intégrations. Si votre solution choisie peut s'intégrer efficacement à vos outils existants, vous devez pouvoir créer un processus de déploiement à l'aide d'un concepteur de processus simple qui ne repose pas sur la rédaction de scripts. Des intégrations efficaces et un concepteur de processus glisser-déposer peuvent supprimer tout ou partie de la rédaction de scripts de votre processus de déploiement.

6-2. Les équipes de développement créent les meilleurs processus de déploiement

Les développeurs savent comment doit fonctionner une application, mais ne savent pas comment fonctionne la topologie des applications dans un environnement de production, car ils n'en ont pas besoin. L'assignation à l'équipe de développement de la tâche de conception d'un processus de déploiement générera probablement un processus qui néglige les principales préoccupations opérationnelles ou les configurations spécifiques à la production, telles que la mise en clusters, l'équilibrage des charges et les intégrations avec des systèmes externes.

Comme nous le mentionnons dans le Chapitre 5, commencer à planifier le processus de déploiement pour la production permet à l'équipe de développement de tester l'application dans un environnement semblable à la production. Cela permet également aux équipes de développement et des opérations de tester très tôt et souvent le processus de déploiement. Les meilleurs processus de déploiement sont le résultat de la collaboration entre l'ingénierie du développement et des opérations.

6-3. Les déploiements complexes peuvent être facilement gérés sans solutions spécialisées

Vous pouvez bien sûr gérer des déploiements d'application simples avec plusieurs méthodes, tels que les e-mails, documents d'exécution, feuilles de calcul, et solutions d'automatisation du déploiement.

Les trois premières méthodes, toutefois, ne fournissent pas la traçabilité ou la planification du déploiement collaboratif, et aucune de ces méthodes ne peut évoluer pour prendre en charge la complexité d'un déploiement d'entreprises interdépendantes.

Bien qu'il soit possible d'utiliser une solution d'automatisation du déploiement pour gérer un déploiement, il est préférable d'utiliser une solution de coordination des déploiements. Les solutions de coordination de déploiement sont conçues pour aider à la planification et l'exécution d'un déploiement en fournissant une planification du déploiement collaborative qui englobe l'application et les modifications de l'infrastructure.

6-4. La livraison continue implique des mises en production constantes

La livraison en continu consiste plutôt à accélérer le plus possible la transmission d'une nouvelle version dans le pipeline de livraison, puis à attendre que l'entreprise décide du moment du déploiement. La même technologie est utilisée pour les déploiements de production, mais la décision est humaine.

Pour la plupart des organisations, les tests automatisés sont insuffisants pour confirmer qu'une version est prête pour la production. Pour elles, la livraison continue réduit au minimum la friction provoquée par le transfert des versions dans les environnements et opti­mise la productivité des équipes de test.

6-5. L'automatisation réduit la qualité et le contrôle

L'automatisation optimise la qualité, car elle exploite les fonctionnalités des ordinateurs pour exécuter des tâches répétitives qui peuvent être bâclées lorsqu'elles sont effectuées manuellement.

Les contrôles sont également améliorés. Le bouton de déploiement soutient la sécurité basée sur des rôles, et les règles d'approbation et de registre de qualité peuvent être mises en application automatiquement. Lorsque vous disposez d'un journal d'audit complet indiquant qui a configuré un processus et qui l'a exécuté, vous savez exactement ce qui s'est passé à tout moment.

6-6. Une feuille de calcul est un bon outil de gestion du déploiement

De nombreuses équipes en charge du déploiement fonctionnent grâce à l'utilisation de feuilles de calcul, mais cette méthode de coordination entraîne presque toujours des erreurs humaines. Les feuilles de calcul permettent effectivement la gestion du processus de déploiement au plus haut niveau, mais elles exigent l'exécution manuelle de tâches hautement répétitives, ce qui augmente le risque d'erreur. Elles nécessitent également une maintenance constante pour garantir que tous les membres de l'équipe de déploiement sont sur la bonne voie. Finalement, à mesure que l'emplacement des équipes varie, que les équipes se développent et que les applications deviennent plus complexes et interdépendantes, les feuilles de calcul deviennent de plus en plus sources d'erreurs et moins utiles, car elles ne s'adaptent pas à la complexité du déploiement.

Contrairement aux feuilles de calcul, les solutions de coordination de déploiement saisissent les interdépendances et déterminent la stratégie de déploiement la plus efficace. Elles alertent également les membres de l'heure du déploiement, lorsque certaines étapes clés du processus ont été réalisées ou lorsque certaines compétences des membres d'équipe sont requises.

Les solutions de coordination de déploiement sont vivement conseillées pour les organisations qui possèdent un processus de déploiement complexe ou des équipes distribuées, ou qui n'ont pas réussi à gérer leur processus de déploiement avec des feuilles de calcul.

Les solutions de coordination de déploiement peuvent être utilisées sans solution d'automatisation du déploiement, mais il est conseillé d'utiliser les deux pour réduire les risques associés aux tâches manuelles répétitives et accélérer la mise sur le marché.

6-7. Un grand déploiement est moins risqué que plusieurs petits

En fait, les déploiements importants comportent un risque de plus en plus élevé selon le nombre d'interdépendances incluses, comparé aux déploiements réduits et fréquents. Si vous rationalisez le processus de déploiement par l'utilisation de solutions d'automatisation, vous libérez votre personnel pour lui permettre de dépanner le processus au lieu d'avoir à exécuter des tâches manuelles hautement répétitives.

Les déploiements plus petits comportent moins d'éléments et d'interdépendances. Les erreurs provoquées par la mauvaise compréhension ou la mauvaise prise en compte de l'interdépendance sont réduites considérablement dans un « petit » déploiement.

Les modifications incrémentielles au moyen d'un véritable processus de livraison continue (CD) constituent l'objectif ultime d'une organisation qui souhaite fournir de la valeur ajoutée en proposant de nouvelles fonctionnalités, à un rythme plus élevé que ses concurrents. Les petites modifications fréquentes fournies au moyen de solutions d'automatisation constituent la première étape dans la réduction du coût et du risque associés aux déploiements traditionnels.

6-8. L'automatisation est indépendante du processus de développement

Malheureusement, tant que vous ne respectez pas les exigences minimales d'un référentiel d'artefacts élémentaire, d'une gestion des dépendances et d'une production de haute qualité issue de votre processus de développement, vous n'êtes pas prêt à envisager l'automatisation du déploiement. Les éléments du déploiement doivent être présentés en versions ou prêts à être présentés en versions pour permettre le suivi de ce qui est déployé et de l'endroit où l'élément est déployé. Pour exécuter des déploiements réussis qui fournissent une visibilité sur l'ensemble du SDLC, vous devez vous assurer que les dépendances sont gérables, visibles et évidentes dans le cadre de votre processus de développement.

Vous pouvez généralement atteindre l'état minimum requis avec l'aide d'un serveur d'intégration continue (CI) qui fournit également la gestion des versions et les fonctionnalités de libre-service pour le déploiement dans des environnements de test. Les formes manuelles de CI peuvent vous donner une longueur d'avance sur l'automatisation du déploiement, mais n'offrent pas la visibilité complète que nous recommandons d'atteindre avant de passer aux solutions d'automatisation du déploiement. L'objectif principal d'un processus de développement rationalisé est de créer des builds en état de fonctionner, présentés en versions cohérentes et prêts à être déployés dans les environnements de test puis de production à un niveau de qualité élevé.

Certaines solutions d'automatisation du déploiement d'applications fournissent une fonctionnalité de gestion des versions avec un référentiel d'artefacts propriétaire. Cette fonctionnalité vous permet d'ignorer l'étape de gestion des versions de vos propres builds et d'utiliser la solution d'automatisation du déploiement d'applications pour intégrer cette étape. Cette solution est IBM UrbanCode Deploy.

6-9. Un retard des éléments à déployer n'indique pas un problème DevOps

Si vous déclarez pratiquer la livraison continue (CD), mais que votre équipe des opérations fait face à un retard très important de la part du développement, vous avec un problème de DevOps , et vous ne pratiquez pas réellement la livraison continue. Les pratiques et solutions DevOps vous aident à saisir les opportunités du marché et réduire le délai de réception des commentaires des clients, en permettant une véritable livraison continue. Lorsque vous décidez de mettre en œuvre des solutions de déploiement, vous devez vous préparer à travailler dans une culture DevOps, ce qui implique des changements pour les personnes, les interactions, les processus et les solutions (voir Chapitre 2 pour plus de détails sur DevOps).

Lorsque vous avez réduit au minimum les différences entre les environnements de développement et des opérations, standardisé votre processus de déploiement, et automatisé la plupart ou la totalité de vos tâches manuelles, vous avez terminé la mise en place d'une solution DevOps. Cette solution DevOps accélère la livraison de logiciels, réduit le délai d'obtention des commentaires des clients, améliore la gouvernance sur le SDLC, et équilibre la qualité, le coût et la vitesse.

6-10. Les solutions de coordination des déploiements règlent tous les problèmes

Le passage d'un processus de déploiement entièrement ou principalement manuel à un processus automatisé est difficile, et exige la prise en compte de plusieurs facteurs. L'une des modifications à long terme concerne la culture de votre entreprise. Les membres de votre personnel et leurs interactions doivent être alignés sur la nouvelle méthode de travail, et peuvent être amenés à modifier leurs responsabilités. Vous devez préparer vos équipes à ce changement, vous attendre à une résistance, et rester conscient de ce qui fonctionne et ne fonctionne pas pour votre organisation.

Lorsque vous aurez sélectionné le bon projet pour mettre en œuvre les solutions d'automatisation du déploiement d'applications et de coordination des versions, vos équipes n'auront pas d'autre choix que de collaborer. Toutefois, les préparer le mieux possible à ce changement rendra la transition plus facile et vous aidera à atteindre vos objectifs commerciaux. Tout comme la résolution des problèmes de développement et d'intégration continue (CI) réduit les goulots d'étranglement du déploiement et de la livraison continue (CD), vous commencerez peut-être à voir de nouvelles opportunités d'amélioration dans votre SDLC après l'introduction de solutions de déploiement.

7. La simplicité avant tout

La pratique de déploiement DevOps permet une livraison des logiciels plus fréquente. La pertinence d'une entreprise repose sur sa capacité à déployer des applications au même rythme que les besoins de l'utilisateur, tout en préservant les systèmes critiques qui les supportent. Cet ouvrage définit les bases du déploiement d'applications et fournit les meilleures pratiques pour la mise en œuvre.

  • Accélérer la mise sur le marché : augmentez la fréquence de livraison des logiciels grâce à des processus de déploiement automatisés et reproductibles dans les environnements de développement, de test et de production.
  • Réduire les coûts : réduisez la quantité de travail manuel, le temps d'attente des ressources, et la répétition des tâches en éliminant les erreurs et en fournissant des déploiements en libre-service.
  • Réduire le risque : offrez des déploiements d'application de haute qualité avec une conformité accrue, grâce à la transparence de bout en bout, l'auditabilité et la prise en compte plus rapide des réactions des utilisateurs.

8. Remerciements

L'équipe developpez.com tient à remercier John Wiley & Sons, Inc.

Licence : www.wiley.com/go/eula

Le déploiement d'applications pour les Nuls®, édition limitée IBM

Publié par

John Wiley & Sons, Inc.

111 River St.

Hoboken, NJ 07030-5774 www.wiley.com

Copyright © 2013 John Wiley & Sons, Inc., Hoboken, New Jersey

Aucun extrait de cette publication ne peut être reproduit, stocké dans une base de données ni transmis, sous quelque forme ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement, numérisation ou autre), sauf aux conditions autorisées aux alinéas 107 et 108 du United States Copyright Act de 1976, en l'absence d'autorisation écrite préalable de l'Éditeur. Les demandes d'autorisation doivent être adressées par courrier à Permissions Department,

John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, par téléphone au (201) 748-6011, par télécopie au (201) 748-6008 ou en ligne sur http://www.wiley.com/go/permissions.

Marques : Wiley, pour les Nuls, le logo Dummies Man, The Dummies Way, Dummies.com, Making Everything Easier et les appellations commerciales afférentes sont des marques commerciales ou déposées de John Wiley & Sons, Inc. et/ou de ses sociétés affiliées aux États-Unis et dans d'autres pays, dont l'utilisation est interdite en l'absence d'autorisation écrite. IBM et le logo IBM sont des marques déposées d'IBM. Toutes les autres marques citées sont la propriété de leurs détenteurs respectifs.

John Wiley & Sons, Inc., n'est lié à aucun des produits ou fournisseurs cités dans cet ouvrage.

LIMITATION DE RESPONSABILITÉ/DÉNI DE GARANTIE : L'ÉDITEUR ET L'AUTEUR S'ABSTIENNENT DE TOUTE DÉCLARATION OU GARANTIE S'AGISSANT DE L'EXACTITUDE OU DE L'EXHAUSTIVITÉ DU CONTENU DE CET OUVRAGE, ET REJETTENT EN PARTICU LIER TOUTE GARANTIE, Y COMPRIS, NON LIMITATIVEMENT, TOUTE GARANTIE D'APTITUDE À UN USAGE PARTICULIER. AUCUNE GARANTIE NE PEUT ÊTRE CONSENTIE OU ÉTENDUE AU TITRE D'UN DOCUMENT COMMERCIAL OU PROMOTIONNEL. LES CONSEILS ET STRATÉGIES PRÉSENTÉS ICI RISQUENT DE NE PAS CONVENIR À TOUTES LES SITUATIONS. CET OUVRAGE EST COMMERCIALISÉ, SACHANT QUE L'ÉDITEUR NE DISPENSE AUCUN SERVICE JURIDIQUE, COMPTABLE OU AUTRES SERVICES PROFESSIONNELS. SI UNE ASSISTANCE PROFESSIONNELLE EST REQUISE, LES SERVICES D'UN PROFESSIONNEL COMPÉ­TENT DEVRONT ÊTRE SOLLICITÉS. NI L'ÉDITEUR, NI L'AUTEUR NE POURRONT ÊTRE TENUS RES­PONSABLES DES DOMMAGES DÉCOULANT DES PRÉSENTES. SI UN ÉTABLISSEMENT OU SITE WEB EST RÉFÉRENCÉ DANS UNE CITATION ET/OU COMME SOURCE POTENTIELLE D'INFORMATIONS COMPLÉMENTAIRES DANS CET OUVRAGE, CELA NE SIGNIFIE AUCUNEMENT QUE L'AUTEUR OU L'ÉDITEUR AVALISE LES INFORMATIONS SUSCEPTIBLES D'ÊTRE COMMUNIQUÉES PAR CET ÉTABLIS­SEMENT OU CE SITE WEB OU SES RECOMMANDATIONS. PAR AILLEURS, LE LECTEUR DOIT AVOIR CONSCIENCE QUE LES SITES WEB CITÉS DANS CET OUVRAGE PEUVENT AVOIR ÉVOLUÉ OU DIS­PARU ENTRE LE MOMENT OÙ CE LIVRE A ÉTÉ ÉCRIT ET CELUI OÙ IL EST LU.

Pour toute information d'ordre général sur nos autres produits et services, ou pour obtenir tous les détails utiles sur la création d'un ouvrage pour les Nuls personnalisé adapté à votre entreprise, veuillez contacter notre service de développement commercial aux États-Unis par téléphone au 877-409-4177, envoyer un e-mail à , ou consulter le site www.wiley.com/go/custompub. Pour de plus amples informations sur l'exploitation sous licence de la marque pour les Nuls avec des produits ou services, contactez .

ISBN : 978-1-119-18613-7 (pbk) ; ISBN : 978-1-119-18614-4 (ebk)

Fabriqué aux États-Unis

Remerciements de l'éditeur  :

Voici une liste non exhaustive des personnes qui ont contribué à la publication de cet ouvrage :

Rédacteur du projet : Carrie A.
Responsable des acquisitions :
Connie Santisteban
Responsable éditorial : Rev Mengle

Délégué du développement :
Sue Blessing
Coordinateur de production :
Melissa Cossell

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2015 John Wiley & Sons, Inc.. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.