11

現在、約 12 名の開発者からなるチームで Gerrit を使用しています。

これが現在のワークフローです:
1. 開発者は master からブランチします
2. 開発者はローカル ブランチで作業し
ます 3. 開発者は gerrit にプッシュします。4. Gerrit
は Jenkins を呼び出し、変更セットに対して単体テスト (および Selenium テスト) を実行します。失敗した場合、コミットは開発者にキックバックされます。それ以外の場合、Jenkins はコミットを +1 します。
5. レビュアーがコミットを見て +1 する
6. 上級レビュアーがコミットを見て +2 すると、変更セットが refs/head/master (つまり、実際のブランチ) にマージされる

私たちはこのワークフローが気に入っています。それは素晴らしい。それは私たちの開発に素晴らしいプロセスと規律をもたらし、以前は見過ごされ無視されていたコードレビューのボトルネックからやるべきことのリストを作成し、誰もがそれを喜んでいます.

× - インターミッション - ×

現在、タスク管理を Jira に移行しようとしています。コードレビューをシバン全体の一部にするのは自然な統合のように思えたので、セットアップ中に Crucible もセットアップしました。私ができないのは、私たちが愛するようになった上記のワークフローを再現することです. Jira/Crucible の統合により、すべてのリポジトリをゲートキーピングする必要がなくなったため (そして Atlassian の Stash にお金を払いたくないので)、コードを Bitbucket にプッシュすることになります。悪いコードは「ゲートキープ」されなくなり、テストやコードレビューに合格する前に開発者によってマスターにマージされるため、マスターで直接作業することはできなくなりました。master ブランチから除外する唯一の解決策は、フォークのようです。わかりました、それは面倒ですが、私はそれで転がることができました. しかし、どうすれば開発者からコミットを取得できますか ' コードレビューを通過した後、フォークはマスターブランチにマージされますか? それは、少しでも似たようなことをした人、または私の状況でそれを達成する方法を知っている人から聞きたいことです.

これらすべてに代わる方法は、 https://github.com/hobbs/jirretを使用して Jira と Gerrit の統合を試みることですが、これはJira がまだサポートしているが開発を行わない XML RPC を使用します。

4

3 に答える 3

4

Vic、開発者のフォークから変更を取得して元のリポジトリのマスターコード行に取り込むには、Bitbucketでプルリクエストを使用できます。それらは、あなたが行っているCrucibleコードレビューを補完するものです。フォークが面倒な場合は、リポジトリに「統合」ブランチを作成して、開発者に頻繁にコードをプッシュしてもらうことができます(ピアレビューの準備が整う前であっても)。そのブランチは、マスターを汚染することなく、統合の問題が表面化して解決できる一種のスープになります。Atlassianの一部の開発チームは統合ブランチを使用しており、Bambooのサポートを利用して、CIスキームを新しいブランチに自動的に適用し、各ビルドでブランチ間を自動マージします。通常、あなたは dコードをdevブランチにプッシュするたびに、Bambooにdevブランチを統合にマージさせます。競合を早期に発見するのに本当に役立ちます。

マットがリンクしているブログでは、この種のワークフローについてさらに詳しく説明しています。基本的なワークフローは、使用するCIツールに関係なく成功する可能性があります(Bambooはそれを非常によくサポートしており、優れたJIRA統合を備えています)。

これがお役に立てば幸いです。

于 2012-08-20T17:17:46.990 に答える
1

プログラミングを行うことを気にしない場合は、Jira スクリプト スーツを使用して、Jira ワークフロー トランザクションを使用してサーバー上で実際のコードを実行し、それに応じて課題のコンテンツ / ステータスを更新することができます。動的コンテンツ (ローカル ファイルまたは任意のリモート サーバーから取得) を表示するには、Jira ビヘイビアー プラグイン使用し、Javascripts および HTML コードを使用します

前述したように、ある程度のプログラミングが必要ですが、元のワークフローを Jira に統合できます。

ちょっとしたメモ - 「Jira はまだサポートしているが、今後開発を行う予定のない XML RPC」ですが、この API は非常に強力で、他の API にはない機能を備えているため、今後開発されることはありませんが、そのままで、ほとんどのニーズに適合することがわかります。

その助けを願っています。

于 2012-08-18T09:26:15.237 に答える
0

現在、Bitbucket のトラッカーで、非常によく似たものについて尋ねるチケットを開いています: https://bitbucket.org/site/master/issue/5652/allow-for-pull-requests-to-require

残念ながら、Atlassian から返された回答は、「申し訳ありませんが、それを行うつもりはありません。Stash を購入してください」というものだったようです。私たちが抱えている問題は、Stash が現在ホストされているソリューションではなく、それをホストするためのインフラストラクチャを自分でセットアップする計画がないことです (実際、私たちは以前に DID を行いましたが、Atlassian と話し合ったところ、彼らのホストされたソリューションに移行することになりました)。 )。Stash で既に作業を行っていることを考えると、Bitbucket の「エンタープライズ」機能としてこれを提供しない理由はよくわかりません。現状では、開発者がこれらのタイプのワークフローに非常に興味を持っていることを示すために、人々にそのチケットにコメントしてもらうことしかできないと思います (その点で GitHub との差別化になる機能です!)。

于 2013-01-14T20:22:48.833 に答える