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 myapp
qui 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-dev
points myws-dev
auxquels les utilisations mydb-dev
. De même, myapp-qa
indique les myws-qa
utilisations mydb-qa
. Pareil pour DEMO
et LIVE
.
Le problème avec cela est que chaque fois que je modifie, disons myapp
, cela m'oblige à apporter des modifications à myws
et mydb
aussi. Mais parce que chaque DEV
environnement 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-dev
et myapp-dev
deviennent 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'
DEMO
environnement pour leurs dépendances en aval, pour tous leurs environnements de non-production (DEV
,QA
etDEMO
); et - Les dépendances en amont dépendent de l'
LIVE
environnement pour leurs dépendances en aval pour leur environnement de production
L'utilisation de cette convention myapp-dev
indiquerait tous ceux myws-demo
qui utiliseraient mydb-demo
. De même, myapp-qa
indiquerait également myws-demo
et mydb-demo
.
L'avantage que je peux trouver ici est la stabilisation de la construction : il est beaucoup moins probable que l' DEMO
environnement d'un composant particulier devienne instable, car le code ne peut pas y arriver DEMO
sans des tests rigoureux à la fois sur DEV
et QA
.
Le seul inconvénient que je peux trouver à cette méthode est que, si se DEMO
casse 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 DEV
et 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?