5

.NET プロジェクトを Jenkins および SVN と統合し (現在 git に切り替える機会があるかどうかはわかりません)、ビルド後および本番前にコードをレビューできるようにするための最良の方法は何ですか?

私はこのようなものが欲しいです:

  1. 開発者がリポジトリをチェックアウトします。
  2. 開発者は何かを実装します。
  3. 開発者は変更をリポジトリ A (SVN) にコミットします
  4. Jenkins はリポジトリ A (SVN) を監視します
  5. Jenkins がビルドを開始します。
  6. Jenkins が単体テストを開始します。
  7. 全て大丈夫。
  8. Jenkins が変更をリポジトリ B にコミットします (リポジトリのレビュー)。
  9. QA 担当者がコードをレビューします。
  10. QA 担当者が変更をリポジトリ C (本番) にコミットします

6a. すべてがOKというわけではありません。6b. Jenkins は、開発者のコ​​ミットがビルドを壊したという通知を開発者に送信し、ステップ 2 に戻ります。

手順 1 ～ 6 の実行方法を知っています。多かれ少なかれ。MSBuild ですべてをビルドできることはわかっているので、これは難しいことではありませんが、手順 6 ～ 9 を構成する方法が正確にはわかりません。

ギット：

git を使用すると、はるかに簡単になると思います。ビルド後のアクションに Git Publisher があり、変更をブランチ (「review-branch」など) にプッシュして、レビュアーに通知を送信できることがわかりました。彼らはリポジトリをプルし、すべてが素晴らしいでしょう. うーん、レビュー ブランチにプッシュする代わりに、Jenkins はそのブランチにプル リクエストを作成する必要があります。しかし、私が言ったように、それは git のシナリオになります。私にとってはgitの方が良いオプションですが、おそらく不可能なので、ここに書きました。git について話している場合、何かが欠けていないかどうか知りたいだけです。

SVN:

ここでは、それを行う方法がわかりません。Jenkinsには、2番目のSVNリポジトリへの「プッシュ」を処理するための組み込み機能がありますか? コードをリポジトリ B にコミットするにはどうすればよいですか?

レビュー: 最良のアプローチは何ですか? - (GIT) Jenkins はプル リクエストを作成します -- 可能であれば - (GIT) Jenkins は 2 番目のレビュー ブランチにプッシュし、電子メールで通知を送信するか、課題トラッカー (Redmine/Jira) でいくつかのチケットを作成します - (SVN) Jenkins はレビュー リポジトリにコミットします電子メールを送信するか、チケットを作成します。- または、すべてを ReviewBoard/Gerrit などと統合する方がよいかもしれません。現在、私はそのようなソフトウェアを使用したことがなく、Gerrit は少し面倒だと読みました。

4

2 に答える 2

4

覚えておく必要があることがあります。

バージョン管理システムでは、すべてが元に戻せます

つまり、コミットされたコードのコード レビューを行い、新しいコミットで問題を修正できます。実際、Subversion はすべてのコード変更を含む適切なリビジョン番号を提供するため、これは Subversion で行うのに適しています。このように、誰もが同じページにいます。( 「リビジョン 23,340 を確認しています」 )。ほとんどのコード レビューは、null ポインターのチェックを忘れているなどのことを探しています。コードが本当に悪い場合、Subversion は変更を完全に元に戻すことを容易にします。

Jenkins は、ビルドに問題がある場合はすぐに通知します。私たちのポリシーでは、開発者は問題を修正するか、変更を元に戻すために 10 分かかります。(90% の確率で、彼らは変更を取り消します)。システムのセットアップが完了したので、開発者と Jenkins の両方が同じビルド メカニズムを使用します。これにより、開発者は変更をコミットする前にビルドをテストし、単体テストを実行できます。

これが、ほとんどのバージョン管理システムにシェルビングがなく、3 セットのリポジトリとほとんどの場所が表示されない理由です。ここはあなたのアパートではありません。あなたのお母さんがあなたのコード履歴を見に来ることはありません。きちんと整頓されている必要はありません。何が起こっているかを反映させましょう。

簡素化する。最後の 3 つのステップを削除します。コード レビューを行い、同じリポジトリでコードを修正します。これは、維持する必要があるリポジトリが 66% 少ないことを意味します。66% 少ないハードウェア。と、

本当に必要なのは、コード レビューを追跡する方法だけです。Crucibleのようなものを使用できますが、Jenkins も使用できます。Jenkins を使用して変更を追跡するには、次の 2 つの方法があります。

  • 個々のビルドに説明を追加: 簡単に実行でき、追加のプラグインは必要ありません。説明は柔軟です。プロジェクトに入り、すべてのビルドのリストを見て、説明を見ることができます。シンプルで簡単。
  • プロモーテッド ビルド プラグイン: 2 つあります。1 つは標準のもので、もう 1 つは単純なものです。

プロモーテッド ビルド シンプル プラグインは、...まあ... シンプルです。Jenkins 構成ページでさまざまなプロモーション レベルをすべて指定すると、それがすべてのビルドで使用されます。個々のビルドごとに 1 つの昇格レベルのみが許可され、すべて手動で行われます。

標準のプロモーテッド ビルド プラグインは少し手間がかかりますが、より強力です。これにより、各 Jenkins ジョブが独自のビルド プロモーション スキームを持つことができます。プロモーションは、手動と自動の両方で行うことができます。ビルドがプロモートされると、電子メールの送信、サーバーへのデプロイなどの他のアクションを生成できます。さらに、複数のプロモーションを表示できます。次のプロモーション レベルを想像してください。

  • Build is passed Unit Testing : ビルドが完了し、その単体テストに合格した場合の自動昇格。コード レビューを担当する QA 担当者に電子メールを送信できます。
  • コード レビューが完了しました。大きな問題はありません: ビルドは一般的に良好です。マイナーな問題がいくつかあるかもしれませんが、このビルドを使用して他の環境に展開し、さらにテストすることができます。
  • コード レビューが完了しました: 重大な問題が見つかりました: このビルドには重大な問題があり、さらにテストするために別の環境に展開する準備ができていると見なされるべきではありません。
  • 開発者はこのビルドで見つかった問題を修正しました:ビルドはまだ悪いですが、少なくとも開発者がこのビルドの問題を処理すると主張していることは知っています。
于 2012-11-30T18:29:51.967 に答える
0

【「できるか」の部分への回答】

はい、ジェンキンスはあなたが説明したことを行うことができます。リポジトリにSVNを使用して必要なすべてのピースを使用するセットアップジョブがあります(ただし、手順はありません)。GITについてはよくわかりません。

  1. Jenkins が単体テストを開始します。

Windows バッチ ファイルを実行するためのビルド ステップを追加します。

  1. Jenkins が変更をリポジトリ B にコミットします (リポジトリのレビュー)。

SVN を使用している場合は、 Jenkins SVN Publisher Pluginを確認してください。GIT の場合、 Git プラグインを使用すれば可能のように見えますが、ちょっとした警告があります。あなたが遭遇するかもしれない問題。」

于 2012-11-30T16:30:22.357 に答える