|
|
|
# poc-multiple-environnements
|
|
|
|
|
|
|
|
> **Le projet à été mis dans un Dev Container, mais ce n'est pas le sujet du POC.**
|
|
|
|
>
|
|
|
|
> _WARNING : La version du dev container n'est pas compatible avec la version de gatsby (starter 2023) & meilisearch._
|
|
|
|
|
|
|
|
## 1. Objectifs du POC
|
|
|
|
|
|
|
|
Avoir un environnement de staging depuis le repo et sans avoir besoin d'avoir un deuxième repo en n'utilisant que les features offertes par GitLab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 2. Que regarder ?
|
|
|
|
|
|
|
|
- Toute la mécanique est dans le fichier [.gitlab-ci.yml](https://forge.tedomum.net/hrenaud/poc-multiple-environnements/-/blob/8baff673bc0c4fbbac10f0db4d7a9676bcff9de4/.gitlab-ci.yml)
|
|
|
|
- les [environnements](https://forge.tedomum.net/hrenaud/poc-multiple-environnements/-/environments)
|
|
|
|
- Staging : http://staging-renaud-heluin.surge.sh/
|
|
|
|
- Production : http://hrenaud.tedomum.org/poc-multiple-environnements
|
|
|
|
- Les environnements dynamiques à `https://renaud-heluin-{feat|fix-issue-name-slugyfied}.surge.sh`
|
|
|
|
- Les Rapports Lighthouse dynamiques à `https://hrenaud/poc-multiple-environnements/-/jobs/{*}/artifacts/browse`
|
|
|
|
- la [CI](https://forge.tedomum.net/hrenaud/poc-multiple-environnements/-/pipelines)
|
|
|
|
- Une [Merge Request de démo](https://forge.tedomum.net/hrenaud/poc-multiple-environnements/-/merge_requests/39)
|
|
|
|
|
|
|
|
## 3. Ce qui a été mis en place
|
|
|
|
|
|
|
|
### A) Les solutions utilisées pour ce POC
|
|
|
|
|
|
|
|
- GitLab CI → 👍
|
|
|
|
- [`surge.sh`](https://surge.sh/) → 🫤
|
|
|
|
|
|
|
|
### B) Ajouts de Tests (4)
|
|
|
|
|
|
|
|
- Test du code (auto) ;
|
|
|
|
- Test de l'application qui build (auto) ;
|
|
|
|
- Rapport Lighthouse de performance, pour chaque Review App (auto) ;
|
|
|
|
- Test que l'application a bien été déployée (manuel, GitLab prend son temps pour vraiment publier, donc pas possible de le lancer en auto).
|
|
|
|
|
|
|
|
### C) De multiples environnements (Production, Staging et Reviews App)
|
|
|
|
|
|
|
|
Actuellement GitLab ne permet pas d'avoir de multiple Pages (environnements de publication/sites) cf. https://gitlab.com/gitlab-org/gitlab/-/issues/16208. GitLab permet néanmoins d'avoir des **Review App**, mais pas l'hébergement associé, donc pour palier à ce problème, il a été mis en place une solution avec [`surge.sh`](https://surge.sh/) d'autopublication.
|
|
|
|
|
|
|
|
> **Pourquoi avoir des Review App**
|
|
|
|
> Cela permet de valider chaque évolution avant de la passer en Staging puis définitivement en prod.
|
|
|
|
|
|
|
|
> **Pourquoi avoir un Staging**
|
|
|
|
> Si plusieurs ticket complémentaires sont livrés et pas testable dans 1 Review App, on peut tester tout le périmètre sur Staging avant la publication en Production.
|
|
|
|
|
|
|
|
**Il y a donc**
|
|
|
|
|
|
|
|
- **La Production** : Environnement définitivement créé et updatable via un bouton quand la MR a été validée en staging. Il est hébergée par `GitLab Page`
|
|
|
|
- **Le Staging** : Environnement temporaire (1 semaine), créé et updatable via un bouton quand la MR a été validée / mergée sur `main`.
|
|
|
|
- **Les Review App** avec :
|
|
|
|
- 1 Environnement temporaire (1 semaine), créé et qui s'actualise à chaque commit du code sur sa branche pour qui une Merge Request a été créé. La version est testable en ligne avec surge.sh ;
|
|
|
|
- 1 Rapport Lighthouse de performance du site (homepage).
|
|
|
|
|
|
|
|
Les Environnements temporaires utilisent des urls de `surge.sh`. Lorsque GitLab stop ses environnements, il supprime aussi les URLS de `surge.sh`.
|
|
|
|
|
|
|
|
### D) Configuration du repo / Process de mise en ligne et bonnes pratiques (forcées)
|
|
|
|
|
|
|
|
- Le repo a été configuré avec 1 seule branch `main` sans droit en écriture direct. Il faut forcément ouvrir des MR qui seront validées par le maintener du Repo pour mettre à jour cette branche finale ;
|
|
|
|
- Les branches sont forcément avec ces formats `feat/*` et `fix/*`.
|
|
|
|
- Le repo a été configuré avec 1 seule branch `main` sans droit en écriture direct. Il faut forcément ouvrir des MR qui seront validées par le maintener du Repo pour mettre à jour cette branche finale ;
|
|
|
|
- Les branches sont forcément avec ces formats `feat/*` et `fix/*`.
|
|
|
|
|
|
|
|
## 4. Annexes
|
|
|
|
|
|
|
|
## 4. Annexes
|
|
|
|
|
|
|
|
### **TODO / Reste à faire / Autres idées**
|
|
|
|
|
|
|
|
### **TODO / Reste à faire / Autres idées**
|
|
|
|
|
|
|
|
- Créer des index temporaires dans meilisearch pour chaque Env (staging et Review App) ;
|
|
|
|
- Mettre en place un test d'impact écologique du site ;
|
|
|
|
- Forcer l'utilisation d'un bon format de message de commit avec `husky` ;
|
|
|
|
- Mettre en place un gestionnaire de version/historique.
|
|
|
|
- Créer des index temporaires dans meilisearch pour chaque Env (staging et Review App) ;
|
|
|
|
- Mettre en place un test d'impact écologique du site ;
|
|
|
|
- Forcer l'utilisation d'un bon format de message de commit avec `husky` ;
|
|
|
|
- Mettre en place un gestionnaire de version/historique.
|
|
|
|
|
|
|
|
### Surge.sh
|
|
|
|
|
|
|
|
### Surge.sh
|
|
|
|
|
|
|
|
Ajouter en Envar de CI `SURGE_LOGIN` et `SURGE_TOKEN`.
|
|
|
|
Ajouter en Envar de CI `SURGE_LOGIN` et `SURGE_TOKEN`.
|
|
|
|
|
|
|
|
Pour avoir son Token
|
|
|
|
Pour avoir son Token
|
|
|
|
|
|
|
|
````sh
|
|
|
|
cat ~/.netrc | grep -A2 surge.sh
|
|
|
|
```sh
|
|
|
|
cat ~/.netrc | grep -A2 surge.sh
|
|
|
|
````
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Captures d'écrans d'une Merge Request
|
|
|
|
|
|
|
|
|
|
|
|
_Image 1 — Tests, rapports et Review App_
|
|
|
|
|
|
|
|
_Image 2 — Publication Staging & Production_ |
