question sur la gestion d'instance d'application

Question

Je travaille actuellement sur un assez gros projet avec une équipe répartie à travers les États-Unis. Les développeurs écrivent régulièrement du code dans le référentiel source. Nous avons l'application suivante construit (tous sont gérés par une application, aucun processus manuel):

1. Intégration continue: un moniteur vérifie pour voir si le référentiel de code a été mis à jour, le cas échéant, il fait une construction et fonctionne notre suite de tests unitaires. En cas d'erreur, l'équipe reçoit des notifications par e-mail.
2. Création quotidienne: les développeurs utilisent cette version pour vérifier leurs correctifs de bogues ou leur nouveau code sur un serveur d'applications réel. Si les choses réussissent, le développeur peut résoudre la tâche.
3. Construction hebdomadaire: les testeurs vérifient la file d'attente de problèmes résolus sur cette version. C'est un environnement de test plus stable.
4. Version actuelle: utilisée pour démo et une plate-forme de test ouverte pour les nouveaux utilisateurs potentiels.

Chaque génération actualise la base de données qui lui est associée. Cela nettoie les données et vérifie les modifications apportées aux bases de données qui accompagnent le nouveau code. Une préoccupation de nos testeurs est que nous devons pré-remplir la base de données de construction hebdomadaire avec des données de test attendues, par opposition à des données plus génériques que les développeurs travaillent avec. Cela semble être une préoccupation/un besoin légitime et c'est quelque chose sur lequel nous travaillons.

Je lance ce que nous faisons pour voir si la communauté SO voit un écart avec ce que nous faisons, ou a des préoccupations. Les choses semblent bien fonctionner, mais il se sent comme ça pourrait être mieux. Tes pensées?

Answer 1

Une étape supplémentaire est la suivante: une fois que la version release a passé les tests (s ayez un test de fumée) alors il est qualifié de bon build (disons une version dorée) et vous utilisez une sorte de mécanisme d'étiquetage pour étiqueter tous les artefacts (code, scripts d'installation, makefiles, installable etc.) qui sont entrés dans la création du image dorée. La construction en or peut devenir un candidat à la libération plus tard ou non.

Probablement que vous faites déjà cela, puisque vous ne mentionnez pas j'ai ajouté ce que j'avais observé.

Answer 2

C'est à peu près la façon dont nous le faisons. La base de données des testeurs eux-mêmes n'est réinitialisée qu'à la demande. Si nous le rafraîchissions automatiquement chaque semaine, alors

1. nous perdrions les références aux symptômes de bug; si un bug est trouvé mais qu'un développeur ne le regarde que quelques semaines plus tard (ou tout simplement après le week-end), alors toute l'expérience de ce bug peut avoir disparu
2. Les testeurs pourraient être au milieu d'un gros test (en prenant plus de 1 jour par exemple)
3. nous avons des tonnes de tests unitaires qui sont en cours d'exécution contre un DB qui est mise à jour (automatique bien sûr) chaque fois qu'une construction d'intégration est exécutée

salutations,
Stijn

Answer 3

Je pense que vous avez un bon processus complet, à condition que cela corresponde au moment où vos clients veulent voir les mises à jour. Une lacune possible que je vois est qu'il semble que vous ne seriez pas en mesure d'obtenir une correction de bogue client critique dans la production en moins d'une semaine, puisque vos versions de test sont hebdomadaires et que les testeurs ont besoin de temps pour vérifier le correctif.

Si vous avez envie de penser différemment, jetez un oeil à cet article sur continuous deployment - il peut être un peu difficile d'accepter le concept au début, mais il a certainement un certain potentiel.