search

gip-inclusion / data-inclusion

data·inclusion aggrège les données de l'insertion sociale et professionnelle
https://api.data.inclusion.beta.gouv.fr/api/v0/docs
MIT License
6 stars 1 forks source link

chore(ci) : Deploy to staging through a PR label #299

Closed vperron closed 3 weeks ago

vperron commented 1 month ago

Il est dommage d'entrer en compétition avec les autres dev à chaque push sur une PR.

Avec ce système, on peut choisir quand déployer, surtout quand certaines PR ne méritent pas forcément un deploy, et se mettre d'accord avec les dev pour ce faire.

De plus, passer en draft n'est pas forcément le meilleur système car on confond le principe d'un brouillon (à ne pas relire) et le fait de déployer ou non.

vperron commented 1 month ago

Je suis moins fan, avec ma proposition tu peux décider que une PR a le "bâton" de déploiement et ne plus t'en occuper, par contre à chaque push ça rédéploiera ta PR comme attendu. Avec ta solution on doit retourner dans le clickodrome pour chaque push.

vmttn commented 1 month ago

désolé j'ai édité entre temps mon commentaire ;)

vperron commented 1 month ago

OK vu seconde proposition. Je pense que ce ne serait pas une mauvaise idée de dupliquer le job, car je suis toujours un peu en stress de voir ce job de deploy_prod tel une épée de Damoclès sur les PRs.

Ca serait limite plus clair d'avoir du coup le deploy_prod séparé (quitte à faire un include YAML pour etre DRY) mais qui ne se trigger que lorsque la PR est mergée, et le deploy_staging qui se fait sur label (ou via autorisation explicite, mais comme dit plus haut, je suis moins fan)

vmttn commented 1 month ago

ok pour dupliquer le job donc (dry ou non) et pour utiliser un label :+1:

pour la prod, est-ce qu'on n'utiliserait pas la branche (protégée) release pour ne plus avoir à review et s'aligner le fonctionnement qu'on a avec l'api (contraint par scalingo) ?

vperron commented 1 month ago

Je pense qu'aujourd'hui, avec staging de plus en plus proche de la prod et réellement utilisé en recette, on devrait pouvoir se le permettre en effet.

Ca relance un peu le sujet d'avoir une unique datawarehouse, mais j'avoue ne pas être encore certain de la marche à suivre à ce sujet. Le sujet des profils DBT permet en effet d'avoir plusieurs "cibles" mais je ne vois pas en quoi cela nous affranchit d'avoir deux clusters postgres séparés.

Il me semble que dans l'immédiat (et dans le doute) avoir deux datawarehouses, meme proches dans le fonctionnement (on pourrait activer les mêmes DAGs en staging et prod ?) me semble le plus safe. Mais je prends toute autre idée avec plaisir !