Gestion des versions des objets d'ordonnancement avec Git

De SOS Paris
Aller à : navigation, rechercher

OpenSource JobScheduler utlise des fichiers XML pour stocker les objets d'ordonnancement. Si ce système étonne, au premier abord, les habitués de la base de données, il s'avère finalement très efficace.

Utiliser de simples fichiers à la place d'une base permet:

  • de copier et dupliquer facilement les objets
  • de créer des objets à la volée même à partir d'un simple batch
  • de synchroniser les fichiers avec des outils natifs au système (Robocopy Windows ou Rsync Unix)
  • de ne pas subir de problème d'intégrité (au démarrage du moteur, les objets sont réorganisés)
  • etc, car la liste est loin d'être exhaustive

Gérer les versions d'objets revient à gérer les gestions de fichiers, il existe pour cela de nombreux outils conçus à l'origine pour gérer les codes sources.

Nous privilégions GIT qui s'installe simplement par copie de fichiers et qui propose un mode local pouvant être déporté sur un serveur distant. La complexité de l'utilisation est donc progressive et évolue avec ses besoins.

Créer un référentiel

On veut sauvegarder le répertoire live qui contient les objets mais l'astuce consiste à considérer plutôt le répertoire config pour 2 raisons:

  • si je crée un référentiel dans live, le moteur va prendre en compte les sauvegardés comme de nouveaux objets
  • prendre l'ensemble des objets permet de visualiser les changements des configurations de job mais aussi identifier les changements de configuration du serveur

Créons un répertoire configgit dans %SCHEDULER_DATA% (windows) ou $SCHEDULER_DATA (unix):

cd %SCHEDULER_DATA%
mkdir configgit

Initialisons le référéntiel:

cd configgit
git init
Initialized empty Git repository in V:/xampp56/jobscheduler/arii/configgit/.git/

On va maintenant copier l'ensemble des fichiers de configuration:

xcopy /s ..\config

On dispose maintenant d'une copie du répertoire, l'utilisation de cette copie permet simplement d'effectuer les tests sans aucun impact sur l'exécution du moteur.

On ajoute l'ensemble des fichiers, nous aurions pu nous limiter aux fichiers XML mais comme tout est potentiellement modifiable dans ce répertoire, il est plus prudent de tout prendre:

git add *

On va maintenant exécuter un commit pour avoir une image:

git commit -m "Ma configuration initiale"

Notre référentiel contient une sauvegarde de l'ensemble des fichiers.

Modification des fichiers

Ajoutons un fichier:

echo test > nouveau_fichier.txt

On ajouter ce fichier dans le référentiel:

git add *

On "commit":

git commit -m "nouveau fichier"
[master 33bf293] nouveau fichier
 1 file changed, 1 insertion(+)
 create mode 100644 nouveau_fichier.txt

Il est possible de visualiser l'historique:

git log
commit 33bf2933a42dcdd3db85d046cc1ddc2662924c14
Author: Eric Angenault <eat@vaudoise.ch>
Date:   Mon Nov 21 10:38:46 2016 +0100

    nouveau fichier 

commit 3b7c924789c4cf699b0b8ecf5341a698ee8030d6
Author: Eric Angenault <eat@vaudoise.ch>
Date:   Mon Nov 21 10:35:37 2016 +0100

    Ma configuration initiale

Modifions le nouveau fichier:

echo Nouvelle ligne >> nouveau_fichier.txt

Et intégrons le dans une nouvelle image:

git add *
git commit -m "Modification du fichier"

Retour arrière

Le contenu de notre fichier nouveau_fichier.txt est actuellement:

test
Nouvelle ligne

Si cette dernière modification ne convient pas, on peut revenir à une image précédente en indiquant l'identifiant listé dans le git log:

git checkout 33bf2933a42dcdd3db85d046cc1ddc2662924c14

Note: checking out '33bf2933a42dcdd3db85d046cc1ddc2662924c14'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 33bf293... nouveau fichier

Vérifions le contenu de nouveau_fichier.txt:

test

La modification d'un seul fichier n'est pas spectaculaire mais lorsqu'il s'agit d'une mise en production de plusieurs dizaines de fichiers ou qu'il faut revenir plusieurs jours en arrière cela devient nettement plus convaincant.