this post was submitted on 15 May 2025
6 points (100.0% liked)
Forum Libre
1126 readers
54 users here now
Communautés principales de l'instance
Nous rejoindre sur Zulip: https://jlailu.zulipchat.com/
Une communauté pour discuter de tout et de rien:
- Fil quotidien "comment allez-vous?"
- Contenu détendu
- Questions à la communauté
- Aujourd'hui j'ai appris
- Anecdotes personnelles
- Bonnes nouvelles
- Projets locaux / associatifs
- Inspiration
- BD / illustrations
- Etc.
Les mots d'ordre sont : respect et bienveillance.
Les discussions politiques sont déconseillées, et ont davantage leur place sur
- !france@jlai.lu
- !monde@jlai.lu
- !belgique@jlai.lu
- !luxembourg@lemmy.world
- !quebec@lemmy.ca
- !suisse@lemmy.world
Les règles de l'instance sont bien entendu d'application.
Fils hebdomadaires"
- Lundi Lecture
- Mardi Marrant
- Mercredi CinéSéries
- Jeudi Tech
- Samedi DJ/Musique
- Dimanche Jeux Videos
"Demandez-moi n'importe quoi"
- Je suis un maraicher en bio sur petite surface - DMN (AMA)
- Je serai bientôt ordonné pasteur protestant, demandez-moi ce que vous voulez !
- Je bosse au 4/5 sur les modèles de langage (LLM, parfois appelées IAs) et à 2/5 sur la robotique open hardware AMA
Communautés détendues
Communautés liées:
Loisirs:
- !cineseries@jlai.lu
- !cyclisme@sh.itjust.works
- !jeuxvideo@jlai.lu
- !jardin@lemmy.world
- !jeuxvideo@jlai.lu
- !livres@jlai.lu
- !motardie@jlai.lu
- !sport@jlai.lu
- !technologie@jlai.lu
Vie Pratique:
Communautés d'actualité
Société:
Pays:
- !monde@jlai.lu
- !belgique@jlai.lu
- !france@jlai.lu
- !luxembourg@lemmy.world
- !quebec@lemmy.ca
- !suisse@lemmy.world
Communauté de secours:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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: 🤷🏻♂️
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).