| Sommaire |
|---|
Gestion des sources avec git
| Info |
|---|
Pour gérer plus facilement les sources sur le serveur d'exploitation il est conseillé d'utiliser git. Le dépôt d'origine d'esup-signature se trouve sur github https://github.com/EsupPortail/esup-signature. Le dépôt fonctionne ainsi :
Des tags sont créés pour chaque version importante du code voir : Change log , https://github.com/EsupPortail/esup-signature/tags |
Clonage
Comme expliqué dans la documentation d'installation, il est préférable de cloner le dépôt git sur le serveur qui héberge esup-signature. Pour cela on commence par faire :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git clone https://github.com/EsupPortail/esup-signature.git |
Le dépôt sera copié dans ./esup-signature, vous pouvez rester sur la branche master (branche git par défaut)
Commit de la configuration de production
Lorsque la configuration ainsi que la personnalisation seront terminées, vous devez créer un commit de production pour "sauvegarder" vos modifications. Grace à cela lorsque que vous récupérerez les prochaines versions vos modifications seront reprises (et pourront potentiellement donner lieu à des conflits)
Pour consulter vos modifications :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git status # ou git diff |
Pour sélectionner les fichiers à "commiter":
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
# pour tout prendre git add . # ou pour de l'unitaire git add src/resources/application.yml |
Pour créer un nouveau commit :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git commit -m "ma conf de prod" |
Il faudra répéter cette opération pour chaque modification effectuée sur le code
Mise à jour d'esup-signature
Il faut tout d'abord mettre à jour votre dépôt local depuis le dépôt github
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git fetch |
Vous pouvez consulter la liste des tags et ainsi contrôler que les dernières modifications ont bien été téléchargées:
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git tag |
Il faut de plus s'assurer que toutes les modifications de code ont bien été sauvegardées ("commitées") :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git status |
S'il y a des modifications à valider, faire un commit comme expliqué plus haut.
On peut alors fusionner la branche master locale avec la version (le tag) correspondant à la version suivante d'esup-signature.
| Info |
|---|
Dans la page Change log on conseille de passer par chaque version intermédiaire du code. Cela n'est nécessaire que dans le cas où il y a des mises à jours de base de données. Il faut donc bien vérifier la présence ou non de script à passer en consultant le Change log et/ou en regardant la liste des scripts dans src/resources/ (les scripts update_X.X.sql). |
Pour fusionner la version (tag) voulue :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git merge X.X.X |
git va tenter de fusionner le code provenant du tag sur votre code de la branche locale master. A ce moment il se peut que des conflits se produisent. Si une même partie de code à été modifiée à la fois dans la branche master locale (configuration ou personnalisation) et sur le tag provenant de github, git va les marquer en conflit. Un retour à l'écran précise les fichiers à corriger, dans ce cas le projet ne compilera pas. Il faut donc éditer chaque fichier en conflit pour corriger les incohérences.
Lorsque les conflits sont résolus et que le projet compile (mvn clean package) correctement, Il faut de nouveau faire un commit sur la votre branche master locale (le commentaire n'est pas obligatoire c'est git qui le gère pour le merge):
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
git commit |
| Remarque |
|---|
Si précisé dans la page Change log , ne pas oublier de passer le script de mise à jour de base de données après avoir fait "mvn clean package" |
Mise à jour de la base de données
| Info |
|---|
Pour monter de version il se peut que des scripts doivent être lancer. Pour ce faire il faut d'abord compiler une première fois les sources pour que le schéma de la base soit à jour. Ensuite, il faut passer le script correspondant présent dans "src/main/resources/update_X.X.sql". Pour lancer un script SQL sous PostgreSQL :
|
Archivage / Purge des données
Lorsqu'une adresse est configurée au niveau la propriété archive-uri du fichier de configuration application.yml le système va tenter d'y archiver les documents signés (Demandes terminées).
Le paramètre delay-before-cleaning permet de régler un délais en jours avant la suppression des fichiers présents en base pour les demandes qui sont au statut "Exporté". Si la valeur est 0, les demandes seront archivées dés quelles auront été exportées.
Le demandes restent consultables depuis esup-signature qui fait, alors, la passerelle avec l'espace d'archivage.