GitHub, workflow Gerrit, Hudson (Jenkins)

Question

Je viens juste de commencer à l'aide GitHub, Gerrit et Hudson (Jenkins) ensemble. Et je besoin de quelques réflexions sur flux de travail.

Nous aimerions utiliser GitHub comme notre principale repo à distance. Nous aimerions utiliser Gerrit principalement pour des revues de code, mais aussi pour les déclencheurs de construction à Hudson.

À l'heure actuelle, cependant, je vais avoir une certaine difficulté à penser à travers le flux de travail pour cela et aimerais entendre ce que les autres se sont fait. Pensées?

Answer 1

Je n'ai pas directement utilisé Gerrit, mais je aime l'idée de repo intermédiaire et spécialisé entre:

• Les prises en pension de votre développeur
• le repo GitHub central distant

Vous devez déterminer ce que vous voulez publier dans le repo GitHub à distance:

• Code à examiner (ce qui signifie une webapp Gerrit locale rassemblerait le code GitHub pour examiner)
• code qui a été examiné (ce qui signifie que vous publiez d'abord votre commits à Gerrit, et après examen du code, vous les pousser à GitHub)

Le second flux de travail est plus proche de ce que Google Android Projets suit avec Gerrit .

Dans les deux cas, un repo intermédiaire local pour Gerrit d'examiner est nécessaire.

Answer 2

Nous utilisons github , Gerrit et jenkins (successeur de hudson ). Nous relions ensemble avec Redmine bugtracking.

Avant Gerrit, nous utilisions github le dépôt principal de développement et les développeurs ont accès engager. Maintenant que nous avons la course Gerrit, github ne sert que notre publication du référentiel et que l'utilisateur a accès à Gerrit pousser à github.

Flux de production:

1. développeur vérifie à la source de GitHub.
2. développeur apporte des modifications.
3. développeur pousse à Gerrit.
4. Gerrit envoie un avis de changement pour le test jenkins d'intégration.
   • jenkins tractions change directement du serveur git Gerrit.
   • sur passe, jenkins ajoute +1 à un examen Gerrit, passe avis sur d'autres développeurs.
   • en cas d'échec, ajoute -1 jenkins à l'examen de Gerrit
   • état réussite / échec poussé à Redmine
5. autres développeurs changement d'examen, d'approuver (2)
6. Gerrit commits change à GitHub référentiel.
   • crochet GitHub Redmine des mises à jour notifie.
   • Redmine tire des changements de GitHub, Parsis commits des informations de billets.
7. développeur fetchs changements de github ... Retour à 2. [EDIT]: nous sommes passés à tirer directement de Gerrit. Github reste comme un miroir pour tirer des sources de production.

pièces manquantes:

1. Gerrit avis sur / de suivi des bogues .