Ce jeu d'outil fournit :

• Une méthode sécurisée de mise à jour, avec automatisation des copies de sécurité et capacité de rollback
• Un jeu de commandes simples pour faire les mises à jour/réception de livraison
• Une capacité “modulaire” de la livraison contrairement à une livraison compacte

• 1 serveur sous Linux (n'importe quelle distribution)
• le paquet subversion installé
• les données de proxy subversion configurées (voir la documentation de “subversion derrière un proxy”) si votre serveur n'a pas un accès direct à Internet.

Vous pouvez récupérer le jeu d'outils sur SVN à l'adresse suivante (après avoir eu accès par nos soins)

http://www.mylearningfactory.com/svn/moodlestore/branches/generic_delivery/prodscripts-moodle

• Créez un répertoire pour l'installation des outils et checkoutez l'URL ci-dessus dans le répertoire :

 mkdir /home/prodscripts/monprojet
 cd /home/prodscripts/monprojet
 svn co http://www.mylearningfactory.com/svn/moodlestore/branches/generic_delivery/prodscripts-moodle

Le fichier config doit être édité avant l'usage

  #!/bin/bash
  
  # Real physical dir of the code (absolute path)
  REALBASEDIR=/var/www/moodle-%MAJOR%-%HOSTNAME%
  
  # The dir of the real running alias
  BASEDIR=moodle-%MAJOR%-%HOSTNAME%
  
  # The SVN working name
  SVNDIR=${BASEDIR}-SVN
  
  # The name for the SAVE copy
  SAVEDIR=${BASEDIR}-SAVE
  
  # The name for the SUPERSAVE copy
  # The SUPERSAVE copy allows making long term super secured copy
  SUPERSAVEDIR=${BASEDIR}-SUPERSAVE
  
  # The name for the CVSD reading user
  # You will need to know the remote accepted password for that user
  SVNUSER=%SVNUSER%
  SVNPASS=%SVNPASS%
  
  # CVS Repository information. Not used for all commands 
  SVNREPO=%REPO%
  SVNROOT=http://www.mylearningfactory.com/svn
  MODULE= # obsolete
  BRANCH=%BRANCH%
  
  # Apache ownership
  FILESERVUSER=<moodleowninguser>
  FILESERVGROUP=<moodleowninggroup>

Le fichier de configuration travailla par défaut sur des schemas de nommage de type moodle-<major>-<hostname>, par exemple moodle-35-mondomaine pour un moodle en version 3.5. Vous pouvez adopter un autre standard de nommage si vous le souhaitez.

Nous vous avons communiqué :

• %REPO% : la valeur du dépot que vous utiliserez
• %BRANCH% : la branche de code qui vous correspond
• %SVNUSER% : L'utilisateur du dépot qui vous est attribué
• %SVNPASS% : le mot de passe associé à cet utilisateur

La configuration des outils prévoit que :

• Moodle soit implanté dans un répertoire quelconque du serveur (suivant la distribution ou les habitudes de l'admunistrateur système). Ce réperoire doit être vide lors du premier checkout.
• Le répertoire des outils contient un lien symbolique vers le répertoire d'installation de Moodle (BASEDIR)
• Le répertoire es outils contient deux répertoires de copie de code de sécurité (SAVEDIR et SUPERSAVEDIR) destinés à stocker des backups de la base de code moodle pendant les livraisons. (il est d'usage de reprdendre le nom du lien symbolique suivi respectivement de -SAVE et -SUPERSAVE
• Le site Moodle opérationnel soit rooté sur le répertoire symbolique, dans le répertoire des outils. Ceci permet au site de continuer à fonctionner sur la copie de sauvegarde pendant les opérations “d'update” à partir du dépôt, et sans que des mises à jour partielles ne viennent déstabiliser le code.

Une fois le fichier de configuration configuré :

Si tout est correct vous descendez la totalité du contenu du répertoire de livraison.

Une fois le checkout effectué, vous devez ramener ¹⁾ le registre svn dons votre répertoire d'outils :

 ''cp -r moodle-<major>-<hostname>/.svn .'' 

Effectue une synchronisation de sécurité entre le répertoire d'exploitation et le répertoire de sécurité -SAVE. Ceci assure que le répertoire de sécurité contient une copie strictement conforme au code en cours d'exploitation, et peut donc prendre sa place sans altération du service.

Bascule la base de code pour mise à jour. Le répertoire original d'exploitation est suffixé par -SVN pour se mettre en face du dépôt. Le répertoire de sauvegarde -SAVE prend la place du répertoire d'exploitation, mettant le code de sauvegarde en face du serveur Web. Les mises à jour sont possible, et le site en exploitation fonctionne normalement.

Effectue tout ou partie de la mise à jour de code. La commande peut être dirigée vers un composant particulier ou n'importe quel point de l'arborescence moodle.

Exemple:

 ./update admin/tool

mettra à jour toutes les modifications de tous les outils d'administration.

Bascule les bases de code pour rétablir la position normale d'exploitation. Le répertoire -SVN temporaire servant aux livraisons est rétabli comme le répertoire principal d'exloitation. Cette opération entraînera la mise en production effective des modifications, avec le cas échéant la nécessité de procéder à la mise à jour logique du modèle de données de moodle (Administration du site > Notifications). Il est donc conseillé de procéder à une sauvegarde de la base de données avant cette opération pour les livraisons dont le périmètre de modification peut être important.

Les mises à jour peuvent être classées dans les cas suivants, en fonction de leur capacité de réversibilité :

• Mise à jour mineure de code sans mutation du modèle de données ou des définitions liées à la version (capacités, événement, modèle de données) ⇒ Réversibilité complète immédiate
• Mise à jour mineure avec mutation locale du modèle de données réversible (la réversibilité suppose que l'ancien code peut opérer le nouveau modèle de données sans faute) ⇒ Réversibilité immédiate
• Mise à jour mineure ou majeure avec modification non réversible u modèle de données ⇒ Réversibilité après réintégration de la sauvegarde de données.

Procède aux mises à jour directes des modification dans la base en exploitation (REALBASEDIR). Les modifications directement descendues ne sont pas intégrées à la copie de sécurité courante.

Remonte les éventuelles modifications locales de fichiers dans le dépôt SVN. Cette pratique est fortement déconseillée (voir ci-après).

Réalise une double copie de sécurité dans les répertoires -SAVE et -SUPERSAVE. Ceci peut être utile lors d'une phase de transformation itérative complexe de moodle. (cas rare)

Les procédures suivantes permettent d'opérer les opérations courantes de mise en place de code, pourvu que la configuration soit correcte. Le point de départ des commandes est dans le répertoire des outils.

 ./checkout    (1)
 cp -r moodle-<major>-<hostname>/.svn .
 ./syncback    (2)

1) Récupération de la base de code complète (la première fois) 2) Création de la copie de sécurité

 rm -rf moodle-<major>-<hostname>/*       (1)
 rm -rf moodle-<major>-<hostname>/..?*      (2)
 rm -rf moodle-<major>-<hostname>/.[!.]*     (2)
 ./checkout
 cp -r moodle-<major>-<hostname>/.svn .
 ./syncback

1) Détruit tous les fichiers de l'ancienne base de code 2) Supprime tous les fichiers et répertoires cachés de l'ancienne base de code

 ./syncback       (1)
 ./goback         (2)
 ./update         (3)
 ./svntoprod      (4)

1) Resynchronise la copie de sécurité 2) Bascule l'exploitation sur la copie de sécurité 3) Met à jour la copie d'exploitation relâchée 4) Bascule les modifications en exploitation

 ./syncback
 ./goback
 ./update mod/module1
 ./svntoprod

La mise à jour partielle fonctionne sur un container de plugins ou un ensemble de plugins nommés par wildcard, par exemple :

 ./syncback
 ./goback
 ./update mod/*
 ./svntoprod

 ./syncback
 ./goback
 ./update repo   (1)
 ./svntoprod

1) Fera toutes les mises à jour dans les containers report et repository

 ./syncback
 ./goback
 ./update ./index.php
 ./svntoprod

 ./pull mod/module1     (1)

1) Réalise en une seule commande le cycle de mise à jour partielle sur le composant spécifié.

Il est en général déconseillé de modifier les fichiers directement sur le serveur. Mais le caspeut survenir :

• Lors d'un débugage “in situ” sur un site de qualification/recette
• Lors d'un débugage d'urgence sur une situation de production critique.

Les risques principaux de la modification locale des fichiers sur le serveur d'exploitations sont :

• La perte de la modification lors d'une mise à jour ultérieur
• La création d'un conflit SVN qui peut bloquer le fonctionnement complet de la plate-forme (s'il est mal placé)

Néanmoins, si exceptionnellement des modications locales ont été apportées, il convient de les remonter directement dans le dépôt :

 ./commit mod/module1

Il est possible lors d'une migration importante, de mettre directement en production un ensemble de modifications préalablement qualifiés sur un environnement de pré-recette.

 ./directupdate

ou

 ./directupdate mod/module1
 

Guide de démarrage/FAQ sur Moodle - Catalogue des services - Aller à l'index des plugins -