Comment synchroniser l'activité CI (Hudson) dans un processus de construction automatisé existant (phing, svn)?

Question

NOTRE processus actuel

Nous sommes une petite équipe de développeurs (2 à 4 personnes selon le projet) qui utilisent actuellement Phing pour déployer le code dans un environnement de mise en scène, avant d'aller vivre. Nous gardons notre code dans un repo SVN, où le tronc détient le développement actif actuel et, à certains moments, nous faisons des branches que nous testons et ensuite (en cas de succès), marquons et exportons vers l'environnement de transfert. Si tout va bien là aussi, nous les déployons enfin dans des serveurs de production. Les actions sont hautement automatisées, mais toujours déclenchées par une intervention humaine.

---

DOUTE

Nous aimerions maintenant vous présenter l'intégration continue (avec Hudson) dans le processus; Malheureusement, nous avons quelques doutes sur la synchronisation des activités, car nous avons peur que CI puisse quelque peu interférer avec notre processus de construction et causer certains problèmes.

Considérant qu'un cycle de CI automatisé a une certaine fréquence d'actions exécutées automatiquement, nous voyons 2 cas possibles pour « l'intégration », chacun avec ses propres problèmes:

1. Cas A: chaque cycle de CI produit un nouvelle branche avec son propre nom; nous utilisons un tel nom manuellement (par l'intermédiaire de phing comme il se passe maintenant) exporter le code de la SVN à la mise en scène env. Le problème que je vois ici est que (sauf contre-mesures spécifiques sont pris - IE suppression) le nombre de branches que nous avons peut facilement devenir hors de contrôle (supposons que nous nous engageons souvent, de sorte que nous avons une nouvelle construction/branche tous les N minutes).

2. Cas B: chaque cycle de CI crée une nouvelle branche nommée « actuelle », qui est ensuite marqué avec un nom unique que lorsque nous décidons manuellement à exporter vers la mise en scène; la branche actuelle, en tout cas est alors supprimé, dès que le prochain cycle CI démarre. Le problème que nous voyons ici est qu'un nouveau cycle pourrait lancer pendant que quelqu'un est marquage/exportation de la branche « actuelle » à la mise en scène créant ainsi une construction incohérente (mais peut-être ici je suis trop pessimiste, puisque je avouer je ne sais pas si SVN offre une protection intégrée contre cela).

---

Avec tout cela étant dit, je me demandais si quelqu'un avec des expériences similaires pourrait être si bon pour nous donner quelques conseils sur le sujet, puisque aucune des approches décrites ci-dessus semble satisfing complètement à nous.

Y a-t-il quelque chose d'important que nous avons complètement oublié dans l'image globale? Merci pour votre attention & (à l'avance) pour votre aide!

Answer 1

Dans les deux options, vous commencez par "chaque cycle CI produit une nouvelle branche". Ne faites pas cela. Vous voulez garder votre nombre de branches au minimum et toujours sous contrôle (créé manuellement) pour éviter que votre projet ne devienne un gâchis. La décision de savoir si le développement de la ligne principale est prête et que vous pouvez produire un candidat à la publication (branche depuis le tronc) n'est pas triviale.

Les cycles de CI sont déclenchés par des changements dans le code pour garantir que l'intégration de ces changements ne casse pas l'application. Par conséquent, vous préférez mettre en place un projet dans Hudson pour chaque flux de développement actif, un pour la ligne principale, un pour la branche qui représente la version de production (pour la correction des bugs) et éventuellement un pour le RC.

Martin Fowler's article about Continuous Integration est un excellent guide sur le pourquoi et le comment de la mise en œuvre du CI.

Answer 2

Une approche que nous avons utilisée dans notre projet consistait à exécuter des générations de CI uniquement lorsqu'il y avait un changement de code. Cela peut être configuré sur votre SVN comme un crochet de validation de publication. Vous pouvez ensuite déclencher à distance des builds dans HUDSON via une URL authentifiée. Le problème que je vois est que puisque des travaux doivent être créés, à moins que votre système de construction ne le prenne en charge, il n'y a aucun moyen pour hudson de comprendre qu'il y a une nouvelle branche sur le repo et de créer un travail pour cela.