Intégration continue avec le contrôle de code source distribué

Question

Je pense que je me méprends sur quelque chose mais que je ne trouve pas exactement quoi. J'ai googlé, mais je n'ai pas eu l'idée. Il existe deux techniques populaires: l'intégration continue et le contrôle de code source distribué. Les gens les combinent d'une manière ou d'une autre, mais je ne comprends pas comment. Autant que je sache, l'intégration continue signifie que vous devez vous connecter au référentiel central (push) dès que vous avez testé votre code localement. Dans le même temps, les systèmes distribués sont tellement appréciés, entre autres, parce que vous pouvez commettre et commettre et commettre localement et jouer avec le code et le pousser aux autres seulement quand vous êtes assez confiant et satisfait. Donc, bien que cela ne force pas, il encourage cependant à ne pas se dépêcher de pousser. Il me semble que le classique pour CI pousser toutes les quelques heures n'aura pas lieu.

Alors, comment et quand reliez-vous ces deux choses ensemble? Ou ai-je tort dans ce que j'ai dit?

EDIT

Je lis les trois premières réponses. Merci pour votre réponse. Je suis toujours confus, mais maintenant je peux formuler la question plus précise.

Dans les systèmes distribués il n'y a pas tellement de désir de commits fréquents, alors en centralisé. Alors, y a-t-il des directives sur la fréquence à publier dans les systèmes distribués pour se conformer à CI? Est-ce encore plusieurs fois par jour ou existe-t-il une autre version de cette règle?

Answer 1

Le contrôle de source distribuée et l'intégration continue ne sont pas des concepts mutuellement exclusifs. En fait, ils jouent très bien ensemble.

Même si les DVCS sont par nature distribués, vous disposez toujours d'un référentiel central qui représente le «tronc» traditionnel des systèmes de version centralisée. Vous ne devez pas modifier votre modèle de développement en termes de quand et quels changements vous «publiez» dans votre référentiel central. Parce que DVCS ne vous force pas à pousser vos changements, vous devez être très discipliné à cet égard. D'autre part, DVCS permet aux développeurs d'effectuer des validations plus petites et incrémentielles sur leurs branches privées. Non seulement les changements sont-ils plus faciles à suivre de cette façon, mais ils sont aussi plus faciles à fusionner à la fin. Avoir des validations locales est particulièrement utile lors de l'ajout d'une fonctionnalité ou lors de modifications expérimentales. Ou lorsque vous avez besoin d'interrompre votre travail sur la fonction A pour corriger le bogue très important B.

Le développeur individuel décide de ce que get est poussé/publié quand. Comme toujours, avec une puissance supplémentaire vient une responsabilité supplémentaire.

---

Vous devez pousser/publier les modifications dès qu'elles sont prêtes. Par exemple, je veux renommer une classe. Cela touchera plus de 50 fichiers, même si seulement quelques lignes. Je fais le renommer en utilisant un outil de refactoring.

Dans un système centralisé, je dois maintenant décider si cela vaut vraiment la peine de s'engager seul ou s'il fait partie d'un travail plus important sur lequel je travaille actuellement. Par expérience, les gens choisissent généralement la deuxième option, parce que vous n'êtes pas sûr si vous voulez que cela fasse partie de l'histoire permanente pour le moment.

Dans un système distribué, je peux valider la modification localement, j'ai une histoire claire séparant les changements de code mécaniques (refactoring) et fonctionnelle. À ce stade, je n'affecte personne d'autre. Je pourrais facilement réviser cette décision plus tard, avant que j'élimine finalement mes changements. Ce sera un engagement propre propre alors.

Le problème dans cet exemple est avec la situation suivante: Imaginons que je renommer cette classe sur ma branche locale ou ma "mise en attente différée". En attendant, quelqu'un commet un nouveau code sur le tronc qui utilise la classe que je viens de renommer. Ce sera un tracas de fusionner mon renommer.

Bien sûr, vous pourriez avoir publié juste que changer le moment où vous l'avez fait. Dans les deux systèmes. La responsabilité est la même. Mais puisque le DVCS vous encourage à avoir des engagements plus petits et plus graduels, la fusion sera plus facile. Les deux systèmes pourraient vous fournir la même "stratégie de sortie" si vous avez publié vos modifications plus tôt.

Answer 2

A L'intégration continue système est un outil (comme par exemple le régulateur de vitesse) qui surveille le référentiel de code source une fois toutes les N minutes.

Chaque fois que quelque chose change (quelqu'un commet du code), l'IC saute dedans, exécute tous les tests et envoie la sortie (échecs ou pas) quelque part, comme l'email ou un écran.

CI ne dépend en aucune manière du type de VCS que vous utilisez, qu'il soit distribué ou non.

Answer 3

Il y a un certain nombre d'éléments à cela, certains ayant trait au logiciel, d'autres au processus.

Les systèmes de contrôle de version sont juste cela, le contrôle de version. La possibilité de revenir en arrière, ramifier et fusionner, etc. que ce soit centralisé ou distribué et qu'ils ont tous les deux des hauts et des bas. VCS en soi ne vous aide pas à mieux coder ou à mieux gérer les projets, ils facilitent le processus de développement en équipe si et quand les équipes fonctionnent correctement. En d'autres termes, vous pouvez bousiller tout aussi royalement en utilisant SVN ou Mercurial que vous le pouvez sans elle. Lorsque CI arrive est plutôt que du code pendant plusieurs jours, puis commettre, puis construire le projet et le test, la validation du codeur plus fréquemment, 1/2 jour 1 jour (max) et le projet est construit et testé (non publié vivre). Cela signifie que toutes les erreurs sont détectées plus tôt et peuvent être plus facilement rectifiées car moins de code a été engagé et la mémoire des programmeurs est plus fraîche. CI peut être fait manuellement, ou il peut être scripté, l'écriture de scripts CLI le fera, ou l'un des outils logiciels CI qui s'intégrera avec CVS ​​peut être configuré pour faire ce processus automatiquement ou semi-automatiquement à réduire la gestion et la capacité de faire des erreurs. L'avantage d'utiliser les outils existants, Mercurial + Hudson ou SVN et Cruise Control, est que vous vous appuyez sur la sagesse et l'expérience de gens qui ont probablement foiré royalement à un moment donné mais qui ont appris la leçon. Ce que vous ne pouvez pas faire, c'est de le sortir de la boîte et de l'utiliser et de vous attendre à ce qu'il fonctionne sans ajouter votre propre processus pour votre propre projet dans le mélange.