Déploiement de l'application

🔥 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.

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.

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

Cliquer sur histologe puis l'onglet Déploiement

📚 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

🧮 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