En tant qu'ingénieur DevOps issu du monde des opérations, vous passerez de la création et du déploiement manuels de serveurs et de logiciels à la création de scripts pour l’installation de logiciels sur vos serveurs, tels que BASH, PowerShell, Python, etc. Les scripts sont cool et commencent à explorer des moyens plus sophistiqués d’ automatiser le déploiement .
Finalement, vous auriez opté pour un outil de gestion de la configuration Chef, Puppet, Ansible ou autre pour vous aider à gérer l’état de votre parc de systèmes. Au fur et à mesure que vos compétences en matière d'automatisation du déploiement d'applications et de gestion de système mûrissaient, ainsi que vos outils, vous êtes récemment entré dans le domaine de « Infrastructure as Code » et vous l'utilisez non seulement pour automatiser le déploiement de logiciels, mais également pour l'infrastructure et les environnements requis. piloter le logiciel lors du passage de l’entreprise au nuage.
Maintenant, vous cuisinez au gaz. Au fil du temps, vous avez découvert les avantages liés à l'utilisation d'outils centrés sur les développeurs, tels que le contrôle de source, pour gérer les modules, les recettes et les modèles constituant votre arsenal d'outils de déploiement et de gestion.
Lorsque vous avez rejoint l' équipe de DevOps , vous avez été initié au cycle de vie du développement logiciel et au concept d' intégration continue . Mais ces développeurs publiaient les changements rapidement et pour continuer, tu travaillais plus étroitement avec les développeurs! Vous avez vécu l'urgence imposé à l'équipe de développement de changer TOUT TEMPS, ce qui va à l'encontre du vieux paradigme opérationnel du " si ce n'est pas cassé, ne le répare pas ". Plus besoin de vous vanter de la disponibilité du système, vous êtes dans une infrastructure jetable .
Vous avez remarqué que le passage à DevOps était plus que travailler avec les développeurs , ou utiliser de nouveaux outils et techniques , mais il y avait un changement culturel distinct dans l'équipe, un changement qui a touché l'ensemble de l'organisation. Vous travailliez comme une équipe soudée avec des responsabilités partagées , un outillage partagé et des objectifs partagés .
Vous avez utilisé vos compétences en déploiement automatisé et les avez intégrées au pipeline " CICD " orchestré par un " serveur d'intégration continue " comme Jenkins , Bamboo ou Code Pipeline . Maintenant, lorsque les développeurs poussent du nouveau code, vos scripts, outils et modèles créent de nouveaux environnements à la demande, incitent les frameworks de test à faire leur travail et suppriment les environnements de pré-production une fois que les voyants verts sont allumés, en respectant les idées de " livraison continue ".
Au fur et à mesure que le nouveau code se fraye un chemin à travers les étapes CICD, vous, les développeurs et les entreprises, êtes convaincus que la mise à jour ne se brisera pas lorsqu'elle sera mise en production. Il reste encore du chemin à parcourir avant que l’équipe ne passe au « déploiement continu ». Vous devez encore vous contenter des détails de l’automatisation de la capacité de déploiement bleu / vert , et la décision est essentiellement commerciale. Pour le moment, vous êtes satisfait du fait que le nombre d'appels à 3h du matin a diminué et que les sev-1 et les sev-2 ont diminué.
Même si vous obtenez un sev-1, vous ne tirez plus toute la nuit de sommeil avec les gérants. Vous pouvez facilement publier la version précédente via le pipeline CICD et remettre le système en ligne rapidement. L’entreprise a constaté que la stabilité des systèmes informatiques s’était améliorée malgré la rapidité des changements .
Vous vous émerveillez de la façon dont vous gérez les ressources nécessaires à la gestion du logiciel dans votre entreprise, en particulier lorsque vous repensez à son état actuel et à la quantité de sang que vous avez laissée sur des rails dans le centre de données ...
