Home » DEVOPS

Category Archives: DEVOPS

Abonnez-vous à ce blog par e-mail.

Saisissez votre adresse e-mail pour vous abonner à ce blog et recevoir une notification de chaque nouvel article par email.

Les changements à l’ère de DEVOPS

ITIL propose un processus de gestion des changements destiné à ne mettre en production que des services éprouvés pour éviter les impacts négatifs sur les utilisateurs. A l’heure où les entreprises sont en recherche permanente d’agilité et où DEVOPS s’impose, l’approche ITIL semble dépassée. Mais est-elle vraiment dépassée où n’est-ce pas plutôt un échec de mise en oeuvre des meilleurs pratiques qui est en cause? Dans cet article, nous allons faire un gros plan sur ce que devrait être la gestion des changements. Et nous allons nous intéresser tout particulièrement au CAB (Comité Consultatif des Changements), mal utilisé le plus souvent.

ITIL - Le CAB à l'heure de DEVOPS
Crédit © rawpixel.com 2018

La seule raison pour laquelle la plupart des personnes et des organisations ont entendu parler du CAB (Change Advisory Board) est qu’il est décrit dans la section sur la gestion du changement des publications ITIL. La plupart des organisations ont alors considéré que si le CAB est décrit dans ITIL, c’est qu’il est obligatoire. Souvent il a donc été mis en œuvre avec enthousiasme comme mécanisme de contrôle de la qualité dans les grandes entreprises. Pour beaucoup de professionnels des opérations non informatiques, le CAB est leur seul contact avec ITIL. Il en est d’ailleurs presque devenu synonyme. Cela signifie également qu’ITIL est lui-même devenu synonyme de douleur récurrente qui revient toutes les deux semaines…

Le conte des trois erreurs

Il en va de la gestion des changements comme de beaucoup d’autres domaines de l’informatique. Il y a une différence significative entre la théorie et la pratique. Pourtant, il est exact que la théorie (dans l’ITSM) a été (partiellement) construite sur la base des pratiques du monde réel. Cependant, il s’agit en fait d’une version idéalisée d’une tentative de description globale destinée à être adaptée à chaque situation particulière. Ce n’est en aucun cas une prescription de ce qui doit être mis en oeuvre tel quel dans les organisations.

Nous allons tenter de mettre tout le monde d’accord pour commencer à travailler à améliorer la pratique de la gestion des changement. A mon sens, c’est une approche à privilégier plutôt que d’essayer de se rassurer dans des initiatives de type «dénigrement» ou «coup de tête». Elles conduisent le plus souvent à des actions de type « paniqué-coupé-renommé-collé » à partir d’une théorie mal comprise..

Il y a trois domaines principaux dans lesquels la confusion à propos du CAB (Change Advisory Board / Comité Consultatif des Changements) et des pratiques de gestion du changement en général ont entraîné des dysfonctionnements importants. Nous allons essayer de les identifier avant de les comprendre dans le détail..

Survol des trois erreurs

Tout d’abord, il y a beaucoup d’incompréhension quant à la signification de la lettre «A» dans l’acronyme «CAB». Deuxièmement, il y a également une incompréhension quant aux changements qui devraient «passer par le CAB». Troisièmement, il existe une confusion relative à la séparation des pratiques de gestion des changements et des pratiques de gestion des mises en production. Cela fait beaucoup pour un seul processus, certes majeur, parmi les 25 processus décrits dans les publications ITIL 2011.

Commençons par rappeler quelques notions issues d’ITIL, mais souvent incomprises :

  • CAB signifie «Change Advisory Board» (Comité Consultatif des Changements) et non pas «Change Approval Board» (Comité d’Autorisation des Changements).
  • Le CAB n’est pas obligatoire dans ITIL, pas plus que l’envoi de toutes les demandes de changement (RFC) au CAB.
  • A chaque fois que les auditeurs exigent des décisions du CAB, ils confondent la fin et les moyens.
  • Lorsque les managers exigent des décisions du CAB, alors c’est qu’il existe probablement un problème de confiance.
  • L’automatisation (pour les modifications logicielles) rend même les auditeurs plus heureux.
  • Le logiciel circulant dans le pipeline CI / CD (intégration continue / livraison continue) n’est pas destiné à passer par le CAB.
  • L’amélioration des pratiques de gestion du changement requiert la réduction du nombre d’intermédiaires intervenant dans le processus pour améliorer son efficacité.

1 – « A » pour « Advisory » (conseiller)

Comme son nom l’indique, le CAB (Comité Consultatif sur les Changements) a pour objectif de conseiller sur l’évaluation des changements. Il est utile principalement lorsqu’il s’agit de changements à haut risque ou de changements à grande échelle qui vont au-delà du champ de perception d’une équipe particulière. Dans ce cas de figure, ils nécessitent la coordination et la gestion de situations complexes. Il faut alors faire face à des priorités conflictuelles et faire des choix en raison de coûts ou de délais. Le rôle du CAB, dans de telles situations, est essentiel car il permet de recueillir les avis de toutes les parties prenantes.

Pour diverses raisons, le mot «Advisory» (Consultatif) est devenu «Approval» (Approbateur) dans de nombreuses entreprises. Le CAB s’est alors transformé en un mécanisme de création de retard sans valeur ajoutée. Il est censé être là pour des raisons de qualité, mais il atteint rarement son objectif. La différence entre les mots est loin d’être seulement une question pédante de sémantique :

  • Advisory: avoir ou exercer le pouvoir de conseiller
  • Approval: acte ou instance d’approbation de quelque chose

Un mode de fonctionnement inefficace qu’il faut absolument améliorer

De plus, les CAB, dans les entreprises, ont souvent tendance à être statiques. C’est toujours même groupe de managers qui discute de tous les changements qui leur sont apportés, quels que soient l’équipe / l’application / le service concerné. Ils invitent parfois les auteurs de RFC (Request For Change / Demande de Changement) ternes et volumineuses à y ajouter un peu de couleur. Cette approche introduit un niveau d’intermédiation qui perd beaucoup de détails.  Par conséquent le risque est grand de créer un type de pratique, fonctionnel techniquement mais défaillant dans la pratique. L’absence d’avis est une chose, mais l’échec en matière d’approbation en est une toute autre.

La pratique consistant à utiliser des RFC dans l’entreprise semble davantage venir d’un livre de recettes que de l’ITSM. La dynamique de la mise en œuvre repose alors sur un examen minutieux afin de s’assurer que tous les champs du formulaire sont remplis. Elle ne repose pas sur des conseils pertinents. En effet, souvent, les RFC contiennent des informations destinées au CAB. Elles ne contiennent pas les questions et les réponses de / à la personne ou l’équipe recherchant un avis.

Cela ne veut pas dire que des contrôles de qualité ne doivent pas être mis en place. Cependant un mécanisme intervenant tardivement dans le jeu, de type Potemkin, est plus susceptible de gêner que d’aider l’entreprise à atteindre ses objectifs. La réduction du nombre d’erreurs est alors obtenue en évitant les changements plutôt qu’en améliorant la résilience du système. En effet, la dynamique est tellement lourde, coûteuse et chronophage que les « petits » changements seront rejetés. Ceci peut souvent conduire, en retour, à un besoin de changements de grande ampleur. C’est notamment le cas  lorsque le système a dépassé sa date de péremption et échoue sur plusieurs fronts simultanément.

Pour améliorer les pratiques dans ce domaine, une réduction réfléchie et consciente des intermédiaires est nécessaire. Ainsi l’évaluation de l’impact et la prise de décision seront rapprochées du lieu où le travail est réalisé. L’efficacité, les coûts et les délais n’en seront qu’améliorés.

2 – Pratiques obsolètes et manque de confiance

Comme nous venons de le voir, le CAB peut être un élément utile de la gestion des changements pour certains types de changements. Il sera beaucoup moins utile pour d’autres. Notez bien que je dis «peut être», ce qui signifie que le CAB est facultatif et en aucun cas obligatoire. Il ne devrait être introduit que s’il est vraiment utile. Sa conception, sa portée, son rôle et sa valeur doivent être réexaminés de manière continue.

Parmi les autres raisons, il y en a deux concernant le «CAB abusif» que je voudrais évoquer ici. La première concerne les pratiques d’audit. Il s’agit de l’exigence de documenter et d’approuver chaque changement. Il est alors tentant de considérer le CAB comme la seule / meilleure méthode pour y parvenir. La première partie de cette exigence est plutôt raisonnable. Pourquoi ne voudrions-nous pas garder la trace des changements? La deuxième partie, par contre, est un exemple de prédominance du « comment » sur le « pourquoi ». Cette exigence est souvent tellement enracinée qu’elle ressemble à une loi intangible. Elle élimine alors d’autres méthodes de travail qui permettraient d’atteindre le même résultat, mais avec un fonctionnement différent.

Les pratiques obsolètes pour satisfaire les auditeurs

Demander au CAB de signer chaque demande de changement a peut-être été le seul moyen pour l’organisation de répondre aux exigences de la vérification par le passé. Ce n’était certainement pas une préconisation figurant dans les directives ITIL. Il suffit de voir, par exemple, l’autorité de changement et la notion de changement standard. Cela a, très probablement, satisfait les objectifs de la gestion des risques, sur papier uniquement. Et finalement cela a été considéré comme suffisant.

Du matériel coûteux, des temps d’approvisionnement longs et des temps de planification encore plus longs ont rendu les approches, idéales d’un point de vue théorique, plutôt populaires. Cependant, le monde a changé.  La plupart des entreprises disposent maintenant d’un soutien suffisant pour investir dans les méthodes et les pratiques informatiques modernes. Il n’est donc plus nécessaire de continuer à jouer ainsi sur le registre de la gestion des risques.

Evitons donc de compter sur des revues de qualité souvent gérées par des personnes ignorantes du contexte. Nous pouvons plutôt utiliser des pratiques d’automatisation, dans lesquelles la documentation détaillée de chaque changement est fournie par défaut. Outre l’amélioration de la qualité du service, nous disposerons alors d’une grande quantité d’informations, plus fiables. Et nous pourrons fournir ces informations aux auditeurs qui seront satisfaits.

L’option d’automatisation s’applique principalement, à priori, aux changements logiciels. Or, dans le contexte du cloud, ceux-ci incluent des éléments de gestion d’infrastructure (« infrastructure as a code »). Mais ensuite, dans quelle mesure est-il raisonnable de prendre en compte les changements logiciels individuels dans le cadre de la gestion «traditionnelle» des changements?

Le manque de confiance dans les équipes

La deuxième raison pour laquelle les CAB sont si populaires et pourtant mal utilisés est la méfiance. Derrière cela se cache aussi la nécessité de sauver ses fesses au cas où quelque chose se passerait mal. Le CAB devient alors un mécanisme pour imposer un contrôle sur des équipes de spécialistes. En effet, sinon, comment savoir si elles travaillent exactement comme on le souhaite?

Dans ce scénario, plutôt que d’utiliser le concept d’autorité de changement et de laisser les équipes les plus proches du travail prendre des décisions, toutes ces décisions sont transférées au niveau du CAB. C’est là que les responsables du responsable du responsable de l’équipe discutent et décident des changements acceptables. Même si le pouvoir décisionnel revient au CAB, c’est toujours le demandeur du changement qui est tenu pour responsable. C’est-à-dire que, si quelque chose se passe mal, le CAB pourra prétendre avoir demandé des informations complètes et justes. Alors, la raison pour laquelle des résultats inattendus sont obtenus sera qu’il disposait d’informations erronées ou incomplètes. Et, on vous expliquera que dès qu’on identifiera qui est l’individu responsable du fiasco, on s’assurera que cela ne puisse plus se reproduire…

3 – La bataille du RAP

La troisième incompréhension porte sur la confusion entre les changements et les mises en production. Mais elle renvoie également au défi que pose la portée du CAB. La gestion du changement détermine si quelque chose doit être changé et quand. La gestion des mises en production vérifie si le package de modifications, quel que soit son contenu, est prêt à être mis en production et à quel moment. Par souci de simplicité, examinons la gestion des mises en production dans le cadre de la gestion des changements…

La manière dont le CAB a été conçu dans de nombreuses organisations pour les changements liés aux logiciels est en réalité un processus d’approbation de mise en production (RAP : Release Approval Process). D’ailleurs ce processus est assez amusant. Plutôt que d’évaluer l’état de préparation à la mise en production et au déploiement (ce qui est à nouveau une tâche à effectuer, de préférence de manière automatisée avec beaucoup de retours), le RAP/CAB évalue la viabilité du changement lorsque le travail sur ce changement a déjà commencé, ou même le plus souvent, a déjà été achevé. C’est évidemment bien trop tard!

Les processus de prise de décision pour les changements (si une modification logicielle est nécessaire) et pour les mises en production (comment valider au mieux la modification) sont déconnectés et mal alignés. Dans ces organisations, la pratique de gestion du changement – bien que généralement non dénommée ainsi – s’appuie sur« le métier», et« l’informatique » et permet de prendre les commandes une fois la décision prise, de livrer ce qui était prévu (mais rarement décrit correctement), et d’assurer qu’aucune perturbation ne surviendra sur aucun service.

Il y a trop de dysfonctionnements dans ce scénario pour pouvoir les détailler et les intégrer dans cet article. Aussi, ce que je voudrais faire, c’est proposer un point de vue différent pour examiner les changements logiciels. Cela permettra peut-être de supprimer en partie la tension entre la communauté ITSM et la communauté DevOps.

Etendre le mandat

Examinons le développement logiciel agile avec intégration continue (CI: Continuous Integration) et livraison continue (CD: Continuous Delivery). En principe, nous pouvons supposer que le code injecté dans le pipeline CI / CD a été pré-approuvé. C’est-à-dire que le développeur a le mandat de travailler dessus. Il nécessite seulement de passer les contrôles de qualité (automatisés) avant d’atteindre l’environnement de production.

Cette approbation préalable ne signifie pas que quiconque a demandé que le travail de développement soit effectué soit sûr à 100% que ces changements spécifiques produiront les résultats escomptés. Pas plus que le développeur n’est totalement convaincu que le code passera les revues qualité sans problèmes. Le temps de retour pour le développeur se compte en minutes / heures. Il se compte pour le client en heures / jours / semaines, en fonction de la conception du pipeline et de la méthodologie de développement utilisée. Le délai de retour est donc extrêmement long et ne correspond pas aux besoins des métiers.

Si le client a déjà décidé qu’il souhaite le changement, cette décision doit en réalité être une décision du CAB. Mais ce n’est pas le CAB tel qu’il est mis en oeuvre habituellement. Ainsi, plutôt que d’essayer même d’évaluer manuellement chaque version logicielle en cours de traitement dans un CAB (ou RAP), les équipes chargées de la gestion des changements et des mises en production doivent alors travailler ensemble pour concevoir et améliorer le pipeline CI / CD. et des revues qualité automatisées.

Est-il raisonnable de démanteler le CAB?

Quelle que soit la conception de votre CAB actuel ou futur, la question clé à garder à l’esprit est la suivante: aide-t-il à obtenir les résultats attendus des métiers?

Une Gestion des Changements efficace ne peut pas être limitée à un portique de sécurité pour l’accès au service informatique. Cela signifie que la gestion du changement n’est pas basée uniquement sur le CAB. Le CAB n’est pas le processus de gestion des changements. C’est juste un mécanisme qui peut être utile au sein du processus. Il reste probablement beaucoup d’autres choses nécessitant une amélioration dans votre gestion du changement.

S’agissant de votre CAB, s’il s’agit d’un groupe de personnes qui ne connaissent pas les détails des changements / mises en production dont ils discutent mais qui prennent cependant des décisions en évitant de répondre de ces décisions, alors c’est clairement un CAB à éliminer d’urgence.  En effet, ce n’est pas du tout le CAB, préconisé par les bonnes pratiques, dont votre entreprise a besoin..

Mais si c’est un groupe de personnes qui peuvent conseiller sur les changements planifiés, aider à la coordination et à la hiérarchisation, et qui sont là pour aider l’organisation plutôt que leur carrière personnelle, alors conservez-le. Mais améliorez-le de façon continue également.

Vous souhaitez évaluer la viabilité des changements? Alors, vous devez le faire en vous appuyant sur des personnes qui comprennent ces changements. C’est la viabilité des Mises en Production que souhaitez évaluer? Alors, cette tâche devrait être effectuée par des personnes qui comprennent ces Mises en Production.

Pour améliorer la qualité, n’oubliez jamais que vous devez réduire les intermédiaires et automatiser autant que faire se peut.

 

Crédits : cet article est inspiré d’une publication de Kaimar Karu

Nouveau: DevOps débarque en Afrique!

Une évolution nommée DevOps

Apparu depuis quelque temps, un nouveau mouvement professionnel et culturel visant à améliorer le flux entre les développeurs de logiciels et les équipes opérationnelles commence à faire ses preuves. Encore peu répandu sur le continent Africain où, pourtant, de nombreuses organisations réalisent leurs propres développements de logiciel en interne avant de les exploiter, DevOps répond clairement à un besoin croissant d’agilité des organisations dans un contexte de plus en plus mondialisé. Certains en ont peut-être déjà entendu parler sur des blogs ou via des offres d’emploi.

Dans un premier temps, DevOps peut être vu comme un outil d’amélioration des performances opérationnelles fonctionnant de manière intelligente. La stratégie DevOps aura un impact sur l’ensemble des réseaux de distribution. A la clé figurent des avantages non négligeables:

  • réduction du temps de commercialisation,
  • diminution des problèmes liés aux nouvelles publications,
  • réduction des délais de mise à disposition de correctifs
  • et accélération des temps de reprise après sinistre.

L’évolution constante des entreprises vers le numérique pousse désormais les développeurs à revoir sérieusement les modes de création d’applications.

DevOps-Evolution

Il n’est désormais plus tolérable d’attendre 6 mois, voire 1an avant de livrer les services demandés par les entités business. Les systèmes d’information doivent s’aligner sur la sortie des produits et services métiers. Le marketing ne peut plus attendre, surtout que les projets futurs deviennent de plus en plus complexes notamment en matière informatique. Le tout se retrouve dans un contexte économique pesant sur les budgets. Dans le cadre de ce développement, DevOps répond parfaitement à ce défi digital et les entreprises en ont maintenant pris conscience.

Qu’est-ce que DevOps?

DevOps est l’abréviation de « Développement » et « Opérations » dans le domaine informatique. Ce n’est pas un outil, un processus ou une méthodologie. DevOps a débuté comme étant, et continue d’être, une convergence d’idées en vue de combler le fossé qui sépare les équipes de développement et d’exploitation dans les Directions Informatiques. L’idée maitresse est de rationaliser le développement de logiciels et de faciliter leur exploitation et leur maintenance. Le terme DevOps identifie un mouvement déclenché par la frustration des professionnels de l’informatique, vers 2010, résultant des dysfonctionnements et de l’incapacité d’y remédier du fait d’outils et de processus inadaptés. Ces professionnels IT frustrés ont partagé leur vision du fait que le développement de logiciels et les opérations peuvent, et doivent être plus efficaces et moins douloureux.

Aujourd’hui, la définition originale de DevOps comme étant l’intégration du « développement » et des « opérations » est devenue trop limitée et inexacte. DevOps implique plus d’acteurs que les seuls développeurs et les techniciens d’exploitation. Le cycle de développement de logiciel  implique également de nombreux autres rôles qui constituent des contributeurs essentiels. Parmi ceux-ci, citons la gouvernance, l’assurance qualité (QA), les tests, la sécurité et la gestion des versions. DevOps est donc une combinaison de personnes, de culture, de processus, d’outils et de méthodes  réduisant les risques et les coûts, et permettant à la technologie d’évoluer à la vitesse de l’entreprise, et d’améliorer la qualité globale.

Pourquoi une nouvelle approche?

L’approche traditionnelle repose sur un ensemble de facteurs qui la fragilisent et l’alourdissent. DevOps représente une prise de conscience que l’approche traditionnelle n’est plus en mesure de satisfaire le besoin d’agilité nécessaire à l’Entreprise pour rester concurrentielle. Un exemple typique serait le cas du web qui gère des applications dans le Cloud. DevOps est une démarche innovante qui s’apparente à une philosophie destinée à des personnes à la recherche d’efficacité.

Pour la réalisation des grands projets informatiques, différentes équipes aux rôles bien définis sont impliquées. Il s’agit d’une part de l’équipe de développement et d’autre part de celle chargée de l’exploitation. Habituellement, les équipes de développement tentent de répondre à des spécifications fonctionnelles issues du métier ou du client. Elles travaillent généralement dans leur propre environnement, avec leurs outils destinés aux développements. Elles ne se soucient guère de l’impact que peut avoir leur code sur la phase d’exploitation qui exécutera l’application sur un environnement de production. Les équipes chargées de l’exploitation, quant à elles, tentent de répondre à des impératifs de performance ou de stabilité du système. Et c’est pourquoi, elles sont très attentives à minimiser les impacts des modifications afin de préserver ces performances. Hélas, cela risque de générer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.

Quelle que soit l’équipe, il est toujours compliqué d’être au courant de comment une autre équipe gère ses tâches. Cela rend difficile l’optimisation des deux côtés. C’est à ce niveau qu’intervient DevOps dont le rôle est, en quelque sorte, de réaliser l’intégration des différentes équipes pour faciliter la communication et diffuser l’information. Les autres fonctions de DevOps incluent l’amélioration de la coordination durant les phases de livraison et de déploiement afin de limiter les erreurs.

Les résultats sont-ils probants?

Les résultats sont probants et donnent un bon aperçu des avantages de DevOps. Selon un sondage récent 66% des entreprises dans le monde utilisent déjà une stratégie DevOps ou envisagent d’en mettre une en œuvre. Plus de 90% d’entre elles ont observé ou s’attendent à un gain substantiel grâce à leurs initiatives DevOps. Les résultats de DevOps sont réels et quantifiables car cette approche génère des améliorations, augmentations ou réductions, à deux chiffres (de 17 à 23%).

Infographie DevOps

Les résultats concernant la France sont inférieurs aux chiffres résultants du sondage mondial mais sont néanmoins significatifs.

Quels sont les enjeux?

L’arrivé de DevOps met la pression aux développeurs car ils doivent produire davantage dans un temps réduit et réaliser des tests supplémentaires tout en respectant les contraintes budgétaires imposées. Parmi les enjeux majeurs apparaissent la réactivité commerciale et les délais de commercialisation qui bien souvent affectent l’expérience du client. Cela dit, DevOps impose un niveau de collaboration, d’agilité, de visibilité de développement et de rapidité de distribution qui relève le défi des projets à long terme dont la lenteur est à bannir compte-tenu des contraintes du monde de l’entreprise.

La stratégie DevOps est moins adaptée aux mainframes car il est généralement compliqué de faire évoluer des processus traditionnels bien ancrés et de développer la collaboration autour de technologies solidement établies. La majorité des schémas organisationnels sont en réalité inadaptés ou insuffisants pour permettre aux équipes de développement d’atteindre leurs objectifs et le niveau de productivité qu’exige leur entreprise.

DevOps, pour quels bénéfices

Le slogan pré-Devops était « Vite vite on met en production ! ». Mais attention, il ne faut pas confondre vitesse et précipitation. La production c’est du sérieux ! En effet, les développeurs produisent du code à partir d’un cahier des charges précis. Ils se préoccupent peu des impacts que peut avoir leur code sur la production. De la même façon, les équipes de production sont quant à elles obnubilées par la stabilité de l’infrastructure, garante de la création de valeur pour les métiers. Elles freinent donc les mises en production et blâment le code du développeur si le résultat voulu par l’utilisateur n’est pas satisfaisant. La vision DevOps tente de pallier à ce problème en favorisant une répartition des responsabilités et l’implication de l’ensemble des acteurs de la chaine. Le développeur devient ainsi testeur de son code.

Les intérêts d’adoption d’une démarche Devops sont multiples :

  • Réduire le cycle et le coût de mise en production,
  • Avoir une approche plus fragmentée (petites évolutions),
  • Faire que les mises à jour deviennent transparentes,
  • Mise en commun des responsabilités (tout le monde dans le même bateau!)
  • Une amélioration continue du produit,
  • Répondre plus rapidement aux besoins des clients.

NETFLIX, Amazon, Singapore Power ont été conquis par DevOps

Eh oui, même les plus grands ont adopté Devops ! Des entreprises telles que Netflix ou Amazon ont bâti une bonne partie de leur succès en s’appuyant DevOps.

Cycle de vie DevOpsChez Netflix, par exemple, le déploiement est totalement automatisé, depuis le packaging du nouveau code jusqu’à la mise en production. Cela passe par la mise en oeuvre de l’infrastructure virtuelle et les tests fonctionnels. Une nouvelle version d’application sera promue automatiquement dans une nouvelle infrastructure virtuelle. Elle est mise en service en lui redirigeant un sous-ensemble du trafic utilisateur. Après une phase pilote avec monitoring automatisé, si le comportement s’avère satisfaisant, la totalité du trafic est redirigé. L’ancienne instance de l’application et son infrastructure sont alors automatiquement décommissionées.

Vous souhaitez en savoir plus sur DevOps?

DevOps est désormais accessible en Afrique. Laissez vous tenter par cette révolution. Faites partie des premiers à satisfaire enfin le besoin d’agilité tant attendue par le Business. Grâce à DevOps vos équipes informatiques pourront concevoir et déployer des applications plus rapidement. Elles travailleront de manière efficace et efficiente, s’adapteront facilement au changement, développeront de meilleurs logiciels. Dernier avantage non négligeable, DevOps vous permettra d’optimiser les coûts. Une mise en œuvre parfaite de DevOps est essentielle et nécessite des professionnels expérimentés dans le domaine. C’est pourquoi AB Consulting, seul organisme officiellement accrédité en Afrique, vous aide à comprendre et à mettre en œuvre DevOps dans votre Organisation. Nous vous accompagnons également dans la conduite du changement culturel au sein de vos équipes. Pour plus d’informations sur nos prochaines formations DevOps Foundation, consultez notre site.

N’hésitez pas à nous adresser vos commentaires et vos questions qui seront les bienvenues pour que s’instaure un dialogue fructueux autour de la révolution DevOps.

Catégories

Archives

Calendrier

janvier 2019
L M M J V S D
« Déc    
 123456
78910111213
14151617181920
21222324252627
28293031  
%d blogueurs aiment cette page :