Comment automatiser les déploiements de production sans ressentir une anxiété extrême?

Dans notre boutique, nous utilisons SVN pour le contrôle des sources et CruiseControl pour CI pour la gestion des builds et des déploiements automatiques dans nos environnements de développement, de test et d'intégration.

Tout cela fonctionne bien, mais en raison de contraintes matérielles et de ressources, notre environnement d'intégration n'est pas un environnement à charge équilibrée pour 2 serveurs comme notre environnement de production. Alors que tout le reste est égal, ce serait la seule différence entre nos environnements d'intégration et de production (bien que grand!)

Théoriquement, la différence est une configuration légèrement différente de nos serveurs d'applications et le script de déploiement devrait simplement déposer les artefacts de génération sur deux serveurs au lieu d'un seul, mais pourquoi suis-je si nerveux d'automatiser nos déploiements de production?!

Je ne suis généralement pas un maniaque du contrôle mais je ressens toujours le besoin insatiable de déployer la production en production manuellement. J'ai entendu des collègues dire que c'est généralement une chose vraiment méchante ™, mais ils n'ont pas réussi à plaider contre.

Je sais que lorsque je le fais manuellement, je peux VOIR que je copie physiquement les fichiers corrects, j'arrête physiquement les serveurs d'applications et je m'assure qu'ils se sont fermés avec succès, je démarre physiquement les serveurs de sauvegarde et inspecte ensuite physiquement les journaux à faire sûr qu'il a bien démarré et que le déploiement a réussi. Cela me donne une tranquillité d'esprit.

Quels sont les arguments contre ces arguments OR pour le déploiement automatique de la production par script?

Il y a quelques arguments évidents contre cela.

1. Que se passe-t-il si vous partez. Toutes ces informations sont-elles soigneusement documentées, ou sont-elles principalement dans votre tête? Les scripts automatisés sont un bien meilleur endroit pour que quelqu'un d'autre prenne le relais.

2. Tout le monde fait des erreurs. Il arrivera un moment où la personne qui fait le déploiement est fatiguée et ne fait plus attention. Oui, idéalement, les déploiements ne se font que dans un endroit calme et heureux avec beaucoup de temps. Dans la pratique, ils peuvent être précipités et stressés lorsqu'ils tentent de déployer des correctifs urgents. C'est le moment le plus probable pour commettre une erreur, mais aussi le plus coûteux. Si le déploiement est un script unique, le risque d'erreurs est limité.

3. Temps. Au fur et à mesure que les déploiements se compliquent, la quantité à faire augmente. Les scripts nécessitent simplement un coup d'envoi, une vérification manuelle, puis une commutation manuelle (vous pouvez également automatiser cela, mais je partage une partie de la paranoïa :)).

Vous pouvez obtenir le meilleur des meilleurs mondes: la tranquillité d'esprit avec la vérification des processus et la fiabilité de l'automatisation.

Scriptez le déploiement. Ensuite, parcourez et vérifiez manuellement que les processus sont démarrés, les fichiers supprimés, etc. En d'autres termes, écrivez votre propre script QA juste pour vérifier que les étapes automatisées 1 à X se sont réellement produites.

Je pense que la clé ici est: pourquoi pensez-vous que vous ne pouvez pas écrire le processus de vérification?

Mes scripts de déploiement ne se contentent pas de pousser les archives et de redémarrer les services. Ils impriment de nombreuses informations codées par couleur à chaque étape du déploiement et me fournissent un résumé des événements à la fin. Cela me permet de savoir que les processus sont en cours d'exécution, que la page d'accueil sert un code d'état 200 et que toutes les machines et tous les services peuvent bien se voir. J'ai ensuite un service distinct qui ne fait pas partie du script qui surveille les fichiers journaux, les erreurs de niveau 4xx et 5xx et les mesures clés du site. Il continue ensuite à me crier sur tous les supports possibles (email, msg txt et alarmes) s'il y a des pics d'effet négatif drastiques.

Entre cela et les serveurs CI exécutant des tests, je déploie et oublie littéralement à ce niveau d'automatisation. Je ne navigue même pas sur une seule page du site après une poussée en raison de la fiabilité du processus, ce qui me permet non seulement de déployer aussi souvent que je le souhaite, mais permet à un nouveau développeur sur le projet de mettre à jour le live site dans les minutes suivant son arrivée à bord. Dans le passé, j'ai même fait en sorte que les serveurs CI se déploient automatiquement en production après un commit dans une branche master / trunk qui passe tout. Voilà à quel point je suis confiant dans mes outils.

Tu devrais l'être aussi.

Exécutez-vous également vos machines de production avec le débogage à distance et les parcourez-vous manuellement? La construction d'un script approprié est identique à l'écriture d'un programme. Tous les problèmes que vous rencontrez indiquent des éléments qu'il devra surveiller et vérifier.

Si quelque chose ne va pas, il devrait suivre les procédures de restauration appropriées et vous envoyer un message. Tout ce qui se passe peut être enregistré pour plus tard. Vous pouvez contrôler la version des scripts et configurer des cas de test.

Mais si vous exécutez manuellement des commandes, vous n'avez aucun de ces avantages. Vous avez plutôt une liste d'inconvénients.

• Vous n'avez pas un bon journal, l'historique du shell ne compte pas
• Personne d'autre ne sait comment le faire
• Les étapes sont manquées
• Les contrôles ne sont que parfois effectués
• Certains éléments à déployer peuvent être manqués, je l'ai déjà fait auparavant
• Cela prend beaucoup plus de temps
• Vous pouvez être interrompu pendant le processus

Un script correct devrait être presque identique à si vous avez tout tapé sur le shell. C'est l'une des raisons pour lesquelles nous avons des scripts bash. Si vous faites confiance à ce que vous faites, pourquoi ne pouvez-vous pas tout enregistrer et le resserrer? Une meilleure vérification, une vérification plus rapide, plus de vérification peuvent se produire parce que l'ordinateur le fait.

Je peux comprendre être un peu nerveux en essayant quelque chose de nouveau sur l'environnement de prod. Méfier d'une catastrophe potentielle est une bonne chose ^TM .

Les scripts automatisés sont également une bonne chose ^TM et tant que vous vous en approchez soigneusement, vous devriez être en mesure de minimiser le danger et de réduire votre peur. Donc, mon conseil est le suivant;

• Préparez (et pratiquez sur l'intégration) une liste de contrôle / ensemble de tests afin de savoir rapidement si cela a fonctionné et si quelque chose s'est mal passé. La journalisation détaillée peut aider à cela.
• Sauvegardez tout. Préparez et pratiquez une restauration manuelle afin de pouvoir récupérer en cas de problème.
• Testez autant que vous le pouvez avant de le faire pour de vrai sur prod. On dirait que vous êtes un bon moyen avec cela avec votre environnement d'intégration.
• La première fois que vous l'essayez, faites-le sur un profil bas et à faible impact. Quelque chose comme une mise à niveau ou un correctif mineur. L'idée est de minimiser les retombées en cas de problème. Ne choisissez pas une mise à niveau majeure de haut niveau (où le PDG et tous vos concurrents regardent) pour votre première course.

Une fois que vous avez réussi quelques runs sous votre ceinture, votre confiance augmentera et bientôt vous vous demanderez comment vous avez réussi à faire des déploiements manuels.

Voici le plus grand argument contre les déploiements manuels en production: vous êtes un humain et vous ferez des erreurs. Il y aura sans aucun doute des moments où vous oublierez de faire quelque chose qui vous causera du chagrin. Un déploiement automatisé bien écrit n'a pas la même tendance. Il est vrai que vous pouvez toujours avoir des déploiements de production foirés, mais c'est parce que votre déploiement automatisé a des bogues qui doivent être résolus.

D'après mon expérience, les avantages des déploiements automatisés en production sont énormes. Le plus important est que vous puissiez vous amuser le week-end au lieu d'essayer de suivre un processus de déploiement manuel qui ne coopérera pas.

Cela dit, voici quelques conseils clés pour automatiser vos déploiements de production:

• Ne faites pas tout en même temps! Commencez lentement à écrire vos déploiements automatisés. Configurez d'abord un environnement de non-production distinct et essayez d'automatiser les déploiements à cet endroit. Une fois que vous avez gagné en confiance dans vos déploiements automatisés, vous pouvez commencer à penser à faire des déploiements de production
• Commencez à publier et à déployer très fréquemment! Il est beaucoup plus facile de faire des déploiements automatisés lorsque vous n'avez pas 4 mois de code en attente de publication. Libérez de petites fonctionnalités et des corrections de bugs plusieurs fois par semaine. Les avantages de ce style de version ne peuvent être sous-estimés!
• Faites confiance à des tests automatisés pour vous assurer que votre environnement de production fonctionnera. Encore une fois, cela prend du temps à construire, mais c'est très important. Les tests automatisés sont toujours meilleurs que les tests d'acceptation manuels. Bien sûr, les tests d'acceptation manuels sont corrects, mais les tests automatisés peuvent vous aider à savoir si vous devez vous déployer en production ou non. Ils sont la clé qui permet tout ce processus de livraison automatisée et continue. Si vos tests ne réussissent pas, vous savez ne pas déployer en production.

Exécutez les scripts sur le serveur en direct. Cela fonctionnera, et après l'avoir vu fonctionner correctement plusieurs fois, vous serez parfaitement confiant.

Sérieusement, vous êtes plus susceptible de faire des erreurs que le script de déploiement.

Les ordinateurs ne font pas d'erreurs, les gens le font.

Écrivez votre script une fois et vérifiez-le soigneusement, parcourez-le ligne par ligne. Dès lors, vous pouvez être sûr que chaque fois que vous déployez, cela fonctionnera.

Faites-le à la main et vous risquez de faire des erreurs. Peut-être que vous avez écrit, tout ce que vous avez à faire, mais c'est tellement facile de faire une erreur. Vous devez copier tous les fichiers sauf le fichier web.config? Vous pouvez parier qu'un jour vous le remplacerez. Un script ne fera jamais cette erreur.

Comment automatiser les déploiements de production sans ressentir une anxiété extrême?

L'extrême anxiété que vous ressentiriez lors de l'automatisation des déploiements de production est très probablement basée sur deux croyances:

1. Un jour ou l'autre, une étape de déploiement échouera et vous ou un autre être humain pourrez récupérer rapidement de l'échec alors qu'un script automatisé pourrait l'ignorer.

2. Un échec négligé de la production a des conséquences dramatiques.

Il n'y a rien que l'on puisse faire à propos de 2., en plus d'éviter les échecs, alors concentrons-nous sur 1.

Une solution bon marché en légère amélioration par rapport à l'existant serait d'utiliser une procédure de déploiement semi-automatique, en attente de validation à la fin de chaque étape de l'installation. Avec une solution semi-automatique, vous bénéficierez des avantages d'une solution entièrement automatique, comme la cohérence et la reproductibilité, tandis que vous aurez toujours la possibilité de surveiller les progrès et de récupérer des erreurs comme vous en avez actuellement l'habitude.

Le script semi-automatisé et son biotope (tests de régression, etc.) pourraient également servir de véhicule pour les connaissances que vous collectez sur les défaillances qui se produisent dans la procédure d'installation et les moyens de s'en remettre.

Ce que j'aime, c'est que vous pouvez tester le déploiement sur le transfert ou le contrôle qualité et savoir que lorsque vous l'exécutez sur prod, les mêmes étapes se produiront.

Lorsque vous le faites manuellement, il est plus facile d'oublier une étape ou de la faire dans le désordre.

... en raison de contraintes matérielles et de ressources, notre environnement d'intégration n'est pas un environnement à charge équilibrée pour 2 serveurs comme notre environnement de production. Alors que tout le reste est égal, ce serait la seule différence entre nos environnements d'intégration et de production (bien que grand!)

Étant donné ci-dessus, je serais probablement aussi anxieux que vous.

J'ai déjà examiné et testé un script automatisé qui se déploie sur SLB et mon sentiment est que sans pré-test lors d'une configuration à charge équilibrée, je préférerais faire les choses manuellement.

Outre la configuration de test de type prod, une autre chose qui a eu un impact significatif sur ma tranquillité d'esprit est que le déploiement de prod a été effectué par une autre équipe que des développeurs - par des gars dont le seul travail était de maintenir l'environnement de production.

• Dans l'un des projets, je les aidais au déploiement en tant que représentant de l'équipe de développement. Avant le déploiement, ils examinaient mes instructions et pendant le déploiement, j'étais simplement assis en ligne prêt à consulter si les choses tournaient mal. À l'époque, j'ai appris à apprécier cette séparation .
   
  Non pas qu'ils soient plus rapides (pourquoi le feraient-ils? J'ai testé les déploiements 5x-10x plus souvent qu'eux). La grande différence était au point. Je veux dire, ma tête est toujours chargée par des choses "principales" - codage, débogage, nouvelles fonctionnalités - il y a juste trop de distractions pour se concentrer correctement sur le déploiement. Par opposition à cela, leur activité principale n'était que la maintenance de la production et ils se concentraient sur cela.
   
  C'est incroyable à quel point le cerveau fonctionne mieux lorsqu'il est concentré. Ces gars-là, ils étaient tellement plus attentifs, ils ont fait tellement moins d'erreurs que moi. Ils savaient juste ce truc mieux que moi. Ils m'ont même appris une ou deux choses qui ont facilité mes propres déploiements de tests.

Créez un script de déploiement que vous utilisez pour déplacer votre code dans n'importe quel environnement. Nous utilisons exactement le même processus de déploiement pour déplacer le code vers dev, qa, staging et enfin production. Comme nous déployons plusieurs fois par jour sur le développement et quotidiennement sur le contrôle qualité, nous avons acquis la certitude que les scripts de déploiement sont corrects. Fondamentalement, testez-en l'enfer en l'utilisant souvent.

1. Simplifier. Votre processus de modification doit être des fichiers rsync, exécuter un script SQL, rien de plus.
2. Automatiser.
3. Tester.

La raison de l'automatisation est d'obtenir quelque chose qui peut être testé, reproductible et auquel vous pouvez faire confiance pour fonctionner correctement dans chaque situation attendue.

Vous devez toujours avoir un plan de sauvegarde, comme pour tout changement dans n'importe quel contexte, et il doit également être automatisé.

Vous voudrez toujours observer le processus tel qu'il se produit si l'environnement est vraiment sensible, mais ne le faites jamais manuellement car il ne peut tout simplement pas être reproduit.

Il est tout à fait possible d'utiliser des scripts d'automatisation pour déployer dans des environnements de production. Cependant, pour le faire de manière fiable, vous devez être capable de faire plusieurs choses.

1. Revenez de manière fiable à la version précédente.
2. Obtenez une confirmation positive que le déploiement a été appliqué avec succès et qu'il répond à un trafic valide.
3. Avoir des environnements de développement et d'assurance qualité comparables qui utilisent également les mêmes scripts.

Il y a quelques avantages aux scripts, comme ils ne manqueront jamais une commande parce que c'est 2h du matin, et c'est fatigué.

Cependant, les scripts peuvent échouer et échoueront toujours. Parfois, l'échec est dû à la conception du script, mais il peut également être causé par une panne de réseau ou d'alimentation, un système de fichiers corrompu, un manque de mémoire .....

C'est pourquoi il est important qu'après l'exécution du script, une phase de test définie soit également suivie qui vérifie que le nouveau déploiement est en cours, en cours d'exécution et en gérant les demandes, avant que le trafic en direct ne soit activé.

1. prenez une fenêtre plus grande pour le déploiement la première fois si les choses tournent mal

2. Divisez le processus de déploiement en deux parties. une. Sauvegarde (manuelle) - cela devrait vous donner confiance en cas de problème pendant le déploiement

   b. Déploiement (automatisé)

une fois que vous êtes en mesure de vous déployer en toute confiance pour la première fois. vous pouvez également automatiser le processus de sauvegarde.