Déploiement d'applications Web pour une population d'utilisateurs limitée

Question

J'essaie de déterminer la meilleure façon de déployer de nouvelles versions d'une application Web établie. Dans le passé, je l'ai fait de deux manières différentes mais cette fois, nous cherchons à faire quelque chose d'un peu différent/meilleur.

Nous utilisons des serveurs de développement/staging/production. Une fois le développement terminé et les fonctionnalités de base testées, nous exécutons le code de développement avec une base de données de production mise à niveau sur le serveur de transfert. Si notre assurance qualité interne ne trouve pas de problèmes dans l'environnement de transfert, nous effectuons ces changements en direct.

Cette dernière étape a été fait dans les deux façons suivantes:

1. Mise à niveau du code et la base de données schéma à un moment de faible utilisation, faire un peu des tests pour vous assurer que les mises à niveau allé OK, puis croiser les doigts et espérons que les utilisateurs ne trouvent pas certains bug que QA manqué, toujours prêt à éteindre les incendies ou revenir à la version précédente en cas de défaillance majeure .

2. Créez la nouvelle version de l'application à une URL différente. Copiez la base de données de production vers une nouvelle version , videz-la, puis copiez sur pour les utilisateurs sélectionnés et utilisez pour utiliser la nouvelle URL. C'est-à-dire, ils accéderaient à l'application de www2.example.com au lieu de www.example.com. Déplacer lentement tous les utilisateurs vers la nouvelle version, puis basculer vers les adresses précédentes.

Cette fois, je cherche à faire quelque chose comme une combinaison des deux méthodes. Fondamentalement, je pense à déplacer un petit nombre d'utilisateurs vers le nouveau service tout en gardant la même URL.

Voici ce que je considère faire dans l'hôte virtuel. Map.txt serait généré/mis à jour lorsque les nouveaux utilisateurs seraient déplacés. (Je regardais en utilisant la carte de réécriture prg mais ai peur de la pendaison apache attendant le script.)

<VirtualHost *:80> 
ServerAdmin webmaster@lotsa.net 
DocumentRoot /web/www.example.com 
ServerName www.example.com 

RewriteEngine on 

RewriteMap deploymentmap txt:/web/map.txt 

RewriteRule ^/id/([0-9]+)/(.*)$ ${deploymentmap:$1}/id/$1/$2 

</VirtualHost> 

map.txt: 

10001 /web/www2.example.com/ 
10002 /web/www2.example.com/ 
10003 /web/www2.example.com/ 
10004 /web/www2.example.com/ 
10005 /web/www2.example.com/ 

Y a-t-il des lacunes évidentes dans cette stratégie de déploiement? Est-ce que je manque une méthode de mise à niveau simple et efficace, moins douloureuse?

Merci d'avance pour toute assistance.

-Paul

Answer 1

Personne n'a jamais répondu, donc je vais me répondre pour la postérité. :-)

Cette méthode fonctionne très bien pour un déploiement par étapes d'une nouvelle base de code sur une ancienne base de code. Dans notre situation particulière, nous avons fait le déploiement en utilisant une méthode similaire à celle ci-dessus. Initialement, tous les utilisateurs ont démarré avec l'ancien système et le fichier de carte de réécriture avait une taille d'environ 800 Ko. Le serveur a servi plus de 100K pages sans différence notable de vitesse en raison des nouvelles directives de réécriture.

J'ai été surpris qu'Apache n'ait pas besoin d'être redémarré après avoir apporté des modifications pour supprimer des entrées du fichier (la documentation implique que ce fichier est lu uniquement au démarrage).Apache a tout de suite ramassé les modifications sur la carte, il doit donc les regarder à chaque requête, ou plus probablement vérifier les horodatages/checksums pour voir si c'est différent.

Une technique similaire pourrait être utilisée non seulement pour le déploiement mais aussi pour le test A/B, en particulier dans les situations où la structure de données ne change pas.