Subversion (http://subversion.tigris.org/) est un outil de versioning puissant. Basé sur un modèle centralisé, il a l'avantage de rester relativement simple.
L'utilisation d'outil de versioning chez les développeurs s'est aujourd'hui réellement généralisé, au point que faire sans n'est maintenant plus envisageable.
Pour le métier de l'exploitant pourtant, l'utilisation de tels outils libres et open sources semble tarder à venir. Pourtant c'est une pratique qui peut faciliter grandement la vie de l'exploitant ... à l'utilisation l'exploitant devrait même être logiquement encore plus gourmand et exigeant quant aux possibilités de tels outils ...
Ce chapitre décrit l'installation d'un logiciel/application (ici ori-oai-workflow) en utilisant subversion (de sourcesup). Puis il montre comment subversion peut aider l'exploitant à mettre à jour son application tout en conservant les modifications qu'il aura apportées dans les configurations, voir dans le code de l'application !
Nous proposons ici d'installer ori-oai-workflow, de le configurer puis de le mettre à jour avec l'outil subversion.
Ce principe peut être bien sûr adapté à l'installation d'autres applications disponibles via subversion (comme les différents modules ORI-OAI, mais pas seulement) et aussi à d'autres outils que subversion comme CVS, mais aussi des outils plus puissants comme Mercurial (http://www.selenic.com/mercurial/), qui bien utilisé, amènerait d'ailleurs encore bien plus de possibilités que subversion pour l'exploitant ...
Checkout d'ori-oai-workflow 0.8.3
Plutôt que de télécharger une version d'ori-oai-workflow sous forme d'archive, on télécharge ici la version taguée dans le subversion de sourcesup.
Comprenez bien qu'ici on se place en tant qu'exploitant, on utilise donc le subversion en mode anonyme, donc sans avoir les droits d'écriture sur le repository.
De plus, on préfère l'utilisation de subversion en ligne de commande via la commande svn sur un serveur linux (a priori pour ce genre d'opération, vous serez connecté sur un serveur distant sans Interface Graphique, en SSH).
sourcesup propose 2 modes de navigation dans un repository subversion :
- via viewvc (http://sourcesup.cru.fr/cgi/viewvc.cgi/?root=ori-workflow) : propose une navigation agréable dans le repository svn : coloration syntaxique du code, logs, etc
- directement via l'interface dav-svn (apache) de subversion avec l'url suivant http://subversion.cru.fr/ori-workflow/ : c'est cette dernière url qui permet à l'outil client svn de venir synchroniser votre répertoire d'installation avec le repository svn distant.
=> Pour l'exemple on récupère via svn ("checkout") la distribution ori-oai-workflow-0.8.3 grâce à l'url :
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3/
L'idée étant de mettre à jour ori-oai-workflow au fur et à mesure des nouvelles versions, dans un dossier nommé ori-oai-workflow-svn (en omettant donc le numéro de version).
Voici la commande checkout à faire depuis le dossier [INSTALLATION:ORI_HOME]/src:
svn checkout http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3 ori-oai-workflow-svn
Copie d'écran :
L'ensemble des fichiers est ainsi récupéré un à un et ajouté (le A signifiant Add) pour la première fois à votre répertoire d'installation.
Configurations d'ori-oai-workflow 0.8.3
Les documentations d'installation aidant, on modifie les fichiers build.properties et conf/properties/main-config.properties pour que cela corresponde à nos besoins propres.
Rapidement, une nouvelle capture d'écran montrant l'édition de ces fichiers :
Une fois fait, svn est capable de nous résumer les modifications via la commande :
svn status
Les fichiers listés avec M indique que ces fichiers ont été modifiés (Mpour Modify).
Une commande svn diff permet de visualiser les différences apportées par rapport à la distribution originale.
Exemple d'un diff sur build.properties :
Ce sont des fichiers de diff classiques qui en ressortent : les + et - indiquent si la ligne est ajoutée/modifiée par rapport à la distribution originale.
Bien sûr ici, et notamment pour le module ori-oai-workflow, l'exploitant va configurer un bon nombre de fichiers, modifier les css, les logos etc.
Ensuite il déploiera l'application dans un Tomcat (cf. le build.properties) ... et viendra le temps de la mise à jour ... !!
Mise à jour d'ori-oai-workflow : 0.8.3 -> 1.0.0
Un svn info nous permet de constater que nous sommes bien sur le tag 0.8.3, c'est à dire sur l'url:
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-0.8.3
Mettre à jour ori-oai-workflow, c'est ici le passer (on dit qu'on le switch) de 0.8.3 à 1.0.0.
Cette manipulation subversion peut avoir des effets non contrôlés, c'est une manipulation qui suivant les cas peut être délicat.
Pour plus de sûreté, on propose avant de faire un switch de sauvegarder l'ensemble du répertoire ori-oai-woirkflow-svn, on peut faire un tar-gz par exemple simplement :
tar czf ori-oai-workflow-svn-backup.tgz ori-oai-workflow-svn
On récupèrera la nouvelle url correspondant à la version 1.0.0 via un navigateur : ici, c'est
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/tags/ori-oai-workflow-spring-1.0.0
Donc depuis le répertoire ori-oai-workflow-svn on peut procéder au switch :
Le U nous indique ici les fichiers directement mis à jour,
Le A les fichiers ajoutés,
Le G les fichiers mis à jour qui ont nécessité une résolution de conflits car modifiés à la fois par l'exploitant et le développeur.
Les fichiers marqués en G sont donc usuellement à vérifier rapidement : on vérifie leur intégrité, on peut pour cela utiliser la commande svn diff pour voir les différences entre le fichier de l'exploitant et le fichier original de la version 1.0.0 d'ori-oai-workflow (la plupart du temps, on peut faire confiance à subversion et au développeur qui a conscience du procédé mis en œuvre et qui agit au niveau du développement en conséquence ....).
Ici il n'y a pas de conflit (marqué C) et donc tout s'est extrêmement bien passé. A priori il n'y a pas grand chose à faire de plus pour cette mise à jour (mis à part bien sûr suivre les indications de la documentation : faire pour le workflow un ant upgrade par exemple ici puis redéployer l'application).
L'avantage ici est que l'on n'a pas eu à recopier et répercuter soit même les modifications de configuration entre une ancienne et une nouvelle.
Cependant, et même si le développeur, en connaissance de cause, prend garde à faire en sorte que ces switchs se passent au mieux, il se peut que l'on rencontre parfois des "conflits".
Mise à jour d'ori-oai-workflow : conflits !
Comme dit ci-avant, usuellement lorsque le développeur y prend garde, il est normalement rare d'aboutir à un conflit. Mais cela arrive tout de même, notamment lorsque (contrairement au paragraphe ci-avant) à la fois
- un certain nombre de modifications entre 2 versions ont été faites côt développement
- un certain nombre de configurations/personnalisations ont été faites côté exploitation
Ici on se met dans une situation où on aura lors du switch un conflit.
Pour cela on se place comme un exploitant qui a chargé via svn le tag 0.6.4 de ori-oai-workflow et qui a modifié quelques fichiers de configurations et autre, notamment le fichier CSS WebContent/media/ori-addon.css :
On procède au switch vers le tag 1.0.0 directement :
Dans la copie d'écran, on ne donne pas le listing complet, mais la plupart des fichiers sont notés U, d'autres A, quelques uns G et surtout le fichier WebContent/media/ori-addon.css est noté C.
On peut d'ailleurs retrouver les fichiers notés C via un svn status :
L'édition de ori-addon.css pour une résolution manuelle du conflit est impératif.
Ici une modification a été faite en parallèle par le développeur et par l'exploitant. On peut retrouver les différentes versions de ce fichier dans les fichiers nommés ori-addon.css.*
Dans le fichier ori-addon.css on retrouvera les caractères <<<<<<<, ======= et >>>>>>> nous permettant d'identifier les régions du ou des conflits.
=> finalement on modifiera simplement ici
<<<<<<< .mine
background: red url( ../media/icons/door_out.png ) no-repeat left center;
border: solid 1px #999999;
=======
background: transparent url( ../media/icons/door_out.png ) no-repeat left center;
border: none;
>>>>>>> .r471
par
background: red url( ../media/icons/door_out.png ) no-repeat left center;
border: none;
par exemple.
Les conflits résolus, on supprimera alors les fichiers ori-addon.css.*.
Conclusion
Bien utilisé à la fois au niveau du développeur que de l'exploitant, subversion peut devenir une arme redoutable pour l'exploitant également (et non plus pour le développeur uniquement).
Pour certaines applications comme ori-oai-workflow qui permet une configuration fine et poussée via la modification de fichiers de configuration, l'exploitant a tout intérêt à utiliser et exploiter au maximum subversion ... côté exploitation !