ProcedureDeploiement < Jmmc/Software

Tags: view all tags
---+!! <center>Déploiement des Logiciels du JMMC</center>
%BR%

%TOC%



---+ Doc au 11-12-14

---++ Deploiement des applications JMCS:
   * rapatrier le module adm-tools: 
   * rajouter dans son PATH le chemin vers adm-tools/bin:
   * installer le parent-pom JMCS
   * lancer admManager.sh pour obtenir de l'aide et proceder à l'installation des logiciels

<verbatim>
cd $MY_PATH
svn checkout https://svn.jmmc.fr/jmmc-sw/ADM/trunk/adm-tools

source adm-tools/bin/env.sh

svn checkout https://svn.jmmc.fr/jmmc-sw/MCS/trunk/jmcs/parent-pom/
cd parent-pom
mvn -Dassembly.skipAssembly -Djarsigner.skip=true clean install
cd .. 
rm -rf parent-pom

admManager.sh
</verbatim>

   Note: Un repertoire du même nom que le logiciel à installer est créé dans le repertoire courant (à moins que l'option -d ne soit fourni)
   Note: Certains artifact maven sont a installer manuellement

Sur jmmc.fr, la conf des clés et profile par defaut se trouve dans /home/soft/local/apache-maven-3.1.1/conf/settings.xml

---+ Doc probablement pas à jour et à rebasculer ci-dessus

---++ Philosophie

   * Le tronc contient toujours la dernière version de développement du logiciel en question.
   * Les versions déployées le sont toujours depuis une version taggée.
   * Ces règles d'hygiène sont de la responsabilité de chacun, pour garantir une traçabilité sans faille de nos développement.

---++ Logiciels
Version générée automatiquement par le script de déploiement ==mkfRepoUtil==:

%INCLUDE{"http://apps.jmmc.fr/releases/deploymentConf.txt"}%

---++ Procédure Générique

   * Chaque logiciel est composé d'un ou plusieurs modules, archivés en configuration sous [[https://svn.jmmc.fr][SVN]] (visibles avec la commande ==# mkfRepoUtil info !AppLauncher==);
   * Chaque logiciel est déployé sous un compte utilisateur dédié sur notre serveur (voir [[#Logiciels][tableau]]).

   * Pour déployer une version alpha/bêta d'un logiciel (par exemple _AppLauncher_), il faut:
      1 installer dans un compte de test les versions 'tronc' de ses modules et ses dépendances avec: ==# mkfRepoUtil install !AppLauncher==
      1 tester cette version en profondeur : __si des problèmes subsistent, corriger dans le tronc__, er recommencer.
      1 une fois validé, vous pouvez tagger la version courante avec la commande ==# mkfRepoUtil -v AL_V1_0_1b1 tag !AppLauncher==

   * Pour déployer une version finale d'un logiciel (par exemple _AppLauncher_), il faut:
      1 tagger les versions 'tronc' de ses modules et ses dépendances avec: ==# mkfRepoUtil -v AL_V1_0_1 tag !AppLauncher==
      1 installer sur le compte de production (voir [[#Logiciels][tableau]]) la version taggée de ses modules et ses dépendances avec: ==# mkfRepoUtil -v AL_V1_0_1 install !AppLauncher==

   Note: l'action ==tag== du script ==mkfRepoUtil== effectue un remote tag (svn) donc travaille sur le tronc.

---++ Spécificités Aspro2
La configuration d'Aspro2 est incluse dans le projet ASPRO2, mais elle peut être mise à jour de manière indépendante en 'installant' une version taguée du projet ASPRO-conf. 

Pour mettre à jour la doc de conf:
   * ssh swmgr@jmmc.fr
   * cd public_html/AsproOIConfigurations
   * ./update.sh

---++ Spécificités SearchCal (dépendance à MCS)
---+++ Pour la beta
1) Mettre la version de développement de MCS:

<verbatim>
MCSTOP     = /home/MCS
MCSDATA    = /home/MCS/data
MCSRELEASE = DEVELOPMENT
MCSROOT    = /home/MCS/DEVELOPMENT
MCSENV     = default
INTROOT    = 

# su - swmgr
# cd mcsins
# svn up
# cd src
# make all install
# cd ../..
# ./mcsinsInstall -u
# exit
</verbatim>

2) Mettre en ligne la beta:

<verbatim>
# su - betaswmgr
# mkfRepoUtil install SearchCal
# ### kill du serveur
# ./sclws.sh
# mkfRepoUtil -v SC_V4_5b1 tag SearchCal
# exit
</verbatim>

---+++ Pour la mise en production
En attendant la refonte, voir [[http://ipag.obs.ujf-grenoble.fr/twiki/bin/view/Jmmc/Software/SearchCalInstallation]].

---+ Astuces

   * Lors du déploiement des versions de production, recopier dans l'applicationData.xml l'element pubDate associé. Les releases notes des versions de prod et beta seront ainsi synchronisée.


---+ Notes d'installation de MCS en mode single user / no MCSROOT en vue d'une installation "isolée" du serveur SearchCal

---++ Sur Ubuntu 12.04 64bits


---+++ Prerequis MCS
   * Installer la config de base:
<verbatim>
# install build material
apt-get install aptitude g++ tclx xsltproc libgdome2-dev svn subversion java7-sdk xmlstarlet

# fix enable directives in Makefiles 
sudo rm /bin/sh ; ln -s /bin/bash /bin/sh
# avoid script name change
sudo ln -s /usr/bin/xmlstarlet /usr/bin/xml
# enable java deploiement copy
sudo mkdir -p /var/www/html/jnlp/jar/original
sudo chmod -R a+w /var/www/html/jnlp/jar/
</verbatim>

   * Ajouter les variables dans le .bashrc (en fait un .bash_mcs chargé par le bashrc):
<verbatim>
# To help mkfMakefile find header glibconfig.h
export USER_INC=$(pkg-config --cflags glib-2.0)

# to help compilation and runtime execution
export USER_LIB="-L/lib -L/usr/lib"
export LD_LIBRARY_PATH=/lib:/usr/lib:${LD_LIBRARY_PATH}

# mandatory variables :
export INTROOT=$HOME/INTROOT
export MCSTOP=$INTROOT
# source main configuration script 
. ~/mcs.sh
</verbatim>
   * Installer mcsins pour installer l'INTROOT et les fichiers de conf de base
<verbatim>
svn co https://svn.jmmc.fr/jmmc-sw/MCS/trunk/mcsins
make -C mcsins/src
</verbatim>
Pour se faciliter la vie lors des deploiements java, recopier du serveur principal le fichier à déposer dans INTROOT/etc/keystore.key.

---+++ Prerequis SearchCal
<verbatim>
# install build material
apt-get install gsoap uuid-dev
</verbatim>


---+++ Lancement de la compilation
Récupérer mkfRepoUtil et lancer:
=mkfRepoUtil MCS SearchCal=

---++++ Modifs de codes (commitées)
du fait d'une config gcc plus stricte:
   * reordonnancement des librairies pour la compilation
   * ajouts d'includes manquant
      * ex :miscLocateFile_LIBS      = misc err log mcs
      * ubuntu "11.10 uses the ld flag --as-needed by default now. This requires the libraries beeing behind the objects needing their symbols on the command line."

---++++ Modifs manuelles
   * Execution test SearchCal:
      * Le proxy empeche certaines requetes Vizier de bien fonctionner. Il faut supprimer la variable d'environnement http_proxy
   * Le fichier wsdl généré par soapcpp2 V2.8 n'a plus le meme namespace qu'en V2.7... une copie de l'ancien permet de compiler le reste de sclgui sans problème

--- Pour tester:
ssh jmmc@gag8129 mdp habituel

---++ Migration MAVEN
En vue de la diffusion !OpenSource de jMCS, la construction de ce module est passé sous Maven.
JAE est la première application à être passée sous Maven aussi.

Pour les autres, voici le recensement des spécifiés de construction:
|| ** || *AppLauncher* || *SearchCal* || *OIFitsExplorer* || *Aspro2* || *LITpro* ||
|| *Dépendances* || jmcs smptest smprsc smprun||jmcs jmal sclws sclgui || jmcs jmal oitools oiexplorer-core oiexplorer || jmcs jmal oitools oiexplorer-core aspro-conf aspro || jmcs jmal oitools oiexplorer-core mfgui ||
|| *User Manual* || jmcsHTML2HelpSet JMMC-MAN-2220-0001 smprun-doc.jar || jmcsHTML2HelpSet JMMC-MAN-2600-0001 sclgui-doc.jar || ? || ? || ? ||
|| *Main Class* ||fr.jmmc.scalib.smprun.AppLauncher||fr.jmmc.sclgui.SearchCal / fr.jmmc.sclgui.SearchCalDiffTool || fr.jmmc.oiexplorer.OIFitsExplorer || fr.jmmc.aspro.Aspro2 || fr.jmmc.mf.gui.LITpro ||
|| *JAXB* || smprsc/src/build-java.xml|| - || - || aspro/src/build-java.xml || - ||
|| *jmcsDeployJnlp* || AppLauncher.jnlp || SearchCal.jnlp / SearchCalDiffTool.jnlp || OIFitsExplorer.jnlp || Aspro2.jnlp || LITpro.jnlp ||
|| *Specifics* || - || - || - || - || ./mfguiGenerateClasses.sh ||


---+++ Essais
---++++ Pom parent
   * TODO
      * tester et activer la production des big-jar seulement en mode profile deploiement (peut-etre uniquement pour les applis finales )
      * dans le cadre de nos developpements la notion de version n'est pas utile puisque par convention, nous souhaitons utiliser les dernieres version du tronc de l'ensemble des modules. Utiliser donc LATEST  ou HEAD systematiquement pour les versions sous les troncs svn : cf http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency
      * tester une installe avec des versions conflictuelles d'une meme dependance

---++++ Astuces
   * mvn help:effective-pom -> indique la conf globale

---++++ A voir/tester:
   * Projets multi-modules : http://maven.apache.org/pom.html#Aggregation
   * remplacer l'ensemble des versions TRUNK par une propriété (definie par defaut a TRUNK dans le parent-pom) surcahrgeable pour par ex la distribution d'un soft

---+++ Deploiements:
   * les releases doivent etre réalisé par le script de deploiement qui:
      * recupere une version du tronc
      * remplace les version des pom
   * un repertoire unique par projet avec toutes les dependance JNLP incluses
      * les commons peuvent etre en URL absolues
   * les deploiements doivent etre tracable (info svn dans le MANIFEST,  ???)
   * synchroniser les infos entre l'ApplicationData.xml et les propriétés utilisées pour generer les attributs du MANIFEST, pom....
   * les "shared" libs géré à la main (installé par mvn process-ressource) doivent être invariantes : il ne faut pas committer une lib sous un meme numero de version.
Topic revision: r18 - 2017-06-19 - CharleenKemps