Github、Gerrit、Hudson（Jenkins）ワークフロー

Question

Github、Gerrit、Hudson（Jenkins）を一緒に使用し始めたばかりです。そして、ワークフローについていくつかの考えが必要です。

GitHubをメインのリモートリポジトリとして使用したいと思います。主にコードレビューにはGerritを使用したいだけでなく、ハドソンのビルドトリガーにも使用したいと思います。

しかし、現時点では、私はこのためのワークフローを通して考えるのに苦労しており、他の人が自分でやったことを聞きたいと思っています。考え？

Answer 1

私はGerritを直接使用していませんが、中間で専門的なレポのアイデアが好きです。

• 開発者のレポ
• 中央のGithubリモートレポ

したがって、リモートGitHubリポジトリで公開したいものを決定する必要があります。

• レビューするコード（ローカルGerrit WebAppがGitHubコードを引いて調べることを意味します）
• レビューされたコード（最初にGerritにコミットを公開することを意味し、コードレビュー後、GitHubにプッシュします）

2番目のワークフローは何に近いです Google AndroidプロジェクトはGerritで続きます.

どちらの場合も、Gerritが調べるための中間ローカルリポジトリが必要です。

Answer 2

私たちは使用しています github, ゲリット と ジェンキンス （後継者 ハドソン）。私たちはそれを一緒に結びます redmine バグトラッキング用。

Gerritの前は、GitHubをプライマリ開発リポジトリとして使用していて、開発者はアクセスしていました。 Gerritが実行されたため、Githubは公開リポジトリとしてのみ使用され、GerritユーザーのみがGitHubへのプッシュにアクセスできます。

ワークフロー：

1. 開発者はGitHubからソースをチェックアウトします。
2. 開発者は変更を加えます。
3. 開発者はGerritにプッシュします。
4. Gerritは、統合テストのためにJenkinsに変更通知を送信します。
   • Jenkinsは、Gerrit Gitサーバーから直接変更を引き出します。
   • パスで、ジェンキンスは+1をGerritレビューに追加し、他の開発者にレビューを合格します。
   • 失敗すると、ジェンキンスはGerritレビューに-1を追加します
   • Redmineにプッシュされたパス/フェイルステータス
5. 他の開発者が変更をレビューし、承認（+2）
6. GerritはGithubリポジトリの変更をコミットします。
   • Github Hookは、Redmine of Updatesに通知します。
   • RedmineはGithubから変更を引き出し、Parsesはチケット情報のメッセージをコミットします。
7. 開発者はGithubからの変更を2. [編集]に戻ります。[編集]：Gerritから直接引っ張りました。 Githubは、生産源を引くための鏡として残っています。

不足しているピース：

1. 縛るピース バグトラッキングとの間でのGerritレビュー.