2010-12-14 104 views
4

Comment avez-vous ou avez-vous essayé de protéger vos référentiels de code source contre les validations qui introduisent des bogues ou cassent des builds? Il semble que les tests de régression forcée au moment de la validation peuvent grandement contribuer à empêcher les bogues de s'infiltrer dans des projets développés par plusieurs développeurs. Cependant, la plupart des outils de gestion de version du code ne proposent aucune fonctionnalité dans ce domaine.Comment protéger le référentiel de code contre les tentatives de rupture ou de buggy?

Voici une méthode que j'ai expérimentée. J'ai créé des hooks de pré-commit de subversion pour générer une copie du projet avec les changements de commit en attente fusionnés, puis j'ai exécuté la vérification de syntaxe et les tests unitaires sur cette copie. Si l'un des tests échouait, commit serait rejeté avec les résultats du vérificateur de syntaxe ou des tests unitaires pour fournir un retour d'information au développeur effectuant cette validation. Si le test de syntaxe et les tests unitaires sont passés, commit sera accepté. Cela a fonctionné mais le compromis était que cela rendait les commits vraiment lents. Si le logiciel de versionnage du code offrait une meilleure intégration pour faciliter cela, en dehors de l'exécution de programmes externes en pré-validation, je pense que la vitesse pourrait être améliorée. Je cherche des méthodes que vous avez utilisées pour y parvenir, des idées sur les raisons pour lesquelles c'est une bonne ou une mauvaise idée, ou des outils de versionnement de code qui prennent en charge les tests de régression/tests de compilation. Aussi, quelle est l'importance de la vitesse des engagements pour vous?

Répondre

6

Vous devriez utiliser une forme de Continuous Integration lorsque l'environnement utilise Hudson, CruiseControl ou un autre tool pour faciliter ce comportement.

+1

Pour ajouter à cette réponse, vous devez utiliser une forme de branchement pour protéger les modifications potentielles contre la rupture d'une version fonctionnelle de votre code. De cette façon, vous pouvez toujours utiliser les avantages du contrôle de version sans exposer vos branches ou sources principales avec du code qui doit être retiré jusqu'à ce que vous soyez sûr que cela fonctionne. –

+0

+1, les outils CI vous permettent généralement d'avertir les développeurs (par e-mail ou autre) lorsque la génération est interrompue, ce qui permet de réparer rapidement les versions endommagées. –