Python >> Tutoriel Python >  >> Python

DevOps, livraison continue... et vous

Ce billet de blog contient les diapositives ainsi qu'une transcription libre et des ressources supplémentaires de mon exposé technique sur les concepts de DevOps et de livraison continue donné à mon alma mater, l'Université de Virginie, au M.S. dans le programme de gestion des technologies de l'information les 2 et 4 novembre 2017.

Des liens pour en savoir plus sur les concepts présentés dans cette conférence se trouvent dans la barre latérale et au bas de cette page.


Salut les amis, je m'appelle Matt Makai. Je suis développeur de logiciels chez Twilio et créateur de Full Stack Python, que plus de 125 000 développeurs lisent chaque mois pour apprendre à créer, déployer et exploiter des applications basées sur Python.

Vous avez parlé d'utiliser la méthodologie de développement logiciel Agile dans vos équipes, mais à quoi ça sert ? Pourquoi le développement Agile est-il important pour vous et votre organisation ?

Agile est important car il vous permet d'expédier plus de code, plus rapidement que les approches traditionnelles de la méthodologie "en cascade".

L'expédition est une allégorie courante dans le développement de logiciels de nos jours, car un code qui n'est pas en production, entre les mains de vos utilisateurs, ne crée de valeur pour personne.

Si le code ne s'exécute pas en production, il ne crée pas de valeur. Le nouveau code créé par vos équipes de développement Agile toutes les deux semaines ne crée pas plus de valeur tant qu'il n'est pas exécuté en production.

Le code d'expédition est si important pour les entreprises performantes que le thème maritime est utilisé dans toutes sortes de projets, y compris dans le Dockerlogo.

Ainsi que dans le logo Kubernetes sous la forme d'un volant de navire.

Voici un diagramme de très haut niveau du scénario idéal dont nous avons besoin pour les équipes de développement Agile. Créez un code fonctionnel et envoyez-le dès que possible en production.

La devise interne de Facebook était "Allez vite et cassez des choses". Ils pensaient que si vous ne cassiez pas de choses, vous ne bougez pas assez vite.

Et éventuellement, si vous expédiez constamment à la production et que vous ne disposez pas des processus et outils appropriés, votre les applications se cassent. La rupture n'a rien à voir avec la méthodologie Agile elle-même.

Votre équipe et votre organisation arriveront à un carrefour lorsque vous vous retrouverez avec un environnement brisé.

Traditionnellement, les organisations ont tenté de prévenir les bris en mettant en place davantage d'outils et de processus manuels. Le travail manuel ralentit... votre... capacité... à... exécuter.

C'est un chemin fourni par la bifurcation de la route. Mettez en place vos "comités d'examen d'EnterpriseChange". Exigez l'approbation de la production par un vice-président exécutif qui n'a jamais écrit une seule ligne de code de sa vie. Rassemblez plusieurs dizaines d'« architectes techniques » dans une pièce pour discuter de la personne qui déploiera leurs modifications en production ce mois-là.

Le chemin manuel est une folie. Finalement, les meilleurs développeurs de votre organisation seront frustrés et partiront. Les dirigeants se demanderont pourquoi rien n'est jamais fait. Pourquoi faut-il trois ans à notre organisation pour apporter une petite modification à une application critique ?

Certaines équipes de développement tentent de contourner les défis de la production manuelle en expédiant tout dans un environnement de développement. L'environnement de développement est sous leur contrôle.

Mais quel est l'énorme problème flagrant dans cette situation ?

Si vous n'expédiez pas en production, vous ne créez aucune valeur pour vos utilisateurs. Les équipes ont pris une décision rationnelle de passer au développement, mais l'organisation souffre toujours des contrôles manuels.

Les problèmes dont nous parlons sont créés par la méthodologie Agile car ils deviennent aigus lorsque votre équipe de développement produit du code à haute rapidité. Une fois le code créé plus rapidement, vous avez besoin d'un moyen de le mettre en production de manière fiable et cohérente afin qu'il puisse créer de la valeur pour ses utilisateurs.

DevOps et livraison continue sont les termes généraux qui englobent la façon d'expédier de manière fiable le code à la production et de l'exploiter lorsque le code est exécuté en production.

Nous allons beaucoup utiliser les termes "DevOps" et "Livraison Continue" aujourd'hui, alors commençons par définir ce qu'ils signifient. En fait, le terme "DevOps" a déjà accumulé beaucoup de mots à la mode, nous allons donc commencer par définir ce que DevOps n'est pas .

Premièrement, DevOps n'est pas un nouveau rôle. Si vous allez embaucher un groupe de personnes et les appeler "ingénieurs DevOps", puis les asseoir au milieu de vos développeurs et de vos administrateurs système/ops, vous allez passer un mauvais moment. Vous venez d'ajouter un nouveau calque entre les deux groupes que vous devez rapprocher.

Deuxièmement, DevOps n'est pas un outil ou une application spécifique. Vous n'avez pas besoin d'utiliser Docker ou Puppet pour faire du DevOps dans votre organisation. Les processus qui font fonctionner DevOps sont beaucoup plus faciles grâce à certains outils tels que les plates-formes cloud où l'infrastructure est transitoire, mais même ces plates-formes ne sont pas obligées de faire correctement DevOps.

Troisièmement, DevOps n'est pas lié à un écosystème de langage de programmation spécifique. Vous n'avez pas besoin d'utiliser Node.js ou Ruby on Rails. Vous pouvez toujours utiliser DevOps dans une organisation COBOL ou J2EE uniquement.

Ces idées fausses étant écartées, parlons de ce qu'EST DevOps. trop évident, DevOps est la combinaison des deux mots Développement et Opérations. Cette combinaison n'est pas un appariement aléatoire, c'est un terme intentionnel.

Deuxièmement, DevOps signifie que vos développeurs d'applications gèrent les opérations. Pas nécessairement tous les opérations fonctionnent, mais les opérations fonctionnent avec le code qu'elles écrivent et déploient dans le cadre de leurs sprints. Les développeurs se familiariseront également très probablement avec l'infrastructure sous-jacente, telle que les serveurs d'applications Web, les serveurs Web et le code de déploiement des outils de gestion de la configuration.

Troisièmement, DevOps permet à votre organisation d'être plus efficace dans la gestion des problèmes en s'assurant que la bonne personne gère les erreurs et les échecs d'application.

Nous n'allons pas passer par la livraison continue (CD) en définissant ce que ce n'est pas, mais il y a quelques peu à dire à ce sujet. Premièrement, le CD est un ensemble de pratiques d'ingénierie visant à automatiser la livraison du code depuis l'enregistrement du contrôle de version jusqu'à son exécution dans un environnement de production.

L'avantage de l'approche CD d'automatisation est que votre organisation aura une bien plus grande confiance dans le code exécuté en production, même si le code lui-même change plus fréquemment à chaque déploiement.

La devise originale de Facebook a changé il y a quelques années en "Move Fast and BuildThings" parce qu'ils ont réalisé que briser la production n'était pas un sous-produit de la rapidité, c'était le résultat de processus et d'outils organisationnels immatures. DevOps et la livraison continue sont la raison pour laquelle les organisations peuvent désormais déployer des centaines ou des milliers de fois en production chaque jour, mais ont une confiance croissante, et non décroissante, dans leurs systèmes à mesure qu'ils continuent d'évoluer plus rapidement.

Examinons quelques exemples de scénarios qui expliquent en quoi consistent DevOps et CD, et apprenons-en davantage sur certains des processus, concepts et outils qui relèvent de ce domaine.

Voici une belle photo du soir de la ville dont je viens de m'éloigner, SanFrancisco.

La société pour laquelle je travaille, Twilio, est située à San Francisco. Si jamais vous atterrissez à l'aéroport SFO et faites un tour en direction du centre-ville, vous verrez notre panneau d'affichage sur le côté droit de la route.

Twilio permet aux développeurs de logiciels d'ajouter facilement des communications, telles que les appels téléphoniques, la messagerie et la vidéo, dans leurs applications. Nous sommes une entreprise de télécommunications construite avec la puissance d'un logiciel qui élimine le besoin pour les clients d'acheter tout le matériel hérité coûteux qu'ils devaient acquérir. En tant qu'entreprise de télécommunications, nous ne pouvons jamais tomber en panne, ou nos clients sont arrosés, puis notre entreprise est arrosée.

Cependant, nous avons rencontré des défis dans notre histoire qui nous ont obligés à faire face à la bifurcation entre les processus manuels et à aller plus vite via la confiance dans notre automatisation.

En août 2013, Twilio a fait face à une panne d'infrastructure.

Tout d'abord, un peu de contexte. Lorsqu'un développeur s'inscrit à Twilio, il place un crédit sur son compte et le crédit est utilisé en passant des appels téléphoniques, en envoyant des messages, etc. Lorsque le crédit est faible, nous pouvons recharger votre carte afin que vous obteniez plus de crédit.

Il y a eu un problème de production majeur avec les frais récurrents en août 2013. Nos ingénieurs ont été alertés des erreurs et du problème a explosé en haut de Hacker News, attirant l'attention générale.

Alors maintenant il y a une grosse erreur de production... on fait quoi ?

(Note du lecteur :cette section est principalement une discussion avec le public basée sur leur propre expérience dans la gestion de ces situations techniques difficiles.)

Une étape consiste à déterminer quand le problème a commencé et s'il est résolu ou non. Si ce n'est pas fini, triez les problèmes spécifiques et commencez à communiquer avec les clients. Soyez aussi précis et transparent que possible.

Le problème technique spécifique dans ce cas était dû à notre mauvaise configuration des instances Redis.

Nous savons que la défaillance technique particulière était due à notre mauvaise gestion de Redis, mais comment pouvons-nous regarder au-delà du bit spécifique et obtenir une meilleure compréhension des processus à l'origine du problème ?

Examinons la résolution de la situation, puis découvrons les concepts et les outils qui pourraient prévenir de futurs problèmes.

Dans ce cas, nous avons communiqué avec nos clients autant que possible sur le problème. En tant qu'entreprise axée sur les développeurs, nous avons eu la chance qu'en étant transparents sur le problème technique spécifique, nombre de nos clients aient gagné en respect pour nous, car ils avaient également été confrontés à des erreurs de configuration similaires dans leur propre environnement.

Twilio est devenu plus transparent avec l'état des services, notamment en affichant les pannes partielles et les pannes.

Twilio a également délibérément évité l'accumulation de processus manuels et de contrôles que d'autres organisations mettent souvent en place après des échecs. Nous avons doublé notre résilience grâce à l'automatisation pour augmenter notre capacité de déploiement en production.

Quels sont les outils et concepts que nous utilisons chez Twilio pour prévenir les futurs scénarios d'échec ?

Si vous ne disposez pas des bons outils et processus, vous finirez par vous retrouver avec un environnement de production défectueux après l'expédition code. Quel outil pouvons-nous utiliser pour être sûr que le code mis en production n'est pas cassé ?

Les tests automatisés, sous leurs nombreuses formes, telles que les tests unitaires, les tests d'intégration, les tests de sécurité et les tests de performances, aident pour garantir l'intégrité du code. Vous devez automatiser car les tests manuels sont trop lents.

D'autres outils importants qui entrent dans le compartiment des tests automatisés mais qui ne sont pas traditionnellement considérés comme un "cas de test" incluent la couverture du code et les métriques de code (telles que la complexité cyclomatique).

Génial, maintenant vous ne déployez en production que lorsqu'un gros lot de cas de test automatisés garantit l'intégrité de votre code. Tout va bien, non ?

Euh, eh bien non. Des choses peuvent encore casser en production, en particulier dans des environnements où, pour diverses raisons, vous n'avez pas les mêmes données exactes en test qu'en production. Vos tests automatisés et vos métriques de code ne détecteront tout simplement pas tous les scénarios qui pourraient mal tourner en production.

Lorsque quelque chose ne va pas avec votre application, vous avez besoin d'une surveillance pour savoir quel est le problème et d'une alerte pour dire le bon gens. Traditionnellement, les "bonnes" personnes étaient dans les opérations. Mais au fil du temps, de nombreuses organisations ont réalisé que les opérateurs finissaient par appeler les développeurs d'applications d'origine qui avaient écrit le code qui posait problème.

Un élément essentiel de DevOps consiste à s'assurer que les développeurs appropriés transportent les téléavertisseurs. Ça craint de porter le téléavertisseur et de se réveiller au milieu de la nuit, mais c'est beaucoup plus facile de déboguer le code que votre équipe a écrit que si vous êtes une personne aléatoire qui n'a jamais vu le code auparavant dans sa vie.

Un autre sous-produit du fait que les développeurs d'applications transportent les "pagers" pour les alertes sur les problèmes de production est qu'au fil du temps, le code qu'ils écrivent est plus défensif. Les erreurs sont gérées de manière plus appropriée, car sinon vous savez que quelque chose vous explosera plus tard à un moment moins opportun.

En règle générale, vous constatez qu'il existe encore de nombreuses erreurs de production, même lorsque vous avez un code défensif en place avec une énorme bande des parties les plus importantes de votre base de code étant constamment testées.

C'est là qu'un concept appelé "ingénierie du chaos" peut entrer en jeu. L'ingénierie du chaos casse des parties de votre environnement de production sur un horaire et même sur une base non planifiée. Il s'agit d'une technique très avancée - vous n'allez pas la vendre dans un environnement qui n'a pas de couverture de test automatisée existante ni de contrôles appropriés en place.

En introduisant délibérément des échecs, en particulier pendant la journée lorsque votre équipe bien caféinée peut résoudre les problèmes et mettre en place des mesures de protection supplémentaires , vous rendez votre environnement de production plus résilient.

Nous avons parlé il y a plusieurs années de l'échec de l'infrastructure de paiement de Twilio qui nous a finalement conduits à devenir plus résistants à l'échec en mettant en place automatisation en place.

Discutons d'un scénario où des vies humaines étaient en jeu.

Pour être explicite sur ce prochain scénario, je ne parlerai que d'informations publiques, afin que mes amis autorisés dans le public puissent se détendre.

Au plus fort de la poussée des forces américaines en Irak en 2007, plus d'engins explosifs improvisés tuaient et mutilaient des soldats et des civils que jamais auparavant. C'était une tragédie incroyable qui a contribué à l'incertitude de l'époque dans le pays.

Cependant, les efforts en matière de biométrie ont été une partie du puzzle qui a permis d'empêcher davantage d'attaques, comme le montre cette image de Rapport du général Petraeus au Congrès.

L'un des principaux défis du projet était un terrible processus de construction manuelle qui impliquait littéralement de cliquer sur des boutons dans un environnement de développement intégré pour créer l'application artefacts. Le processus était trop manuel et le résultat final était que la dernière version du logiciel prenait beaucoup trop de temps pour entrer en production.

Nous n'avions pas de déploiements automatisés dans un environnement de développement, de préproduction ou de production.

Notre équipe devait commencer quelque part, mais faute d'outils approuvés, nous n'avions à notre disposition que des scripts shell . Mais les scripts shell étaient un début. Nous avons pu créer un processus de déploiement automatisé très fragile mais reproductible dans un environnement de développement ?

Il reste cependant un énorme problème flagrant :tant que le code n'est pas réellement déployé en production, il n'apporte aucune valeur aux utilisateurs.

Dans ce cas, nous ne pourrions jamais entièrement automatiser le déploiement car nous devions graver sur un CD avant de passer physiquement à un réseau informatique différent. L'équipe pouvait cependant automatiser à peu près tout le reste, et cela importait vraiment pour l'itération et la vitesse de déploiement.

Vous faites de votre mieux avec les outils à votre disposition.

Quels sont les outils et concepts derrière l'automatisation des déploiements ?

Le code source est stocké dans un référentiel de contrôle de source (ou de contrôle de version). Le contrôle de source est le début du processus d'automatisation , mais de quoi avons-nous besoin pour intégrer le code dans divers environnements à l'aide d'un processus reproductible et automatisé ?

C'est là qu'intervient l'intégration continue. L'intégration continue extrait votre code du système de contrôle de version, le construit, le teste et calcule les métriques de code appropriées avant que le code ne soit déployé dans un environnement.

Nous avons maintenant un serveur d'intégration continue connecté au contrôle de source, mais cette image semble toujours étrange.

Techniquement, l'intégration continue ne gère pas les détails de la construction et comment configurer les environnements d'exécution individuels.

Les outils de gestion de configuration gèrent la configuration du code d'application et des environnements.

Ces deux scénarios ont fourni un certain contexte pour expliquer pourquoi DevOps et ContinuousDelivery sont importants pour les organisations de divers secteurs. Lorsque vous avez des équipes performantes travaillant via la méthodologie de développement Agile, vous rencontrerez un ensemble de problèmes qui ne peuvent être résolus en faisant « mieux » Agile. Vous avez besoin des outils et des concepts dont nous avons parlé aujourd'hui ainsi que d'un grand nombre d'autres pratiques d'ingénierie pour mettre ce nouveau code en production.

Les outils et concepts que nous avons abordés aujourd'hui étaient les tests automatisés, la surveillance, l'ingénierie du chaos, l'intégration continue et la gestion de la configuration.

Il existe de nombreuses autres pratiques dont vous aurez besoin tout au long de votre voyage. Vous pouvez toutes les découvrir sur Full Stack Python.

C'est tout pour aujourd'hui. Je m'appelle Matt Makai et je suis développeur de logiciels chez Twilio et auteur de Full Stack Python. Merci beaucoup.


Des ressources supplémentaires pour en savoir plus sur les sujets suivants sont disponibles sur leurs pages respectives :

  • Déploiements
  • Intégration continue
  • Informatique sans serveur
  • AWS Lambda
  • Générateurs de sites statiques
  • Surveillance
  • DevOps
  • Gestion des configurations
  • Plate-forme en tant que service (PaaS)
  • Docker
  • Sécurité des applications Web
  • Test
  • Contrôle de la source
  • Git
  • Métriques de code
  • NoSQL