Déploiement de l'application - MTES-MCT/histologe GitHub Wiki

🔥 Déploiement

Scalingo est utilisé pour gérer les déploiements Histologe

💡Prérequis

Pour pouvoir faire un déploiement, vous devez au préalable être rajouté dans l'organisation github et scalingo par un membre de l'équipe.

⚙️ Staging

Le projet est automatiquement déployé lorsqu'une pull request est mergée sur la branche develop et l'intégration continue est validée.

Le suivi du déploiement se fait sur la plateforme scalingo

Cliquer sur histologe-staging puis l'onglet Déploiement

Si besoin de jouer une commande sur la staging :

scalingo -a histologe-staging run php bin/console app:nom-commande-a-jouer

🚀 Production

🤓 Remarque sur le système de numérotation des tags/releases

Le système de numérotation de version utilisé est des plus classiques : MAJOR.MINOR.PATCH, voici une brève description de comment elle est utilisée chez Histologe.

La MAJOR version est utilisée lorsqu'il y a des changements importants dans l'application qui peuvent nécessiter des mises à jour importantes dans les systèmes utilisant l'application.

La MINOR version est utilisée lorsqu'une nouvelle fonctionnalité est ajoutée à l'application.

La PATCH version est utilisée lorsqu'une modification est apportée à l'application pour corriger un bogue ou apporter une amélioration.

:warning: Nous avons remarqué que les PR de review_app vers main étaient mergées automatiquement lorsqu'on suit la procédure suivante. Donc faire attention, et éventuellement fermer ces review apps avant de faire la mise à jour.

La mise en production est faite par un membre de l'équipe depuis son poste en mergeant develop vers main.

Une fois les mises à jour poussées vers main, le déploiement se fait automatiquement.

🔧 1. Mise à jour de la branche locale develop

$ git checkout develop
$ git pull origin develop

🔧 2. Mise à jour de la branche locale main

$ git checkout main
$ git pull origin main

🔧 3. Merger develop dans main

$ git checkout main
$ git merge develop

🔧 4. Pousser les mises à jour depuis main

$ git push origin main

Le projet est automatiquement déployé lorsque l'intégration continue est validée.

image

Le suivi du déploiement se fait sur la plateforme scalingo

Cliquer sur histologe puis l'onglet Déploiement

image

📚 Publication de la release note

Nous utilisons les tags pour marquer la version de l'application.

Consultez la liste des tags afin de créer le tag de la prochaine version https://github.com/MTES-MCT/histologe/tags

🔧 1. Créer un tag de release depuis main

$ git tag 1.7.4
$ git push origin 1.7.4

🔧 2. Créer une release à partir du tag

🔧 3. Cliquer sur Releases

🔧 4. Créer une release à partir du tag précédemment crée en cliquant Draft a new release

🔧 5. Générer la release note afin de récupérer les titres des pull request et faire les modifications nécéssaires en vous basant sur les précédentes releases.

Exemple: Template actuel

# :rocket:  1.7.3 (2023-03-30)
## Features
* [Performance] Revoir la récupération des notifications [#972](https://github.com/MTES-MCT/histologe/issues/972)
* [Performance] Revoir implémentation technique export [#971](https://github.com/MTES-MCT/histologe/issues/972)

## Bug fixes
* Correction du parcours dans l'édition de signalement [#1122](https://github.com/MTES-MCT/histologe/pull/1122)
* [BO- Export données] -Erreur si Filtre Etiquette #508 

**Full Changelog**: https://github.com/MTES-MCT/histologe/compare/1.7.2...1.7.3

🔧 6. Informer l'équipe en collant la release note sur le channel mattermost histologe---dev-et-ux

🔧 7. Dans le backlog, créer un nouveau milestone (s'il n'existe pas déjà) avec le numéro de version, v1.7.3, l'attribuer aux tickets effectués et les fermer (ils passeront en Done automatiquement)

:abacus: Commandes

Vérifier avec l'équipe technique s'il y a des commandes à jouer.

scalingo -a histologe run php bin/console app:nom-commande-a-jouer

Variables d'environnement

Vérifier avec l'équipe technique s'il y a des variables d'environnement à ajouter ou à supprimer sur scalingo

Suivi de la MEP

Faire un tour sur la plateforme pour vérifier les nouvelles fonctionnalités Vérifier s'il y a des erreurs sur Sentry dans les heures qui suivent

🔧 Opération de maintenance

L'activation du mode maintenance peut être nécessaire dans deux contextes :

  • Lors de problèmes indépendants de notre volonté tels que des dysfonctionnements au niveau de l'infrastructure, gérés par des fournisseurs tiers, qui ont un impact majeur sur l'expérience utilisateur.

  • Peut également être activé pour préparer une mise à jour majeure de la plateforme. En mettant le site en mode maintenance, nous assurons la sécurité des opérations en limitant l'accès pendant la durée de l'intervention, minimisant ainsi tout impact sur l'expérience utilisateur. image

Pour les mises à jour majeure, il est nécessaire d'informer avant d'activer le mode maintenance en activant la bannière de maintenance avec un message approprié

Voici les variables d’environnements permettant de gérer ces opérations

Variable Description
MAINTENANCE_BANNER_ENABLE Activation de la bannière de maintenance. Mettez à 1 pour activer et à 0 pour désactiver.
MAINTENANCE_BANNER_MESSAGE Message affiché dans la bannière de maintenance. Indiquez le message prévu lors de l'opération de maintenance.
MAINTENANCE_ENABLE Activation de la maintenance. Mettez à 1 pour activer et à 0 pour désactiver. (Accès limité à la plateforme, seul les super admin pourront déposer un formulaire et se connecter au BO)

🕸️ Infrastructure

L'infrastructure d'un environnement est déployée et gérée par Scalingo et s'articule comme suit :

  • Le buildpack PHP orchestre un conteneur appelé web qui contient :
  • Le serveur PHP communique avec la base de données MySQL.
  • Le serveur PHP communique avec la base de données Redis, notamment pour le stockage des sessions utilisateurs et le cache
  • Le serveur PHP communique avec des services tiers :

Diagramme:

image