Les techos, j’ai besoin d’un avis externe. Dans ma boîte, on a plusieurs services cloud qu’on développe et déploie. On essaye de suivre une approche microservice : un service par “fonctionnalité” (ie on a un service qui gère la gestion des données, un service qui gère le processing, une app qui permet de soumettre des jobs, etc.). Et on a 3 environnements : DEV, QA, PROD.
Mon approche, ça a toujours été de dire : un service en DEV appelle le QA de tous les autres, un service en QA appelle le QA de tous les autres et un service en PROD appelle la PROD de tous les autres. Ainsi, les developpeurs d’un service peuvent foutre le dawa en DEV, ça n’impacte pas les autres (en gros, on a le droit de casser DEV pour tenter des choses, car ça n’a aucune incidence sur le travail des autres équipes).
Sauf qu’on est en train de me faire comprendre que ça arrange pas certains autres services et qu’il faudrait changer ma manière de faire. Je suis convaincu que mon approche est la bonne, mais je suis preneur d’avis externes.
J’ai déjà travaillé comme ça avec l’environnement de DEV Qui appelle l’environnement d’intégration. Mais maintenant dans ma boîte tu fait tout en local, tu lances uniquement tes services et pas besoin d’avoir les services des autres pour travailler sur ton périmètre (ou très rarement).
Le dev local est limité pour certains services parce qu’on ne peut pas tout avoir un local (on utilise des composants azure qui ne sont pas deployables localement).
Mais pour aller plus dans le détail, on fait pareil et c’est probablement le cas de pleins d’entreprises. Cependant (1000 points pour Gryfondor) il y a également ce léger shift dérangeant.
On utilise 3 réseaux, Ops, admin et valid. Valid est le dev où tu peux tout casser. Sauf que pour alimenter Valid avec des data pas trop degueullasse il est alimenté par Ops via un tunnel à sens unique. C’est déjà un premier problème car si tu casses le valid le tunnel se remplit du côté ops.
Ensuite, je ne sais pas pourquoi, de plus en plus de systèmes plus ou moins importants utilisent les données présentes sur valid, donc si tu casses tout leurs utilisateurs ne sont pas contents.
Ce glissement s’est fait en une décennie peut être et je ne sais pas d’où ça vient, ça semble toucher plusieurs entreprises. C’est problématique car ça crée un flou entre dev et prod, a tel point qu’on en arrive à devoir refaire un nouvel environnement dev.
Donc avec ton exemple, ce qui était Prod, QA, Dev devient Prod, QA, Dev1-Prod et Dev2-Experiences.
C’est très con oui, je ne sais pas pourquoi ni comment on en arrive là, je soupçonne les Agiles Bros et leurs Team Falcon etc d’avoir participé à ce bordel mais je n’en suis pas certain.
Pour le coup dans ma précédente boîte on avait trois environnements comme toi : staging, QA et prod, plus l’env local. Notre infrastructure faisait qu’on ne pouvait pas appeler les services d’un autre environnement (chacun était dans son propre réseau privé, isolé des autres). La seule exception étant en local où on branchait notre service sur ceux de staging.
Pour en revenir à ta question, tu dis " les developpeurs d’un service peuvent foutre le dawa en DEV, ça n’impacte pas les autres" sauf que si j’ai bien compris, quand un service appelle un autre, c’est celui de QA qui est appelé. Et du coup je peux comprendre que ça saoule certains d’avoir des données en vrac sur la QA, c’est par ailleurs la raison pour laquelle on avait introduit cet environnement en plus de staging et prod.
Les techos, j’ai besoin d’un avis externe. Dans ma boîte, on a plusieurs services cloud qu’on développe et déploie. On essaye de suivre une approche microservice : un service par “fonctionnalité” (ie on a un service qui gère la gestion des données, un service qui gère le processing, une app qui permet de soumettre des jobs, etc.). Et on a 3 environnements : DEV, QA, PROD.
Mon approche, ça a toujours été de dire : un service en DEV appelle le QA de tous les autres, un service en QA appelle le QA de tous les autres et un service en PROD appelle la PROD de tous les autres. Ainsi, les developpeurs d’un service peuvent foutre le dawa en DEV, ça n’impacte pas les autres (en gros, on a le droit de casser DEV pour tenter des choses, car ça n’a aucune incidence sur le travail des autres équipes). Sauf qu’on est en train de me faire comprendre que ça arrange pas certains autres services et qu’il faudrait changer ma manière de faire. Je suis convaincu que mon approche est la bonne, mais je suis preneur d’avis externes.
J’ai déjà travaillé comme ça avec l’environnement de DEV Qui appelle l’environnement d’intégration. Mais maintenant dans ma boîte tu fait tout en local, tu lances uniquement tes services et pas besoin d’avoir les services des autres pour travailler sur ton périmètre (ou très rarement).
Le dev local est limité pour certains services parce qu’on ne peut pas tout avoir un local (on utilise des composants azure qui ne sont pas deployables localement).
Je suis d’accord avec toi, point final.
Mais pour aller plus dans le détail, on fait pareil et c’est probablement le cas de pleins d’entreprises. Cependant (1000 points pour Gryfondor) il y a également ce léger shift dérangeant.
On utilise 3 réseaux, Ops, admin et valid. Valid est le dev où tu peux tout casser. Sauf que pour alimenter Valid avec des data pas trop degueullasse il est alimenté par Ops via un tunnel à sens unique. C’est déjà un premier problème car si tu casses le valid le tunnel se remplit du côté ops.
Ensuite, je ne sais pas pourquoi, de plus en plus de systèmes plus ou moins importants utilisent les données présentes sur valid, donc si tu casses tout leurs utilisateurs ne sont pas contents.
Ce glissement s’est fait en une décennie peut être et je ne sais pas d’où ça vient, ça semble toucher plusieurs entreprises. C’est problématique car ça crée un flou entre dev et prod, a tel point qu’on en arrive à devoir refaire un nouvel environnement dev.
Donc avec ton exemple, ce qui était Prod, QA, Dev devient Prod, QA, Dev1-Prod et Dev2-Experiences.
C’est très con oui, je ne sais pas pourquoi ni comment on en arrive là, je soupçonne les Agiles Bros et leurs Team Falcon etc d’avoir participé à ce bordel mais je n’en suis pas certain.
TLDR: 🤷🏻♂️
Pour le coup dans ma précédente boîte on avait trois environnements comme toi : staging, QA et prod, plus l’env local. Notre infrastructure faisait qu’on ne pouvait pas appeler les services d’un autre environnement (chacun était dans son propre réseau privé, isolé des autres). La seule exception étant en local où on branchait notre service sur ceux de staging.
Pour en revenir à ta question, tu dis " les developpeurs d’un service peuvent foutre le dawa en DEV, ça n’impacte pas les autres" sauf que si j’ai bien compris, quand un service appelle un autre, c’est celui de QA qui est appelé. Et du coup je peux comprendre que ça saoule certains d’avoir des données en vrac sur la QA, c’est par ailleurs la raison pour laquelle on avait introduit cet environnement en plus de staging et prod.