Comment tester un déploiement

Question

Nous envisageons d'ajouter un autre serveur au cycle de vie de développement, afin que nous puissions tester un déploiement.

Un peu d'histoire: Nous développons des applications web, en utilisant ASP.NET et SQL Server 2005. Il y a 4 développeurs dans l'équipe et ont tendance à relâcher une fois toutes les 2 semaines.

Voici notre méthode actuelle de déploiement: Nous développons sur un serveur Dev et que chaque cas de dev est terminée, il est ajouté au serveur de stockage intermédiaire, où il est testé. Lorsque nous arrivons à la date de publication, tous les cas dans une version sont déployés depuis le serveur de transfert vers le serveur Live.

Mais le problème est que seul le déploiement complet est lorsque nous déployons sur Live à la date de publication - tout le déploiement vers le stockage intermédiaire est effectué au cas par cas. Cela signifie que nous avons commis des erreurs ou que nous avons ignoré les étapes du déploiement en direct (par exemple, en oubliant de verrouiller les utilisateurs pendant le déploiement). Ce dont nous avons besoin, c'est d'un moyen de faire une simulation du déploiement en direct.

Ce que nous envisageons est l'ajout d'un autre serveur au processus de libération, alors ...

serveur actuel set-up: serveur Dev -> Serveur Staging -> Serveur en direct

serveur potentiel série -up: serveur Dev -> serveur Staging ->Beta serveur (est-ce le nom correct?) -> serveur en direct

de cette façon, nous pourrions pratiquer chaque déploiement complet sur le serveur bêta et DRA w une série d'étapes pour le déploiement en direct - et espérons que nos déploiements en direct seront plus faciles. Nous prévoyons également de donner aux clients l'accès au serveur bêta pour tester les choses par eux-mêmes.

S'il vous plaît laissez-moi savoir ce que vous pensez. Faites-vous cela ou existe-t-il un autre moyen de tester notre déploiement avant la date de publication?

Answer 1

Vous êtes sur la bonne voie.

Voici comment nous travaillons - d'autres personnes peuvent faire les choses différemment (mais elles peuvent aussi répondre à votre question et vous pouvez décider de votre propre approche).

1) Le code est construit en dev - il s'agit d'une zone non contrôlée.

2) Toutes les modifications de la base de données sont scriptées et tout le code .NET est intégré aux MSI. Nous les déployons dans Test. Ils sont également stockés quelque part spécial où ils ne peuvent pas être foiré avec. S'il y a des problèmes, les tests les trouveront et nous ajusterons les scripts/créerons de nouveaux MSI avec les correctifs.

3) Une fois le test terminé, l'environnement de «pré-production» est renvoyé de la phase de production. Ça ressemblera à une copie identique de live. Les versions finales sont exécutées en "pré-production". Le déploiement devrait juste fonctionner, mais c'est l'occasion de s'assurer que c'est le cas. Si ce n'est pas le cas, le déploiement est ajusté et l'environnement de «pré-production» est renvoyé du live, donc nous savons que nous le testons contre une copie exacte (aucun point ne le testant contre celui que vous avez déjà foiré) avec!)

4) Si la version fonctionne (et que vous effectuez généralement des tests pour vérifier tous vos composants), elle est prête à être exécutée en direct.

Il est utile que vos scripts de base de données soient relancés. Détectez si le changement existe déjà avant de le faire à nouveau, dans le cas où les scripts sont exécutés plus d'une fois pour une raison quelconque. Par exemple, si vous ajoutez une valeur de configuration à une table, vérifiez que vous ne l'avez pas déjà fait, sinon vous pouvez l'ajouter plusieurs fois et ajouter vos données.