Déploiement des Logiciels du JMMC

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

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

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:

Failed to include URL http://apps.jmmc.fr/releases/deploymentConf.txt Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)

Procédure Générique

• Chaque logiciel est composé d'un ou plusieurs modules, archivés en configuration sous SVN (visibles avec la commande # mkfRepoUtil info AppLauncher);
• Chaque logiciel est déployé sous un compte utilisateur dédié sur notre serveur (voir 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
  2. tester cette version en profondeur : si des problèmes subsistent, corriger dans le tronc, er recommencer.
  3. 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
  2. installer sur le compte de production (voir 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:

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

2) Mettre en ligne la beta:

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

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:

# 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/

• Ajouter les variables dans le .bashrc (en fait un .bash_mcs chargé par le bashrc):

# 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

• Installer mcsins pour installer l'INTROOT et les fichiers de conf de base

svn co https://svn.jmmc.fr/jmmc-sw/MCS/trunk/mcsins
make -C mcsins/src

Pour se faciliter la vie lors des deploiements java, recopier du serveur principal le fichier à déposer dans INTROOT/etc/keystore.key.

Prerequis SearchCal

# install build material
apt-get install gsoap uuid-dev

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.