Leonardo Brito

Idéalement, les déploiements devraient être petits, concis, facilement réversibles, rapides et avec une empreinte petite ou nulle sur la base de données. Cependant, peu importe à quel point vous êtes génial, parfois c'est tout simplement inaccessible et vous finissez par avoir besoin de déployer quelque chose qui est juste le contraire: gros, désordonné, difficile à revenir en arrière, lentement douloureux et frottant la DB de la mauvaise façon. Si le déploiement gâche une partie critique de votre logiciel, tant pis pour vous.

Mais il existe en fait de nombreuses façons d'aggraver ces situations. Voici quelques points que vous pouvez suivre pour garantir un déploiement cauchemardesque avec des effets secondaires désagréables qui vous hanteront ainsi que vos collègues pour les jours à venir.

1. Ne faites pas de plan

Les plans sont nulles. Ils prennent du temps et des efforts et n'ajoutent aucune nouvelle fonctionnalité à votre logiciel. La planification d'un déploiement nécessite une réflexion approfondie sur ce qu'il doit faire et, plus important encore, sur ce qu'il ne devrait pas faire (mais pourrait le faire). Un bon plan de déploiement est un chemin heureux étape par étape qui est écrit de manière claire et concise, suivi d'une liste de tout ce qui peut arriver. Faire un plan de déploiement, c'est essentiellement essayer de couvrir autant d'angles morts que possible avant d'appuyer sur la gâchette. Mais, bien sûr, vous et votre équipe êtes des ninjas de code ou des artisans de logiciels ou quel que soit le terme le plus hippique de nos jours, et vous n'avez pas besoin d'un plan! Aile-le. Appuyez sur le bouton et résolvez chaque problème qui pourrait survenir de manière ponctuelle. Qu'est-ce qui pourrait mal se passer?

2. Ne planifiez pas de temps d'arrêt

Les temps d'arrêt sont nuls: c'est généralement aux heures impaires, tard dans la nuit ou tôt le matin, lorsque les clients dorment rapidement (et vous aimeriez bien l'être également). Pourquoi prendre la peine de bloquer l'accès public et de rediriger les clients vers une belle "page de maintenance planifiée"? Pourquoi vous offrir, à vous et à votre équipe, la tranquillité d'esprit et un calendrier clair pour travailler si vous pouvez ressentir la ruée de la rupture de la production avec des clients en direct? Le débogage de production est le meilleur type de débogage! Confondez vos clients avec des états incohérents et laissez-les attendre pendant que votre équipe essaie de corriger les bugs qui ont été définitivement corrigés vendredi soir dernier.

3. Ne pas avoir un excellent système de journalisation

Les journaux sont pour les logiciels buggy, vous n'en aurez pas besoin. Pourquoi passer du temps et éventuellement de l'argent avec une excellente plate-forme de journalisation en tant que service (LaaS)? Ayez juste toute votre équipe ssh en production et regarder les queues de journal. Ou, encore mieux, utilisez un terrible LaaS lent, peu fiable et doté d'une interface utilisateur déroutante pour que tout le monde puisse être frustré d'essayer de trouver des erreurs pendant le déploiement.

4. Ne pas avoir de traqueur de bogues

Voir ci-dessus: tout comme les journaux, les suiveurs de bogues sont également boiteux. Votre RP génial n'aura pas de bugs, maintenant, n'est-ce pas? Les régressions ne se produisent jamais sous votre surveillance. En outre, qui a besoin de suivre les exceptions avec une excellente plate-forme de suivi des bogues, rapide et fiable lorsque vous avez des journaux disponibles? N'êtes-vous pas assez pirate pour grep chaque exception qui pourrait être soulevée?

5. Ne pas avoir de serveur de transfert

Les serveurs de transfert représentent un gaspillage de ressources, à la fois en temps et en argent. Quel est l'intérêt d'avoir une copie presque exacte de vos serveurs de production, qui à ce stade sont radicalement différents de votre environnement de développement? Bien sûr, la conteneurisation est déjà en quelque sorte résume bon nombre de ces différences, mais (espérons-le) vous avez des paramètres réseau, des API tierces et d'autres choses qui ne sont pas les mêmes en développement, même avec des conteneurs. Soyez donc audacieux et passez du développement à la production!

6. Ne vérifiez pas vos vars env

Votre projet ne dispose que de 80 jetons d'accès différents, clés API, informations d'identification de base de données et informations d'identification de magasin de cache réparties sur une demi-douzaine de YAML. Super facile à suivre et super difficile à gâcher avec vos environnements de production, de développement et (espérons-le) de mise en scène. Ne revérifiez pas les variables qui auraient pu être modifiées dans le déploiement, et vous obtiendrez quelques heures de débogage pénible dans un proche avenir.

7. Ne garantissez pas la cohérence des données après le déploiement

Dans une étape précédente, on vous avait déjà dit de vous assurer que les clients pouvaient continuer à utiliser votre logiciel à mi-déploiement, nous sommes donc déjà à mi-chemin pour garantir une mauvaise cohérence des données. Assurez-vous que vous n'avez pas cartographié tous les points que votre nouveau code pourrait toucher la base de données, en particulier la structure de la base de données elle-même. En cas de problème, annulez simplement la validation et la restauration – ne vous inquiétez jamais de devenir orphelin ou incohérent.

8. Ne vous préparez pas à un retour en arrière tardif

Si tout le reste échoue… attendez, ce ne sera pas le cas! Certains problèmes peuvent survenir pendant le déploiement, bien sûr, mais nous n'aurons pas besoin de revenir en arrière après c'est fait, non? Droite? Une fois que tout est réglé, et que vous avez fait un plan (que vous ne devriez absolument pas, vous vous en souvenez?) Et que vous l'avez suivi étape par étape, et que tout s'est bien passé, vous ne devriez pas avoir besoin de revenir en arrière. Mais disons que cela se produit, et quelques heures (ou jours) après le déploiement, vous devez revenir au commit / tag / précédent que vous utilisez. De nouvelles données auront circulé et devront peut-être être reconverties manuellement en quelque chose de gérable par la version précédente de votre logiciel. N'y pensez pas, ne planifiez pas cela – il est peu probable que cela se produise. Et si c'est le cas, vous aurez beaucoup de temps à travailler sur des cas excentriques et marginaux tard dans la nuit. Ce qui est de ne pas aimer?

9. Ne communiquez pas efficacement avec votre équipe

Vous savez déjà que vous devriez avoir de terribles systèmes de suivi des journaux et des erreurs. Ajoutez l'insulte aux blessures et ne parlez pas à vos collègues de manière rapide, directe et claire. Les longues pauses sont idéales pour un effet dramatique, surtout lorsque vos collègues attendent une réponse rapide. Soyez vague sur ce que vous faites. Appuyez sur le bouton de restauration et "oubliez" d'en parler aux gens. En général, soyez aussi déroutant et indisponible que possible.