Le blog de Fabien DUMINY

Un blog utilisant WordPress

Skip to: Content | Sidebar | Footer

Devoxx France 2013 – Architecturer pour la livraison continue

7 mai, 2013 (09:00) | Devoxx France 2013 | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « Architecting for Continuous Delivery » présentée par Axel Fontaine.

Facebook, Flickr et Stack Overflow font plusieurs mises en production par jour et donc du déploiement continu. Remarque : on constate que le numéro de version du site Stack Overflow se trouve en bas de page.

Le déploiement continu ne doit pas se faire à partir d’une version snapshot afin de permettre la reproductibilité. Le cycle est donc : lancer tous les tests, créer une nouvelle version et faire le déploiement dans l’environnement de déploiement continu.
Lorsque le déploiement est manuel, il faut l’automatiser. La version déployée doit contenir le code, les différences entre les bases, ainsi que la configuration de tous les environnements (intégration, recette, production …). La détection de l’environnement doit se faire automatiquement, par l’intermédiaire d’une variable d’environnement, d’un fichier présent dans un endroit précis …

Gestion des modifications de la base de données

Axel conseille de choisir un outil pour gérer les différentes versions d’une base de données ainsi que l’ordre d’execution des scripts :

  • Flyway est un projet libre de migration de base de données. Il enregistre la version de chacun des scripts joués. On peut partir d’une base existante pour générer la première version des scripts.
  • Liquibase est un autre projet libre avec des fonctionnalités similaires.

Gestion des nouvelles fonctionnalités

La bascule de fonctionnalité (en anglais : Feature toggle) permet d’éviter la création de branches (et donc la fusion des branches et la duplication de l’environnement d’intégration continue). Cela se traduit souvent dans le code par un ‘if’, ce qui évite de casser le code existant. L’ancien code sera supprimé plus tard quand tout sera correct en production.

Gestion des serveurs

Pour palier au crash éventuel d’un serveur et maintenir le site web toujours actif, il faut utiliser 2 machines.

Lors d’une mise en production, l’une des machines sert au déploiement de la nouvelle version, toujours connectée sur la même base de données. La compatibilité de l’ancien serveur avec la base de données doit être assurée : au lieu de renommer une colonne, il faut en rajouter une autre ainsi qu’un trigger qui fait la copie de l’ancienne colonne vers la nouvelle. L’ancienne colonne et le trigger seront supprimés plus tard. Pour une application web fonctionnant sous tomcat, l’utilisation d’un cache de session partagé tel que memcached-session-manager permet de conserver les sessions actuellement actives. Chaque machine héberge une instance de tomcat et une instance de memcached. Le passage à la nouvelle version se fait ainsi de manière totalement transparente pour les utilisateurs.

Be Sociable, Share!
Share and Enjoy

Write a comment





If your website is claim enabled, it will be notified that you have posted here.

MySQL query error