Nous avons beaucoup d'applications et de services Web (certains produits destinés au public, certains internes et une partie d'un "backend" privé) qui sont interdépendants les uns des autres. Chacun de ces composants possède 4 environnements (clusters de serveurs / nœuds répondant à des objectifs spécifiques):
- Hors production
DEV- Environnement de développement intégré où CI construit des changements poussés; utile aux ingénieurs pour dépanner les bogues difficiles à trouver qui ne sont pas reproductibles localementQA- AQ isolé / environnement de testDEMO- Environnement UAT stable pour les acteurs commerciaux
- Production
LIVE- Notre environnement live / production
La promotion du code va: LOCAL(machine du développeur) => DEV=> QA=> DEMO=> LIVE.
Supposons que nous ayons une application appelée myappqui est soutenue par un service Web RESTful appelé myws, lui-même soutenu par une base de données appelée mydb.
Actuellement, nous avons ce que j'appellerais une promotion " orchestrée " parmi ces dépendances: les myapp-devpoints myws-devauxquels les utilisations mydb-dev. De même, myapp-qaindique les myws-qautilisations mydb-qa. Pareil pour DEMOet LIVE.
Le problème avec cela est que chaque fois que je modifie, disons myapp, cela m'oblige à apporter des modifications à mywset mydbaussi. Mais parce que chaque DEVenvironnement pointe vers les environnements de ses dépendances DEV, cela signifie que je dois planifier et déployer ces changements en même temps. De plus, si une version devient instable / cassée, elle fait souvent tomber d'autres composants en amont; par exemple, si un développeur casse quelque chose lors d'un changement mydb-dev, les clusters myws-devet myapp-devdeviennent généralement instables.
Pour résoudre ce problème, je prépare une proposition pour ce que j'appellerais une stratégie de promotion " cloisonnée ": toutes les dépendances inter-composantes suivent cette ligne directrice:
- Les dépendances en amont dépendent de l'
DEMOenvironnement pour leurs dépendances en aval, pour tous leurs environnements de non-production (DEV,QAetDEMO); et - Les dépendances en amont dépendent de l'
LIVEenvironnement pour leurs dépendances en aval pour leur environnement de production
L'utilisation de cette convention myapp-devindiquerait tous ceux myws-demoqui utiliseraient mydb-demo. De même, myapp-qaindiquerait également myws-demoet mydb-demo.
L'avantage que je peux trouver ici est la stabilisation de la construction : il est beaucoup moins probable que l' DEMOenvironnement d'un composant particulier devienne instable, car le code ne peut pas y arriver DEMOsans des tests rigoureux à la fois sur DEVet QA.
Le seul inconvénient que je peux trouver à cette méthode est que, si se DEMOcasse pour un composant particulier, tous les environnements de non-production pour toutes les dépendances en amont seront soudainement brisés. Mais je dirais que cela devrait se produire extrêmement rarement en raison des tests effectués sur DEVet QA.
Cela a eu un problème que beaucoup de développeurs (beaucoup plus intelligents et expérimentés que moi - même) ont résolu, et je ne serais pas surpris si ce problème et ses solutions ont déjà des noms à eux ( en plus de ce que je fais appel orchestrée / cloisonnée). Je demande donc: les avantages d'une stratégie de promotion cloisonnée l'emportent-ils sur les inconvénients, et quels sont les inconvénients que je peux ignorer ici?
Réponses:
Si je lis bien votre message, il ne semble pas que cette proposition résout réellement l'un des problèmes allégués.
La "stratégie de promotion cloisonnée" semble ne faire qu'empirer les choses. Si myapp v2, myws v2 et mydb v2 ne sont que sur DEV, et myapp v2 s'appuie sur mydb v2 pour ne pas planter, alors quand j'essaierai d'exécuter myapp v2 sur DEV, je frapperai mydb v1 DEMO et ça plante. Vous seriez essentiellement obligé soit de remplacer constamment les silos, soit de déployer mydb v2 jusqu'à prod avant de pouvoir même commencer à travailler sur myapp v2. Plus important encore, vous ne testeriez jamais mydb v2 sur DEV, donc s'il est cassé, vous ne le découvrirez même pas jusqu'à ce qu'il casse sur DEMO, puis vous êtes de retour à la case départ.
Dans une certaine mesure, le problème que vous décrivez est inévitable, quelle que soit la configuration de votre flux de travail, mais il peut être minimisé. L'astuce consiste à s'assurer que l'interface entre mydb et myws (et l'interface entre myws et myapp) est strictement définie et que toutes les mises à jour de cette interface soient entièrement rétrocompatibles . Dans mon travail, nous avons un schéma XML définissant l'interface entre nos applications et nos services, et bon nombre de nos outils internes ne nous permettent tout simplement pas d'effectuer des mises à jour incompatibles avec ces schémas.
Cela me semble être un problème grave, mais pas un problème de déploiement. Une base de données cassée empêchera certainement le service et l'application de fonctionner correctement, mais ils ne devraient pas devenir "instables". Ils devraient renvoyer des messages d'erreur d'une sorte, de sorte que toute personne exécutant myapp sur dev voit "Nous sommes désolés, notre base de données a des problèmes aujourd'hui" au lieu de simplement planter.
Si le problème est qu'une base de données cassée cause ces problèmes, alors ce que vous pouvez faire est de configurer un système de "silo temporaire" qui vous permet de dire "mydb DEV est cassé maintenant, veuillez router toutes les requêtes myws DEV vers mydb DEMO pour le moment ". Mais cela ne devrait être qu'un moyen d'effectuer des correctifs temporaires jusqu'à ce que mydb DEV fonctionne à nouveau normalement. Si tout est "cloisonné" de cette façon par défaut, alors vous êtes de retour aux problèmes que j'ai décrits ci-dessus parce que personne ne court contre mydb DEV.
J'ai l'impression que je ne comprends probablement pas votre proposition d'une manière ou d'une autre, mais j'espère que cette réponse rend au moins évident ce qui était mal compris et la meilleure façon de la reformuler.
la source