8000 Deploiement · v-l-m/vlm Wiki · GitHub
[go: up one dir, main page]

Skip to content
hb edited this page Feb 26, 2015 · 1 revision

VLM utilise depuis la 0.8 un mode de déploiement basé sur le subversion et par module. C'est décrit dans DeploiementTesting.

Les instructions de déploiement d'une version à l'autre sont décrites en général en détail dans le fichier hosting/UPGRADE.

#Principes L'usage, et les contraintes d'architecture ont permis de stabiliser les constats suivants :

  • on distingue 3 type d'unité de déploiement :

    1. MASTER le serveur maître, par ce que c'est le seul à héberger la récupération (principale) météo, le moteur et la base maître ;
    2. SLAVES les serveurs esclaves, qui ne sont concernés que par les autres modules
    3. ALL tous les serveurs (quand on parle de déployer les modules communs).
  • on distingue 3 temps d'installation :

    1. le pré-déploiement : avant de toucher au coeur de VLM
    2. le déploiement du coemur :
    • c'est la phase la plus sensible, qu'il faut faire le plus vite possible
    • les zones de risques sont au niveau des modifications faites en base et des possibles bugs dans le moteur.
    1. le déploiement du reste, partout.

Voir pour mémoire les tickets du component hosting.

Pas de prise en charge du cluster

Les scripts de déploiement s'appliquent sur un seul serveur. Pour les étapes portant sur les unités SLAVE ou ALL, c'est une perte de temps.

C'est le ticket #120. Il pourrait utiliser la sémantique MASTER / SLAVE / ALL

Pas de prise en charge automatique de la page d'indispo

La fonction de page d'indispo existe, mais n'est pas ou peu utilisée car :

  • Les déploiements sont courts (c'est plutôt une bonne nouvelle)
  • Elle n'est pas intégrée dans le module site.

Pas assez d'automatisation des déploiements

Pour les besoins d'urbanisation du développement, le code a progressivement été découpé en modules de plus en plus nombreux. Le nombre d'opération de déploiement de module a corollairement augmenté, alors que ce sont souvent des opérations par paquets.

  • On pourrait définir la notion de méta-module, le déploiement se faisant du back au front

    • module "front" = jvlm guest_map mobile site
    • module "middle" = lib/phpcommon lib/vlm-c moteur grib
    • module "back" = base hosting
  • On pourrait définir, pour une release donnée, des scripts qui automatisent au maximum les paquets de déploiement.

L'état du moteur n'est pas prise en compte par le déploiement

On ne devrait pas pouvoir déployer un module du middle ou du back si le moteur tourne.

Trop de reports de modifications d'un langage / techno à l'autre

C'est du au format des fichiers de conf. C'est le ticket #59.

Clone this wiki locally
0