build

Build and deploy

Build

Chaque commit publié sur master ou sur une branche concernée par une pull request vers master, déclenche l'intégration continue sur Azure DevOps.

• Le fichier azure-pipelines.yml permet de configurer la mise en forme du code, la compilation de l'interface graphique et le packaging (via plugin_packager.py) dans un pipe Azure.

• Le fichier .travis.yml permet de configurer les tests de déploiement du plugin (packaging et installation) avec Travis CI. L'environnement de tests (versions de QGIS et de Python) doit être mise à jour au fil de l'évolution du plugin en modifiant ce script. par exemple :

  matrix:
    - QGIS_VERSION_TAG=release-3_4

  deviendra

  matrix:
   - QGIS_VERSION_TAG=release-3_10

Déploiement

Chaque commit étiqueté (tagged) publié sur master, déclenche l'intégration et le déploiement continus depuis Azure DevOps. En plus des taches listées précédemment, le fichier azure-pipelines.yml permet alors la création d'une GitHub Release dans ce dépôt.

Packager

Si plusieurs branches

1. merge les PR correspondantes à la nouvelle version dans master

2. créer la branche releasing-*version* (par exemple releasing-3.2.0) depuis master :

3. dans la branche releasing-*version*, effectuer les tâches de la check-list ci-dessous :

- [] vérifier les traductions
- [] vérifier que le code est nettoyé des logs de dev
- [] formater le code avec black
- [] corriger les erreurs indiquées par l'analyse statique
- [] vérifier le fichier `quicksearches.json` dans la version packagée dans le CI
- [] modifier le `metadata.txt` pour indiquer la nouvelle version et mettre à jour le changelog

4. coller cette check-list dans la description de la PR de releasing-*version* vers master et intituler la PR "[version] pre-release"

5. récupérer le résultat de Packaging et tester l'installation via le zip, corriger si nécessaire

6. merge la PR "[version] pre-release" (si possible en mode squash) en nommant le commit "bump version to version"

7. basculer dans master et taguer le commit "bump version to version" correspondant au merge de la PR "[version] pre-release"

Commande exemple dans un terminal git, où XXXXXX est la signature (hash) du commit :

git tag -a 2.0.0-beta3 XXXXXXX -m "Version 2.0.0-beta3"
git push origin 2.0.0-beta3

8. récupérer dans le CI la version packagée du commit tagué

Si une seule branche (intitulée version)

1. dans la branche, effectuer les tâches de la check-list ci-dessous :

- [] vérifier les traductions
- [] vérifier que le code est nettoyé des logs de dev
- [] formater le code avec black
- [] corriger les erreurs indiquées par l'analyse statique
- [] vérifier le fichier `quicksearches.json` dans la version packagée dans le CI
- [] modifier le `metadata.txt` pour indiquer la nouvelle version et mettre à jour le changelog

2. intituler la PR "[version] description" (par exemple)

3. récupérer le résultat de packaging et tester l'installation via le zip, corriger si nécessaire

4. merge la PR dans master

5. récupérer le résultat de packaging et tester l'installation via le zip, corriger si nécessaire

6. basculer dans master modifier le fichier metadata.txt pour indiquer la nouvelle version et mettre à jour le changelog, nommer le commit "bumb version to version"

7. taguer le commit "bump version to version" de l'étape précédente

Commande exemple dans un terminal git, où XXXXXX est la signature (hash) du commit :

git tag -a 2.0.0-beta3 XXXXXXX -m "Version 2.0.0-beta3"
git push origin 2.0.0-beta3

8. récupérer dans le CI la version packagée du commit tagué

Mettre en prod

1. se connecter avec le compte Isogeo sur le dépôt en ligne des plugins QGIS Python
2. se rendre dans le dépôt du plugin Isogeo
3. Manage > Add version > indiquer l'emplacement du zip packagé (récupéré pendant la dernière étape du packaging)
4. cocher la case "Experimental flag" s'il s'agit d'une beta
5. mettre le lien vers la release correspondante dans le changelog
6. cliquer sur save

Attendre la confirmation par mail.