Les opérations décrites ci-dessous sont pour la plupart effectuées depuis l'interface graphique du panneau d'administration des serveurs VDS. Seules, les commandes complémentaires en ligne de commande seront détaillées.

Le service test

Ce service est destiné à l'adaptation et à la mise au point du logiciel OpenERP avant toute mise en production.

Le paramétrage du service test permet habituellement de récupérer un code d'OpenERP et d'y appliquer des adaptations. Pour récupérer du code, on peut télécharger ce code depuis un serveur internet (wget), lire un système de gestion de révisions (bazaar, git, mercurial) ou encore utiliser une recette buildout. Pour adapter le code ainsi chargé, on peut organiser les changements dans un répertoire appelé specific, afin que ces changements soient automatiquement ré-appliqués en cas de récupération d'un nouveau code.

Le programme qui est en charge de rejouer des séquences de modifications sur du code OpenERP s'appelle poe. Son utilisation est optionnelle. Cet article ne détaillera pas l'outil poe (poe --help) utilisé par xoe lors des fonctions de mise à jour des services.

Une fois ce code chargé et modifié, on peut lui faire subir des tests jusqu'à validation du résultat qu'on souhaite passer en production. Un dernier test permettra le cas échéant de contrôler la capacité de la base de données en production d'être mise à jour et de s'adapter aux nouveautés apportées au service test. Pour cela, copier la base de production vers test et utiliser la fonction update de la base.

Le service production

Ce service est destiné à l'utilisation réelle. Les opérations sur production sont effectuées avec le maximum de précautions.

Pour s'assurer de la parfaite identité du code de production et du code testé sur le service test, on peut remplacer la configuration la récupération du code de production afin de copier directement le code de test.

Dans la configuration de xoe :

xoe --config -edit

Les exemples ci-dessous désignent les services par les noms production, formation et test complétés de la référence contrat -aaaa-nnnn. Vous devez remplacer -aaaa-nnnn par vos propres références.

Commenter les lignes qui commencent par

directory:production-aaaa-nnnn:

et ajouter une ligne avec les instructions suivantes :

directory:production-aaaa-nnnn: Auto copy /home/sisalpuser/openerp/test-aaaa-nnnn/server server

et exécuter la mise à jour du code par la fonction upgrade qui procédera au réalignement automatique le code du service production sur celui du service test.

Le service formation

Le service formation sert à l'entraînement des utilisateurs sur une copie de la base de production et un code séparé du code de production afin d'éviter toute interférence.

La aussi, la synchronisation du code du service formation peut être automatisée, en indiquant dans la configuration xoe :

xoe --config -edit

de copier le code de production sur le service formation en cas d'upgrade depuis le panneau d'administration :

directory:formation-aaaa-nnnn: Auto copy /home/sisalpuser/openerp/production-aaaa-nnnn/server server

Cet article ne détaille pas comment on peut automatiser la copie quotidienne des bases de données de production sur le service de formation. Pour cela consultez la documention du fichier de configuration :

xoe --config -help

Quelques questions complémentaires

Particularités des environnements python (virtualenv)

Si vous utilisez des environnements python définis dans la configuration de xoe, les opérations décrites ci-dessus dupliqueront automatiquement l'environnement et le code. Les fonctions upgrade et downgrade du panneau d'administration sont inchangées.

Ai-je besoin de l'étape de test si je déploie automatiquement depuis un serveur de développement et de test ?

Je pense que oui et vous encourage à le penser aussi (je vous l'aurai dit ;-) ).

En théorie, il n'y a jamais de raison pour qu'un programme ne se comporte pas comme il devrait le faire, ou se comporte différemment sur un serveur de développement et le VDS de production.

Dans la pratique, un programme ne peut être validé que s'il s'exécute dans un contexte parfaitement identique au contexte final de production.

Quelque soit la qualité de votre travail en amont, revalidez la solution d'ensemble sur le VDS et son service test avant de "presser sur le bouton" sur le service production et les données vivantes de l'entreprise.

Pourquoi utiliser le service de formation plutôt qu'un base séparée sur le service production ?

Une personne en formation doit pouvoir faire des erreurs sans risque pour les données de l'entreprise. Même si le service production supporte plusieurs bases, le code est unique. En téléchargeant un module, on modifie ce code pour toutes les bases du service. Il en est de même pour le stockage des documents externes à la base qui ne sont pas dupliqués et indépendants d'une base à l'autre.