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.
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2017-06-19 - CharleenKemps
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback