La méthode que tu décris est bien sûr meilleure mais ce n'est pas applicable à chaque projet.
Ça fait longtemps que je crois plus au relation d'ordre dans le développement. Le mot clé est "pragmatisme" ;)
Je comprends pourquoi tu fais ca. D'une part par ce que c'est facile et d'autre part c'est une contrainte ferme. Par contre je souligne que généralement on fait ça en amont ou en aval du commmit pour des raisons d'efficacité. En amont quand on travail par patch pour forcer les contributeurs à répondre à des métriques objectives qui viennent en complément de la revue de code subjective par les développeurs. En aval dans les autres cas, ou on vérifie l'intégrité entière du repository (compilation, checkers, test unitaires/fonctionels/intégration etc.).
Mon commentaire indique aussi que la qualité est une démarche. Utiliser des barrières trop fermes dans cet objectif peut nuire à l'objectif. Tu perds en productivité et en souplesse mais il te faut toujours le même souhait de qualité en plus du hook. Avoir un système de métrique qualité (souvent dans la partie intégration continue) est souvent suffisant. L'objectif affiché est que ce soit toujours vert mais on ne tombe pas dans l'excès inverse de ne jamais permettre le rouge. Par contre c'est la responsabilité de l'équipe que quand c'est rouge ça ne le reste pas. De toute facon si l'équipe n'applique pas ça tu vas dans le mur quoi qu'il arrive.
En gros en général on est souple au développement et ferme à la livraison. C'est à dire qu'on s'autorise des petites instabilité pour développer mais qu'à la livraison c'est toujours nickel. D'où l’intérêt de faire de petits incréments.
est largement compensé par le temps économisé (attente que le contributeur revienne pour qu'il ajoute le fichier manquant, ou revert de ses derniers commits)
Pour les rares fois ou ça t'impacte, le mec qui commit et se tire sans vérifier le build, un rollback local ça prend 10s. Et tu le feras de toute façon si il a introduit une régression qui t'impacte.
[^] # Re: Les warnings
Posté par ckyl . En réponse au journal compiler en c++ pour avoir plus de warnings. Évalué à 2.
Ça fait longtemps que je crois plus au relation d'ordre dans le développement. Le mot clé est "pragmatisme" ;)
Je comprends pourquoi tu fais ca. D'une part par ce que c'est facile et d'autre part c'est une contrainte ferme. Par contre je souligne que généralement on fait ça en amont ou en aval du commmit pour des raisons d'efficacité. En amont quand on travail par patch pour forcer les contributeurs à répondre à des métriques objectives qui viennent en complément de la revue de code subjective par les développeurs. En aval dans les autres cas, ou on vérifie l'intégrité entière du repository (compilation, checkers, test unitaires/fonctionels/intégration etc.).
Mon commentaire indique aussi que la qualité est une démarche. Utiliser des barrières trop fermes dans cet objectif peut nuire à l'objectif. Tu perds en productivité et en souplesse mais il te faut toujours le même souhait de qualité en plus du hook. Avoir un système de métrique qualité (souvent dans la partie intégration continue) est souvent suffisant. L'objectif affiché est que ce soit toujours vert mais on ne tombe pas dans l'excès inverse de ne jamais permettre le rouge. Par contre c'est la responsabilité de l'équipe que quand c'est rouge ça ne le reste pas. De toute facon si l'équipe n'applique pas ça tu vas dans le mur quoi qu'il arrive.
En gros en général on est souple au développement et ferme à la livraison. C'est à dire qu'on s'autorise des petites instabilité pour développer mais qu'à la livraison c'est toujours nickel. D'où l’intérêt de faire de petits incréments.
Pour les rares fois ou ça t'impacte, le mec qui commit et se tire sans vérifier le build, un rollback local ça prend 10s. Et tu le feras de toute façon si il a introduit une régression qui t'impacte.