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:

Les mots d'ordre sont : respect et bienveillance.

Les discussions politiques sont déconseillées, et ont davantage leur place sur

Les règles de l'instance sont bien entendu d'application.

Fils hebdomadaires"

"Demandez-moi n'importe quoi"

Communautés détendues

Communautés liées:

Loisirs:

Vie Pratique:

Communautés d'actualité

Société:

Pays:

Communauté de secours:

founded 2 years ago
MODERATORS
 

Pour parler de technologie toute la semaine, il y a !technologie@jlai.lu

you are viewing a single comment's thread
view the rest of the comments
[–] cnovel@jlai.lu 5 points 3 months ago (3 children)

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.

[–] BlackEco@lemmy.blackeco.com 2 points 3 months ago* (last edited 3 months ago)

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.

[–] Skunk@jlai.lu 2 points 3 months ago

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: 🤷🏻‍♂️

[–] Underwire@lemmy.world 2 points 3 months ago (1 children)

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).

[–] cnovel@jlai.lu 1 points 3 months ago

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).