Repository et GitLab
- Frédéric Deniger
Tous les projets Fudaa ont été migrés sur GitLab: https://gitlab.com/fudaa et les livrables sont publiés sur le repository central Maven: https://central.sonatype.org/pages/ossrh-guide.html.
Accès développeur
Pour participer au projet, les développeurs devront avoir un compte sur GitLab: https://gitlab.com/ et:
contacter un Owner du projet: https://gitlab.com/groups/fudaa/-/group_members
ou contact chez fudaa.org
Gestion des tickets et de la documentation
La documentation ( developpeur + utilisateur) et les tickets sont toujours gérées sur l’instance Atlassian:
Gestion des sources
GIT est utilisé pour la gestion des sources.
Par rapport à Subversion, un action de Commit (git commit) ne va pousser les modifications sur le dépot distant mais simplement sur le dépot local. Il faudra faire un “push”
Voir:
Workflow de gestion des versions
Plusieurs solutions existent pour gérer les versions de très simples à très compliquées:
Etant donné que le cycle de livraison des projets Fudaa est assez simple et consiste a des releases d’exécutables, la solution “release branches” https://docs.gitlab.com/ee/workflow/gitlab_flow.html#release-branches-with-gitlab-flow est adoptée pour la plupart des projets. La branche master contient les derniers développements qui sont livrables à tout moment.
Une release se traduit par la construction d’un livrable par le CI/CD de Gitlab: le pipeline construit les livrables avec la nouvelle version et si succès, les livrables sont poussés sur le repository et les sources sont taguées.
Dans l’idéal chaque nouveau développement devrait se faire dans une branche ayant une durée de vie courte ( 4 jours maxi)
Intégration continue CI/CD
Un projet simple a été construit pour illustrer l’intégration continue:
Fichiers principaux:
https://gitlab.com/fudaa/fudaa-test-gitlab/blob/master/.m2/settings.xml
Définit la configuration du repository et active le projet GPG permettant de signer les livrables ( indispensables pour déployer sur le repository Maven Central).
Le fichier est assez simple et toutes les valeurs sont issues des variables du groupe fudaa de GitLab.
https://gitlab.com/fudaa/fudaa-test-gitlab/blob/master/.gitlab-ci.yml
Ce fichier définit les différentes étapes de l’intégration continue:
build: compilation du projet
test: lancement les tests
deploy: déploiement soit upload des jar dans le repository
release: cette étape est en général lancée manuellement: elle permet de générer les livrables en version “release” (sans -SNAPHSOT) et de taguer les sources
L'étape n+1 est lancé si l'étape n est en succès.
Chaque projet Fudaa peut re-définir ces étapes pour notamment activer les profiles Maven adéquat et générer les installeurs.
Sécurité
Bien entendu, aucun mot de passe ne doit être laissé en clair dans les sources. GitLab fournit un système de variables permettant de définir ces mot de passe pour le group fudaa.
Les scripts d’intégration continue ne doivent pas écrire les valeurs de ces variables ( mot de passe) qui seront alors accessibles par tous. Une possibilité serait de rendre “private” les jobs afin de cacher ces logs.
Repository
Tout est configuré dans le pom parent des projets fudaa: https://gitlab.com/fudaa/fudaa-pom (https://gitlab.com/fudaa/fudaa-pom/blob/master/pom.xml)
Les livrables fudaa ( releases et snapshots) sont accessibles ici:
Toutes les releases sont également disponibles sur le repository officiel CENTRAL: