ETQ que dev je souhaiterais déployer automatiquement mon application lors de chaque merge sur master

[Volubyl]

L'idée serait de pouvoir automatiser ces étapes.

A. Client

Lors de chaque push :

1. Installer les dépéndences
2. Linter et lancer les tests unitaires

Lors du merge sur master :

3. Builder l'image docker et faire en sorte qu'elle soit la plus légère possible (utilisation du multi stage build ?)
4. Pusher l'image sur le registry
5. Puller l'image sur le serveur de production

B. Serveur

Lors de chaque push :

1. Installer les dépéndences
2. Linter et lancer les tests unitaires

Lors du merge sur master :

3. Builder l'image docker et faire en sorte qu'elle soit la plus légère possible (utilisation du multi stage build ?)
4. Pusher l'image sur le registry
5. Puller l'image sur le serveur de production

Schéma graphique ici : https://excalidraw.com/#json=5485919473762304,isVk1hlN1rbilKCFEOap9w

Prérequis :

1. Les étapes du workflow Client doivent se passer en // par rapport aux étapes du Serveur
2. Chaque étapes est bloquante pour la suivante. En cas d'échec d'une étape, la CI s'arrête.

[Volubyl]

@mmarchois @ip512 @NicolasDievart

Cette tâche est vraiment sujette à discussion. Je propose cette idée car ce worlflow me parraît bien mais p-e qu'il est overkill ou non prio pour le moment.

A vue de nez pour faire cette feature il faudrait :

1 . créer un docker file de production en utilisant les multi stage build de Docker (https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds) pour le client et le serveur

pourquoi ?

• On pourrait imaginer n'embarquer dans l'image de prod que les dépendences et pas les dev dependencies.
• Pour le front on pourrait mettre que le css minifié et purgé
• On pourrait virer les tests *

2. Si on utilise docker-compose pour le déploiement, il faudrait en créer un de prod. @mmarchois tu parlais de k8s mais là c'est un peu en dehors de mon scope de compétence.

3. Lancer une commande en SSH sur les serveurs pour puller les images (un peu bricolé mais ça pourrait le faire) *

Qu'en pensez-vous ?

• pas certains de mon idée là :sweat_smile:

[ip512]

À mon avis, il faudrait dans un premier temps le mettre en place sur un environnement de test/staging. On pourrait utiliser cet environnement comme démo, mais dans ce cas il faudrait prévoir un minimum de fixtures pour pouvoir jouer avec.

[florimondmanca]

On a désormais la doc du processus de déploiement manuel actuel ici : https://github.com/fairnesscoop/permacoop/tree/master/prod

Dans la continuité de la discussion, j'envisagerais ça :

1. Configurer un environnement de test/staging, genre https://staging.permacoop.fairness.coop. On y activera le déploiement auto en cours de développement, en gardant le process manuel en prod pour l'instant. Quand le déploiement auto semblera robuste, on pourra le faire sur la prod aussi.
2. Ajouter .github/workflows/staging.yml avec un job deploy qui se lancerait à chaque push sur master (ou autre branche avec laquelle on voudrait jouer pour déclencher des déploiements de test).
   • Pour l'instant, ce job referait grosso modo le process manuel actuel en lançant un script via SSH : git pull, npm run build client et serveur, relance de pm2. Il faudra générer une clé SSH spécifique et la mettre dans les $secrets sur GitHub.
   • Une fois que ce sera opérationnel, on pourra ensuite voir pour "améliorer" / "sophistiquer" le process (par ex avec Docker… Même si ça pose la question de leur taille, de leur stockage, du registry à utiliser, etc : est-ce qu'on en aura vraiment besoin ? À voir… D'où cette étape incrémentale.)

[florimondmanca]

On a un avis sur l'outil de déploiement de PM2 ? https://pm2.keymetrics.io/docs/usage/deployment/. Apparemment ça ne prend tjr pas en compte le reload éventuel des applications.

Je me dis aussi qu'on peut commencer par bidouiller des scripts SSH, mais qu'assez vite il faudra aller sur des outils + robustes, sans être overkill non plus. Mais dans le domaine du "DevOps côté infrastructure" je suis preneur de bonnes pratiques… À discuter.

[florimondmanca]

Il y a du changement avec l'adoption d'Ansible #276.

Je vais màj la description de l'issue avec ce qui me semble nécessaire désormais