Avez-vous des politiques de validation?

Question

Mon patron a annoncé hier une nouvelle stratégie de validation des archivages dans le référentiel. Ces règles sont valables pour les commits dans la tête / le tronc et les branches.
Un message de validation doit comporter les éléments suivants:

• Raison (ID de bogue, ID de projet ou modification non fonctionnelle)
• Nom du réviseur

Après la validation, nous devons également créer une entrée de blog de modification dans notre CMS.

Je ne suis pas un grand fan de cette politique de commit, car je n'ai normalement pas besoin d'un relecteur lorsque je fais des choses nouvelles ou expérimentales dans une branche non productive.

Avez-vous des règles de validation à suivre?

Je pense que c'est une bonne idée de changer de branche productive uniquement à cause d'un rapport de bogue, mais les commits dans les branches de développement devraient être moins restrictifs.

Answer 1

Engagez-vous tôt et engagez-vous souvent.

Nous utilisons réellement / trunk en tant que développement et balises pour créer des branches différentes. Seuls les changements intrusifs structurels vont dans / branches.

Nous utilisons activement des balises pour les versions de production et d'acceptation, afin de pouvoir remonter facilement dans le temps. Tout ce qui est commis dans le coffre ne devrait contenir qu'un message décrivant ce que la validation a changé ou ajouté brièvement.

Je ne suis pas un grand fan d’utilisation de l’espace de message pour établir un lien avec des ID de bogue. Il faut tout de même rechercher l’ID. Dans ce cas, vous pouvez également le rechercher dans le logiciel de suivi des bogues et le fermer à cet endroit, ce qui m’arrive est à peu près le même effort.

Cela ne veut pas dire que je n'aime pas l'intégration SVN: - Nous utilisons plus de bonté de scripts nant automatisés pour faire des versions qui les branchent dans / tags - Les accessoires svn stockent en réalité nos numéros de version: p. - scripts de crochet pour la notification par courrier électronique et la consignation des messages (idéal pour les notes de publication collées-collées).

Answer 2

Nous avons un certain nombre de politiques, qui sont appliquées via un plug-in interne à Visual Studio. Nous vérifions que le code est compilé et que les tests unitaires ont été exécutés avec succès. Pour le moment, nous vérifions également la couverture de code et émettons des avertissements pour le code ne disposant pas de suffisamment de tests. Nous effectuons également diverses vérifications de cohérence et nous vérifions qu'une tâche appropriée est présente dans notre système de gestion des modifications afin de permettre la traçabilité de toutes les modifications.

L’avantage de l’aide aux outils est formidable, car il n’appartient pas vraiment aux personnes de respecter les politiques, mais il ya évidemment un inconvénient et ces vérifications prennent du temps. Cependant, avec de nombreux développeurs, il est difficile d'appliquer des normes sans une prise en charge appropriée des outils.

Answer 3

Un critique semble inutile pour les raisons que vous avez mentionnées, car tout ne doit pas nécessairement être examiné par d'autres.

Auparavant, la seule politique de validation que nous avions (où je travaillais auparavant) consistait à inclure un commentaire indiquant ce que vous avez changé et pourquoi, mais cela relève du sens commun avant tout.

Answer 4

Une politique de validation commune consiste à associer un ID de bogue à la validation de la ligne de réseau comme justification. Parfois, les systèmes de contrôle de version et de suivi des bogues sont configurés pour appliquer cette stratégie.

Answer 5

Notre stratégie de validation ressemble un peu à la vôtre, à la différence près que nous ne l'appliquons pas aux branches de tâches (lorsqu'une branche de tâche est comme un bac à sable pour les expérimentateurs).

Nos commentaires de validation doivent inclure un ID de contrôle de modification (nouvelle fonctionnalité, amélioration) ou un ID de problème (correction de bogue). Vous devez également inclure une brève explication sur pourquoi vous avez apporté ce changement; Le contrôle de version suit le qui, quoi, quand et où.

Answer 6

Mon message de validation comprend une brève description de ce que j’ai implémenté ou modifié dans les classes.

Le numéro de bogue et les descriptions supplémentaires que j’ai mis dans la commentaire au-dessus du nouveau code. Identifiants dans les messages de validation que nous avons mis lorsque nous fusionnons les modifications dans une branche étiquetée.

Chaque nuit, un build automatique vérifie les différentes caractéristiques et produits et s'assure que le code est stable.

Mais au final, je pense que vous ne pouvez pas avoir trop de descriptions pour les classes nouvelles ou modifiées, mais trop de règles à faire avant un commit. Le nom du critique est quelque chose que je ne mettrais pas dans le message de validation.

Pensez à cela, vous devez parfois comprendre le code que vous avez implémenté il y a 2 ans. Et puis, vous êtes satisfait des messages de validation qui ne ressemblent pas à "Mettre à jour après le débogage".

Answer 7

Nous avons des succursales pour chaque version majeure publiée du logiciel qui sont toujours activement prises en charge. L’identification dans l’une de ces branches nécessite un ID de bogue. Il est appliqué par scmbug , qui non seulement vérifier que le commentaire est préfixé par l'ID de bogue, mais il recherchera également ce bogue dans la base de données de bogues, s'assurera qu'il est attribué au responsable et vérifie éventuellement d'autres critères (par exemple, le champ "Correction dans la branche" est la branche étant engagée).

L’un des produits risque davantage d’échouer de manière embarrassante, et les archivages nécessaires nécessitent non seulement un ID de bogue, mais également une révision du code. Cependant, les critères de révision du code sont gérés dans notre base de données de bogues - nous avons des champs personnalisés pour cela et le bogue ne peut pas être accepté et fermé tant qu'il n'a pas été examiné. Pour moi, cela fonctionne au niveau conceptuel - il est probablement préférable de vérifier le code censé fonctionner dans le référentiel non révisé, puis rouvrez le bogue et modifiez-le si nécessaire plutôt que de retarder la validation jusqu'à ce que vous êtes sûr. il est prêt à être publié.

À part cela, il n'y a pas de politique explicite pour le tronc (bien que les principes généraux de l'enregistrement souvent sans casser la construction, y compris de bons messages de validation descriptifs, l'enregistrement en unités de travail de manière atomique s'appliquent toujours).