continuous-integration - GitHub、Gerrit、Hudson(Jenkins) ワークフロー

Question

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

GitHub をメインのリモートリポジトリとして使用したいと考えています。主にコードレビューに Gerrit を使用したいと考えていますが、Hudson でのビルドトリガーにも使用したいと考えています。

ただし、現時点では、このワークフローについて考えるのに苦労しているので、他の人が自分で何をしたかを聞きたいと思っています. 考え？

score 26 · Accepted Answer

github、gerrit、jenkins（hudsonの後継）を使用しています。バグ追跡のためにredmineと結び付けます。

gerritの前は、主要な開発リポジトリとしてgithubを使用しており、開発者はコミットアクセス権を持っていました。gerritが実行されたので、githubは公開リポジトリとしてのみ使用され、gerritユーザーのみがgithubにプッシュするためのアクセス権を持ちます。

ワークフロー：

開発者はgithubからソースをチェックアウトします。
開発者が変更を加えます。
開発者はgerritにプッシュします。
gerritは、統合テストのために変更通知をjenkinsに送信します。
- jenkinsは、変更をgerritgitサーバーから直接プルします。
- パスで、jenkinsはgerritレビューに+1を追加し、他の開発者にレビューを渡します。
- 失敗すると、jenkinsはgerritレビューに-1を追加します
- 合格/不合格ステータスがRedmineにプッシュされました
他の開発者が変更を確認し、承認します（+2）
gerritは変更をgithubリポジトリにコミットします。
- githubフックはredmineに更新を通知します。
- redmineはgithubから変更をプルし、コミットメッセージを解析してチケット情報を取得します。
開発者は変更をgithubからフェッチします...2に戻します。[編集]：gerritから直接プルするように切り替えました。Githubは、生産ソースをプルするためのミラーとして残っています。

score 5 · Accepted Answer

私は Gerrit を直接使用したことはありませんが、次の間の中間および特殊なリポジトリのアイデアが気に入っています。

そのため、リモート GitHub リポジトリで何を公開するかを決定する必要があります。

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