eyrolles_prod.tex

\subsection{Processus de livraison}
\label{section:eyrolles_prod}

Une livraison d'\aey\ consiste à installer la version du site sur le serveur du client. C'est une tâche qui nécessite de la rigueur : en effet, il faut s'assurer que l'application fonctionne aussi bien sur le serveur de destination qu'en local et qu'elle n'engage pas de régression due au changement d'environnement, au risque d'exaspérer le client.

Ainsi, afin d'en garantir la qualité, la livraison d'\aey\ suit un processus qui se déroule en plusieurs étapes.

La première impose de marquer la version de l'application à livrer : cela permet de garder un historique des livraisons. La méthode employée consiste à créer un \emph{\atag} sur le dépôt \asvn, qui est en fait une copie à un instant~$t$ de la branche de développement.

La deuxième étape concerne l'installation de l'application sur un serveur dit \emph{de \astaging} interne à \asl. C'est un \avserver\ particulier utilisé pour présenter aux clients, lors de la phase de recette, les sites web développés. Dans le cas du projet, il sert de passerelle pour installer le \alotdeux\ sur le serveur d'\aey : en effet, c'est la seule \og machine \fg\ autorisée à s'y connecter. Aussi, l'intérêt du serveur de \astaging\ est de simuler l'installation et la configuration d'une application, afin de se préparer pour la livraison réelle. Le \alotdeux\ de l'\aintranet\ d'\aey\ a donc été testé sur le \astaging\ avant chaque livraison.

Une fois l'application opérationnelle sur \astaging, tous les fichier sont transmis au serveur d'\aey. L'outil utilisé est un script faisant appel à \arsync : les fichiers sont synchronisés, c'est-à-dire que les fichiers locaux nouveaux ou modifiés sont envoyés, et ceux supprimés le sont également à distance. De cette manière, la base de fichiers du projet est la même sur \astaging\ et sur le serveur du client.

La dernière étape consiste à mettre à jour la base de données du \alotdeux\ chez \aey. Au début de la phase de recette, on ne se posait pas de question car il suffisait de détruire l'ancienne puis de la reconstruire à chaque livraison. Plus tard, le client a choisi de la conserver au fil des livraisons : quand la structure de la base de données ou son contenu était modifié en environnement de développement, il fallait répercuter les changements chez le client.