Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)
Mercure 2 et méthode de travail sur les applications Pleade
Ce document décrit les scripts permettant de travailler et mettre à jour les applications recette sur le serveur mercure2. L'ensemble des interventions doivent se faire dans la mesure du possible avec l'utilisateur système ajlsm. Pour travailler avec un projet, il faut se positionner dans le répertoire correspond. Ce répertoire se trouve à l'emplacement /home/ajlsm/recette/<nom du projet>. Par exemple, le projet ad53 se trouve à l'emplacement /home/ajlsm/recette/ad53.
Chaque projet peut proposer des surcharges correspondant à chaque variante. Ces surcharges se trouve à l'emplacement /home/ajlsm/recette/<nom du projet>/surcharges/<nom de la variante>. par exemple, pour la variante internet du projet ad53, la surcharge se trouve à l'emplacement /home/ajlsm/recette/ad53/surcharges/internet. Ce répertoire des surcharges est aussi un dépôt svn; Ce qui signifie qu'on peut y lancer directement les commandes SVN (update, commit, ...).
À coté du répertoire des surcharges, les sources SVN du projet sont disponible à l’emplacement /home/ajlsm/recette/<nom du projet>/<nom du projet>. Exemple pour ad53, /home/ajlsm/recette/ad53/ad53.
Pour chaque projet, les scripts permettent d’exécuter les opérations suivantes
- Intervention et mise à jour de l'application de recette.
- Arrêt, démarrage et redémarrage du service tomcat.
- Dépôt (si possible) d'une webapp complète sur le serveur de production.
- Commiter les changements directement sur le serveur SVN depuis mercure.
Modification et mise à jour de la recette
[modifier | modifier le wikicode]Le système de mise à jour travail conjointement avec la surcharge des applications. La liste ci-dessous définie les fichiers spéciaux qui sont traditionnellement surchargé pour les projets. Dans la suite, on appellera ces fichiers, fichiers spéciaux:
- parametres.xconf
- WEB-INF/cocoon.xconf
- WEB-INF/pleade-*
- WEB-INF/web.xml
- WEB-INF/properties/*
- WEB-INF/logs/pleade-stats-*
- module-eadeac/pages/*
- module-eadeac/conf/*.xconf
- module-eadeac/conf/search-forms/*
- module-eadeac/conf/subsets/*
- module-eadeac/conf/cdc/*
- theme/i18n/local/*
- theme/css/local/*
- theme/images/local/*
Avant de faire n'importe quel changement, il faut se poser dans l'ordre les questions suivantes :
- Question 1 : Est-ce-que la modification concerne (hors fichiers spéciaux) pleade-libre, pleade-entreprise, pleade-mets; ainsi que l'ensemble des projets AJLSM.
- Question 2 : Est-ce-que la modification concerne (hors fichiers spéciaux) uniquement les fichiers spécifiques du projet.
- Question 3 : Est-ce-que la modification concerne un fichier spécial pour l'ensemble des variantes du projet (preprod, salle de lecture, internet, ...).
- Question 4 : Est-ce-que la modification concerne un fichier spécial mais uniquement pour une ou plusieurs variantes du projet.
- Question 5 : Est-ce-que la modification concerne n'importe quel fichier de la webapp (hors fichiers spéciaux) mais, pour un ou plusieurs variantes du projet.
Si la réponse à l'une de ces questions est oui, on n'aura pas besoin de vérifier les questions suivantes. En effet l'utilisation du script update et la mise à jour dépendra uniquement de la question sur laquelle on se situe.
Pour chaque cas, on détaillera les fichiers à modifier, le script à lancer ainsi l'endroit où il faut lancer la mise à jour du SVN.
Si on souhaite faire des changements dans plusiuers fichiers mais, ces fichiers répondent à des questions différentes. Dans ce cas, chaque fichiers doit satisfaire séparément à la procédure qui correspond à la question associée.
Méthode de travail pour la question 1
[modifier | modifier le wikicode]La question 1 signifie que l'on travail sur un élément qui va impacter l'ensemble des projets. Par exemple, une modification dans le fichier module-eadeac.xmap
Fichiers à modifier
[modifier | modifier le wikicode]Il faut travailler directement dans les sources SVN de pleade-libre, pleade-entreprise ou pleade-mets.
Mise à jour recette
[modifier | modifier le wikicode]Pour voir ses modifications, il faut lancer le script $ ./update.php ce dernier s'occupera de récupérer les modifications et de les placer dans la webapp. Il lancera aussi automatiquement le redémarrage du service tomcat
Le script rebuild.sh permet quand à lui de nettoyer complètement les sources; en plus de faire un update. Il est à utilisé au cas où le script update.sh semble ne pas mettre à jour les fichiers
Méthode de travail pour la question 2
[modifier | modifier le wikicode]la question 2 signifie que l'on souhaite apporter un changement global. Mais, uniquement pour le projet concerné. C'est le cas par exemple d'une modification de l'affichage des résultats de recherche.
Fichiers à modifier
[modifier | modifier le wikicode]Il faut travailler directement dans les sources SVN du projet
Mise à jour recette
[modifier | modifier le wikicode]Pour voir ses modifications, il faut lancer le script $ ./update.sh (ou ./rebuild.sh) ce dernier s'occupera de récupérer les modifications et de les placer dans la webapp. Il lancera aussi automatiquement le redémarrage du service tomcat
Méthode de travail pour la question 3
[modifier | modifier le wikicode]La question 3 signifie que l'on souhaite apporter une modification sur un fichier surchargé. C'est le cas par exemple des formulaires de recherche.
Fichiers à modifier
[modifier | modifier le wikicode]Ces fichiers peuvent être modifier en travaillant dans le tomcat, directement dans la webapp
Mise à jour recette
[modifier | modifier le wikicode]Les modifications sont visibles en live puisque l'on travail dans la webapp. Si ce n'est pas le cas, il faut relancer tomcat avec le script $ ./restart_tomcat.sh
À la fin des changements, il faut lacer le script $ update.sh (ou ./rebuild.sh) qui s’occupera de récupérer les changements pour les sauvegarder dans le répertoire surchage de la recette.
Il faut ensuite, placer ou faire un merge à la main des fichiers modifier dans les sources SVN du projet..Méthode de travail pour la question 4
[modifier | modifier le wikicode]La question 4 signifie que l'on souhaite travailler sur une surcharge d'une variante du projet. C'est le cas par exemple, si on souhaite modifier uniquement le fichier ead-documents-property-sets.xconf de l'application internet
Fichiers à modifier
[modifier | modifier le wikicode]Ces fichiers peuvent être modifier en travaillant dans le tomcat, directement dans la webapp.
Mise à jour recette
[modifier | modifier le wikicode]Les modifications sont visible en live puisque l'on travail dans la webapp. Si ce n'est pa le cas, il faut relancer tomcat avec le script $ ./restart_tomcat.sh
Méthode de travail pour la question 5
[modifier | modifier le wikicode]La question 5 signifie que l'on souhaite travailler sur une modification en dur du projet; mais, qui concerne uniquement une variante (eg. salle de lecture, internet, préprod). C'est le cas par exemple, si on souhaite modifier uniquement le fichier sitemap.xmap de l'application internet.
Fichiers à modifier
[modifier | modifier le wikicode]Il faut travailler directement dans les sources SVN du projet; ou bien de pleade-libre, pleade-plus ou pleade-mets
Mise à jour recette
[modifier | modifier le wikicode]Pour voir ses modifications, il faut lancer le script $ ./update.php ce dernier s'occupera de récupérer les modifications et de les placer dans la webapp. Il lancera aussi automatiquement le redémarrage du service tomcat.
Mise à jour des applications de production
[modifier | modifier le wikicode]Les applications de production sont mis à jour en faisant automatiquement un merge entre la webapp de l'application de recette; et les surcharges de la variante concernée. Avant de lancer une mise à jour production, il faut donc veiller à ce que la recette soit dans un état fonctionnel.
Pour faire une mise à jour, il suffit de lancer le script $ ./deliver.sh <nom de la variante>. Exemple, pour l'application internet des ad53, $ ./deliver.sh internet.
Le script s'occupe de préparer la webapp et de faire un dépôt (si possible) à la racine de l'utilisateur ajlsm du serveur de production. Il faut ensuite se placer à la racine du serveur de production et lancer le script $ ./update.sh <nom de la variante>. Par exemple, pour l'application internet des ad53, $ ./update.sh internet
Le script s'occupera de relancer automatiquement le tomcat. Les changements de la mise à jour devraient donc être visible immédiatement après l’exécution du script.
NB
- La mise à jour écrase la version sur le serveur de production avec celle se trouvant en recette. Il faut donc veiller à ce que les paramètres locaux (fcihiers spéciaux) sur le serveur de prod aient bien été récupérés dans le répertoire surcharge de la recette.
- Il peut exister des cas particuliers. par exemple, pour mettre à jour les applications internet-consultation et internet-digiwin des ad53, il faut lancer le script $ ./deliver_internet_consultation_et_digiwin.sh sur le serveur de recette. Ensuite, sur la production, lancer le script $ ./update_consultation_et_digiwin.sh .Les deux application sont mises à jour en même temps.
- Pour les applications, où le script ne peut pas déposer directement la webapp dans le serveur de production (exemple, ad64), à la fin du script deliver, il faut placer manuellement l'archive générée sur le serveur de production. Ensuite, on pourra lancer le script update depuis la production.