En tant qu'ingénieur de construction, je cherche constamment de nouvelles méthodes intéressantes pour améliorer notre processus de construction - et cela inclut la recherche de moyens nouveaux et intéressants d'échouer à nos constructions!
Je n'ai encore pas trouvé une liste canonique de raisons pour échouer une construction ... Donc, je pense qu'il est temps d'en avoir créé. Avec cela à l'esprit:
Quels chèques de construction - à la fois évidents et créatifs - avez-vous vu des constructions d'échec?
12 Réponses :
Échec du test unitaire.
Quelque chose d'aussi simple qu'un contrôle sur la défaillance de la compilation devrait être considéré comme obligatoire, nuff dit .
Les contrôles qui conduisent à des constructions brisées devraient être inacceptables, bien que la triste vérité soit que de nombreuses organisations acceptent de tels.
Si la compilation échoue:
pourquoi?
@Pascal thivent: Je suis sûr que j'étais clair à ce sujet; J'ai mentionné un chèque et s'il ne s'agit pas de compilation, il est clairement pas Travailler. C'est à dire. (! Compilation ==! Travailler) Ne pas réclamer quoi que ce soit d'autre à ce stade, car l'OP a demandé un chèque. Je suis sûr que c'est la base évidente.
Édité ... au moins maintenant, j'espère que je l'ai mieux expliqué. Si vous ne vérifiez au moins une défaillance de la compilation, rien ne fonctionnera. Duh! : P
Code Échec des inspections de qualité automatisées (FXCop, etc.).
échec de l'avertissement de compilation
Dans son article introduisant Intégration continue , Martin Fowler a présenté Échec de la suite de tests d'unité de l'application comme une raison convaincante d'échouer une construction.
Les Checkins non approuvés dans la construction. Des choses comme le code vérifié dans ce qui n'est pas associé à un élément de travail ou à un correctif de bogue.
+1: Souvent négligé, mais très utile dans un environnement d'équipe où le soutien est une préoccupation quotidienne.
introduire une dépendance cyclique entre les modules (packages Java, par exemple).
Ma compagnie ne le fait pas réellement, mais avec une grande base de code héritage comme la nôtre, il serait bon d'échouer sur des changements sans papiers. Sans billet de bug, notre département QA ne saurait pas tester les changements et c'est effrayant!
Recherchez des classes en double (même package et nom de classe) dans différents fichiers JAR (Java).
La couverture de code diminue ou tombe en dessous d'un seuil acceptable.
Probablement ;-) wiki c'est!