Mise en place du DevOps
Changer la façon dont le logiciel arrive en production : des changements plus petits, livrés plus souvent, avec un retour arrière plutôt qu'un espoir.
Aperçu
Le DevOps est un mode de travail, pas une boîte à outils. Installer les outils sans changer la façon de travailler donne les mêmes grandes livraisons mensuelles avec de meilleurs journaux, ce qui ne change pas grand-chose pour ceux qui traitent l'incident la nuit.
Le changement est simple à énoncer et inconfortable à mettre en œuvre : des modifications plus petites, livrées plus souvent, testées automatiquement, avec un retour arrière que quelqu'un a déjà exécuté pour de vrai. Cela réduit le risque par livraison, parce qu'il y a moins de choses en vol à la fois.
À qui cela s'adresse
- Équipes qui livrent rarement et avec un risque élevé
- Entreprises dont les déploiements demandent des étapes manuelles et une liste de contrôle
- Organisations sans chemin de retour arrière éprouvé
Notre approche de Mise en place du DevOps
Les travaux précis que couvre une mission type. Le périmètre est convenu d'avance : rien ici ne réapparaîtra plus tard comme une ligne surprise.
État des lieux
Comment on livre aujourd'hui, combien de temps cela prend, ce qui se fait à la main et ce qui a mal tourné récemment.
Déploiement automatisé
Le déploiement comme opération reproductible plutôt qu'une suite d'étapes qu'une personne connaît de mémoire.
Infrastructure décrite en code
Des environnements définis plutôt que configurés à la main, pour que test et production se ressemblent réellement.
Environnements
Des environnements séparés avec des données réalistes, un test contre une base vide n'apprenant pas grand-chose.
Retour arrière
Un chemin de retour éprouvé. Un retour arrière jamais exécuté est une hypothèse, pas un plan.
Astreinte et passation
Qui est appelé en cas d'incident, dans quel ordre, et ce que cette personne trouve en se connectant.
Du premier échange au résultat mesuré
Toujours la même séquence, pour que vous sachiez ce qui vient ensuite.
Relever
Décrire le chemin actuel du commit à la production, avec les durées et les gestes réels.
Automatiser
Remplacer les étapes manuelles, en commençant par celles qui produisent le plus d'erreurs.
Accélérer le rythme
Passer à des livraisons plus petites et plus fréquentes, ce qui réduit le risque par livraison au lieu de l'augmenter.
Répéter
Exécuter le retour arrière et la procédure d'incident avant d'en avoir besoin sous pression.
Des résultats, pas des livrables
Un empilement de documents n'est pas un progrès. Voici les changements que le travail doit produire.
Moins de risque par livraison
Quand peu de choses partent à la fois, la cause d'un incident se trouve en minutes plutôt qu'en heures.
Un retour arrière qui marche
Avoir répété le retour sépare une courte interruption d'une longue soirée.
Des environnements comparables
Une infrastructure décrite met fin à la classe de bugs qui n'apparaissent qu'en production.
Moins de dépendance aux personnes
Un processus automatisé signifie que livrer ne dépend pas de qui est en vacances.
Questions fréquentes sur Mise en place du DevOps
Ce qu'on nous demande avant de nous contacter. Si votre question n'y est pas, posez-la nous directement.
Livrer plus souvent n'augmente-t-il pas le risque ?
C'est l'inverse. Le risque croît avec la quantité de changement par livraison, pas avec le nombre de livraisons. Dix petites livraisons se vérifient et se reprennent une par une, alors qu'une grande livraison mensuelle contient des dizaines de modifications dont aucune n'est identifiable comme cause en cas d'incident.
Faut-il recruter des profils DevOps dédiés ?
Pas nécessairement, et pour une petite équipe c'est souvent la mauvaise réponse. Ce qu'il faut est un processus automatisé que les développeurs utilisent eux-mêmes. Un rôle dédié se justifie à partir d'une taille où le travail de plateforme est une activité permanente.
Combien de temps pour la transition ?
Des améliorations sensibles en quatre à huit semaines, généralement l'automatisation du déploiement et un retour arrière fiable. Le passage à des livraisons réellement petites prend plus longtemps, parce qu'il touche aux habitudes et non aux outils.
Et si nous sommes fortement réglementés ?
La réglementation exige de la traçabilité et des validations, pas des livraisons rares. Un processus automatisé avec validations journalisées répond généralement mieux aux exigences d'audit qu'un processus manuel, parce que chaque étape est documentée et reproductible.
Vous réfléchissez à Mise en place du DevOps ?
Dites-nous ce que vous cherchez à changer. Si nous ne sommes pas les bons interlocuteurs, nous vous le dirons et vous orienterons ailleurs.
Vous cherchez la vue d'ensemble ?
Mise en place du DevOps accompagne généralement d'autres travaux en DevOps, infrastructure et exploitation technique. Parcourez tout le domaine pour voir les liens.