Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permettre de mettre en bêta/prod BEAUCOUP plus souvent #4184

Closed
SpaceFox opened this issue Feb 7, 2017 · 3 comments
Closed

Permettre de mettre en bêta/prod BEAUCOUP plus souvent #4184

SpaceFox opened this issue Feb 7, 2017 · 3 comments
Labels
C-Infra Concerne l'infrastructure technique sous le site

Comments

@SpaceFox
Copy link
Contributor

SpaceFox commented Feb 7, 2017

Le fonctionnement actuel en version bloque le déploiement de tout un tas de connectifs / améliorations assez triviaux, parce qu'il faut attendre pour qu'ils soient déployés que la version soit prête et testée, et que comme dans toute version, on voudrait bien que les fonctionnalités X et Y soient embarquées, et donc correctement testées, etc.

C'est long et apporte de la latence, mais c'est encore le processus le moins pire qu'on a trouvé avec nos outils et contraintes.

L'exemple inverse, ce serait une intégration continue dans laquelle tout ce qui est mergé sur prod est automatiquement déployé en prod. Sauf que ça pose d'autres problèmes, notamment dès qu'une version nécessite des opération manuelles pour être déployée.

Or donc voici qu'au boulot on utilise GitLab (une instance locale), qui vient avec une intégration continue assez géniale. Depuis quelques mois, cette intégration continue propose une fonctionnalité tout aussi géniale : les déploiement intégrés à l'intégration continue

Ce sont des tâches d'intégration continue comme les autres (donc potentiellement des scripts Shell arbitraires), qui sont taggués comme « déploie la version en cours sur l'environnement X ». Et surtout, on peut les lancer manuellement.

En admettant qu'on trouve un outil d'intégration continue sur Github qui propose la même fonctionnalité, on pourrait tout à fait définir ce genre de tâches (actives, disons, sur la branche prod et/ou sur les tags), ce qui permettrait :

  1. De déployer en 1 clic une version arbitraire sur la bêta ;
  2. De déployer en 1 clic une version arbitraire sur la prod (attention à qui on donne les droits d'appuyer sur ce bouton) ;
  3. De gérer les cas particuliers en faisant un déploiement manuel.

Je pense que ça peut être un gros plus pour le déploiement de ZdS est éviter cet espèce d'effet tunnel qu'on a aujourd'hui.

Si vous voulez des détails supplémentaires sur le fonctionnement du truc et la théorie, n'hésitez pas !

@SpaceFox SpaceFox added the C-Infra Concerne l'infrastructure technique sous le site label Feb 7, 2017
@SpaceFox
Copy link
Contributor Author

SpaceFox commented Feb 7, 2017

PS : En admettant qu'on trouve une solution qui fasse ça et qui ait grosso merdo les mêmes fonctionnalités que Gitlab CI, on peut bien entendu :

  1. Lui faire faire tous les backups imaginables avant la MEP proprement dite, et
  2. Lui faire mettre la page de maintenance pendant les opérations.

Puisqu'il s'agit en grosexactement d'exécuter un ou plusieurs scripts arbitraires sur un ou plusieurs serveurs arbitraires.

@pierre-24
Copy link
Member

Moi, l’intégration continue, je suis moyen chaud : pour rester concret, je dirais qu'au vu du nombre de RC de nos dernières releases, l'intégration continue est assez suicidaire. Et du coup, on peut pas se permettre, avec notre coverage actuel (pourtant pas mauvais, mais par exemple on a pas de tests fronts), de se reposer uniquement sur les tests, ce qui signifie intensifier la phase de QA, qui est déjà pas drôle à la base. Bref, dangereux.

Après, je suis assez fan de la fonctionnalité de GitLab CI en elle-même :)

@vhf vhf self-assigned this Feb 10, 2017
@vhf
Copy link
Contributor

vhf commented Feb 19, 2017

J'ai réfléchi à tout ça et je pense que si j'avais une semaine de vacances ce serait jouable.

Petite note :

  • De déployer en 1 clic une version arbitraire sur la bêta ;

Là aussi, attention à ne pas autoriser trop de gens à appuyer sur ce bouton. Les données sur la bêta sont généralement quelques jours/semaines derrière la prod. On peut pas se permettre de déployer du code sans être certain qu'il ne donne pas accès à la DB.

@vhf vhf removed their assignment Mar 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Infra Concerne l'infrastructure technique sous le site
Projects
None yet
Development

No branches or pull requests

4 participants