Outils d'aide à la gestion du processus de promotion des applications dans un environnement d'entreprise

Question

Je suis curieux de savoir comment d'autres personnes gèrent la promotion du code de DEV à TEST en passant à PROD au sein d'une entreprise.

Quels outils ou processus utilisez-vous pour gérer les "règles administratives", les critères d'entrée / de sortie?

Mon organisation actuelle est à moitié coincée entre certaines fonctionnalités de type de formulaire en ligne personnalisées et des dépendances sur papier pour soumettre des documents, rassembler des approbations et des révisions.

Tout cela reste entre les mains des gestionnaires de projet pour suivre ce qui a été soumis, passé en revue, approuvé, et informer la direction en cas d'obstacles pouvant nécessiter une approbation pour être "négligés". avant qu'une application puisse être promue dans l'environnement suivant.

Une application basée sur un navigateur serait l’idéal ... alors, que se passe-t-il? montrez-moi s'il vous plaît que vous googlefu est meilleur que le mien.

Answer 1

Il est difficile de trouver un bon site via Google. Il existe une vaste gamme d’outils pour la gestion des problèmes; je vais donc mentionner ce que nous utilisons et ce que nous aimerions utiliser.

Nous utilisons actuellement des produits serena. Ils ont bien fonctionné pour nous par le passé. Team Track est notre gestion des problèmes et gère le cycle de vie de tout problème sur lequel nous travaillons. Version Manager est notre contrôle de source et offre la possibilité de mettre en œuvre des groupes de promotion tels que DEV TEST and PROD. Nous utilisons DEV, TSTAGE, TEST, PSTAGE et PROD pour indiquer le mouvement de l'un à l'autre, mais c'est à peu près la même chose. Les deux produits s’intègrent parfaitement, de sorte que la source associée aux problèmes soit liée, mais nous n’avons pas de configuration de processus de construction dans cet environnement. C'est cher, mais ça marche bien.

Nous envisageons de ne pas passer à un système plus courant utilisant Jira pour la gestion des problèmes, Subversion pour le contrôle de source, Fisheye pour relier les deux et Cruise Control pour la gestion des versions. C’est moins cher, totalisant quelques milliers pour une licence d’entreprise et offrant les mêmes fonctionnalités mais avec en plus le bonus de SVN qui est un très bon gestionnaire de version de code.

J'espère que cela aide.

Answer 2

J'ai eu recours à plusieurs scénarios différents au fil des ans:

Dev - > Test: il existe généralement une date d'arrêt sur code qui arrête de fonctionner sur les nouvelles fonctionnalités et donne à un environnement de test le code qui a été créé / étiqueté / étiqueté / archivé. Ceci est ensuite copié sur les machines et les tests se déroulent bien. C’est aussi généralement le moins détaillé de tous les efforts.

Test- > Prod: Cela nécessite une modification mineure, à savoir que la production doit baisser, ce qui peut signifier qu'un "parti en pêche" est parti. la page monte ou IIS ne fait tourner aucun site et le code est recopié. Il existe des cas particuliers dans lesquels un équilibreur de charge peut jouer le rôle de commutateur afin que la promotion ait lieu et qu'aucun des clients ne subisse une interruption de service, car ceux sur l'ancien serveur seront déplacés à la fin de leur session.

Pour en savoir plus sur cette idée de commutateur, la configuration consiste à avoir 2 serveurs potentiellement actifs avec un seul serveur recevant des demandes pour que l'équilibreur de charge envoie tout le trafic à un ordinateur pouvant être commuté lorsque l'autre serveur dispose du code mis à jour. aller vivre.

Il peut également exister un environnement intermédiaire situé entre les tests et la production, dans lequel le processus est similaire, en ce qu’il existe une date précise pour la promotion.

Là où je travaillais, il y avait des jours de fusion où un développeur passait la majeure partie de sa journée à fusionner le code Perforce afin de le promouvoir d'un environnement à un autre.

Il existe maintenant quelques cas où cela n'est pas utilisé:

"Hotfixes" ou "Hot Patches" Cela se produirait là où je travaillais et, dans ce cas, les fichiers spécifiques étaient copiés dans les environnements de transfert et de production, car le changement de code devait entrer en production dès que quelque chose de cassé dans la production ou quelque chose de nouveau devait être fait. cela prend 2 minutes est fait. Dans ce cas, le changement de code inséré devait être examiné et approuvé avant de sortir.

Telles sont les différentes approches que j'ai utilisées: généralement, il existe des calendriers et des calendriers doivent éventuellement être modifiés ou des ressources supplémentaires peuvent être mobilisées pour fixer une date difficile, comme si une conférence avait lieu un week-end particulier, telle ou telle est prête. pour cela.

Bien sûr, dans quelques endroits, il y a eu le "Oh, est-ce que ça a été cassé? Laissez-moi voir ... " et quelques minutes plus tard, "Non, voyez, ce n'est pas cassé pour moi" où quelqu'un a changé des choses sans demander la permission ou quoi que ce soit où une entreprise a toujours ce qu'elle appelle "la programmation de cow-boys".

Un autre point concerne l’ampleur de la publication: 1) Minuscule - Il s’agit du cas où une page Web est affichée de sorte que l’utilisateur X puisse faire Y.

2) Petit - Une poignée de fichiers qui ne sont pas vraiment compliqués mais qui ne sont pas vraiment triviaux.

3) Moyen: pour passer d'un environnement à un autre, il faut modifier de nombreux fichiers et généralement déplacer des scripts.

4) Gros - Là où il y a des promotions programmées et où il est demandé à différents développeurs de savoir qui prend quel quart de travail une fois la campagne effectuée. J'avais ceci dans un cas où il y avait une migration de données à faire en plus d'une publication de nouveaux sites de commerce électronique.

5) Mammoth - Où tout est flambant neuf, y compris son utilisation. Je ne pense pas en avoir déjà vu un de cette taille, mais j'imagine que Microsoft ou Google auraient des versions de cette taille.

Quelque part dans ce spectre, la plupart des mises à jour sont en baisse et l'ampleur de la planification et de la préparation peut varier considérablement. N'oublions pas que la conformité à la réglementation peut parfois être pénible pour certaines choses.