Idée de workflow d'intégration continue

Question

Dans l'environnement de développement de logiciels où je travaille, nous avons un groupe de développeurs travaillant tous dans la même base de code (Java) (utilisant actuellement SVN). Je remarque que les gens veulent souvent commettre ce qu'ils ont construit sans 'casser la construction'. Donc, juste pour cette raison, je suis à la recherche d'outils comme Git et Mercurial qui facilitent le branchement et surtout la fusion. L'une des choses que je vois est que si un développeur commet un «mauvais code», alors le code est cassé pour tout le monde. Comme une idée pour éviter cela, je voudrais une façon d'avoir un référentiel «intermédiaire unique» qui est simplement le «maître» actuel avec SEULEMENT l'un changeset pour cette nouvelle fonctionnalité unique. Un tel référentiel «intermédiaire unique» peut ensuite être testé automatiquement (qualité du code, test unitaire, contrôle manuel du code, etc.) avant de faire partie de la base de code principale.

Donc, le flux de travail que j'ai en tête ressemble à ceci: Un développeur crée une nouvelle fonctionnalité et la transmet localement tous les jours.

Après un certain temps, le développeur a terminé et soumet l'intégralité du changeset à intégrer dans le référentiel 'principal'.

Un système d'intégration continue prend le "maître" actuel, applique le changeset et vérifie le code (conflits de fusion, PMD, Findbugs, ...), exécute les tests unitaires, vérifie le style de codage, etc

Si le système CI décide "mauvais code" le développeur est informé des raisons et le développeur doit résoudre les problèmes mentionnés. Dans ce cas, le référentiel principal est inchangé.

Si le système CI décide "assez bien" alors le code atteint le "développeur principal" ou un "réviseur de code" qui inspecte la solution choisie et l'approuve ou la rejette.

L'ensemble de modifications approuvé est ensuite inclus dans le référentiel principal et est disponible pour tous les développeurs pour rebaser/fusionner.

J'ai quelques questions au sujet de ce type de flux de travail:

• -vous cette chose va bien travailler dans la pratique (à savoir est-ce une bonne idée ou un vraiment Braindead)?
• Est-ce que l'un d'entre vous a déjà travaillé avec quelque chose comme ça? Quels étaient les avantages et les inconvénients?
• Existe-t-il un script/une procédure/un outil/... prêt à l'emploi qui permette de démarrer un tel flux de travail (ou une variante de cette idée) en un minimum de temps?

Merci.

---

Note d'information:

J'ai travaillé en tant que développeur quelque 13 ans auparavant dans une entreprise où ils construisent un flux de travail similaire en interne et ils ont eu deux nightly builds:

1. La « production 'version: Base de code principal
2. La' version senior: base de code principal avec toutes les versions nouvellement soumises de tous les fichiers modifiés.Parce que c'était tout SCCS (lock-edit-unlock model), il n'y avait aucun moyen de «commettre souvent», vous avez eu des blocages pour les changements de code et tous les autres types d'effets désagréables. Ce que je cherche, c'est surtout les bonnes choses sur ce que j'ai utilisé à l'époque en utilisant les meilleurs outils d'aujourd'hui.

Answer 1

TeamCity a une fonction prétest engagent.

http://www.jetbrains.com/teamcity/delayed_commit.html

Answer 2

Dans l'entreprise où je travaille actuellement, nous avons pensé à utiliser une telle approche. À la fin, nous avons choisi d'utiliser quelque chose de plus simple. Nous laissons les constructions automatisées définir une étiquette après une construction réussie et nous avons un outil que nous utilisons pour synchroniser cette étiquette. Donc, quand quelqu'un brise la construction, d'autres personnes seront toujours en mesure d'obtenir une version de travail du référentiel. L'outil de synchronisation s'assure également que si vous venez de soumettre quelque chose, vos modifications ne seront pas remplacées par les révisions appartenant à l'étiquette. Pour nous, cela fonctionne parfaitement, mais cela pourrait ne pas convenir à votre situation.

Cordialement,

Sebastiaan