ブランチの品質レベルの低下を保証するCIツールはありますか?


10

従来、CIシステムは、変更がすでにコミットされているコードベースでQA検証を実行し、リグレッションを監視して人間の介入の通知を送信することにより、統合ブランチの品質レベルの監視のみを実行します。

しかし、これらのリグレッションが検出された場合、少なくともそれぞれのQA検証が開始されてからブランチはすでに問題を抱えており、すべての原因が特定されて修復がコミットされ、新しいQA検証が行われるまで、そのような状態が続きます(またはさらに悪化します!)ブランチの品質レベルが復元されたことを確認します。この間、ブランチは通常の開発のためにブロックされたと見なすことができます。

このようなリグレッションの発生を実際に防ぐことができるCIツールはありますか?これは、コミット前の QA検証を実行し、それぞれのコミットで更新されたコードベースがそれらのコミット前のQA検証にも合格する場合にのみコミットを許可するため、最小を保証しますブランチの品質レベル?

更新:それぞれの回帰を検出できるように適切なカバレッジを備えた適切な自動QA検証がCIツールによる呼び出しに利用可能であることが前提です。


私はこの質問を理解する正しい方法(そしてあなた自身の回答でのあなた自身の推奨)について疑問を抱き続けます。「監視」を「事後」に、「防止」を「発生を防ぐ」に置き換えた場合、多かれ少なかれ同じ質問になりますか?また、違いを説明するためのシナリオ例を追加できますか?
Pierre.Vriens

@ Pierre.Vriensこれはもっと良いですか?
Dan Cornilescu 2017年

回答:


6

私が知る限り、ビルドを中断するコミットを拒否するツールを探しています。CIツールは実際にコードを修正してもリグレッションを防ぐことはできませんが、不正なコードを追加することはできませんリポジトリに。

Atlassianには、Gitフックの興味深いアプリケーションがいくつかあります

サーバー側の事前受信フックは、コードが特定の条件を満たさない限り、開発者がコードをマスターにプッシュするのを防ぐことができるため、継続的な統合を特に強力に補完します。

Gitを使用している場合、フックは非常に強力であり(SVNMercurial、およびその他のバージョン管理システムにも同様のフックがあります)、それらを使用してコミット前のチェックを実行すると便利な場合があります。

Gitのドキュメントには、このユースケースに簡単に適応できる特定の基準満たさないプッシュを拒否するフックの作成に関するページがあります

ただし、ブランチでコミットを拒否することは悪い考えであると多くの人が主張featureします。実際にバグを修正するのではなく、何らかの理由でビルドが中断したときに、CIシステムとの戦いに時間を費やすだけです。

masterあなたはそれが常にビルドを確保したい場合がありますので、分岐、それは、壊れたマージを拒否することに意味を作ることができます。以下のためにfeature支店、あなたがなり、必然的に物事を破ると、コードが生産に入っていないので、今、それは実際にあなたが完全にコミット拒否よりも、あなたを警告するために、より理にかなっています。


まあ、構築するswイメージは何が良いのでしょうか?開発者はビルドしてもコードの変更をテストできないため、同じようにブロックされます。したがって、一般に、コミット拒否を、2つの競合する要件のバランスをとることによって選択された最小のQAチェックに失敗したものに拡張します。ブロッキングから保護される開発者の数を最大化するためにできるだけ高く、QA検証の遅延が発生しないようにできるだけ低くしますプロセスを遅くしすぎないでください。
Dan Cornilescu

この例として、プルリクエストをマージできるかどうかに特定の制限を課すことができるプルリクエストモデルがあります。たとえば、私たち(私の会社)はAtlassian Bitbucket Serverを使用しており、プルリクエストをマージする前に、特定のブランチに対して少なくともNの承認とXの合格ビルドを要求するオプションがあります。これは完全にそれを拒否しません。しかし、テストが失敗したり、他の目がまだコードを見ていなかったりしたときに偶発的にマージすることを防ぎます。
アンディ・シン2017年

@AndyShinn:ええ、それは非常に便利です。GitHubは保護されたブランチとプルリクエストのチェックも提供します。
Aurora0001 2017年

1
機能ブランチで壊れたコードを許可するための1つの引数は、開発者が作業中のコードをリポジトリにプッシュできるようにすることです。これは、準備が整う前の初期のコード/アーキテクチャレビューでコードを他のユーザーと共有したり、問題のデバッグに役立てたり、休暇を取ったりする人が、他の人がアクセスできるように部分的に作業を行ったりするのに役立ちます。機能ブランチの場合、私はリンターのようなものと、プリコミットフックとしてのみ配置します。
ブラディム2017年

2

どのツールも回帰を保証できない可能性があります。これは、実行するツールよりもテストに大きく依存します。ただし、キャッチされるリグレッションが統合ブランチに入るのを防ぐのに役立ちます。これは、プリコミットフックを使用して実行できますが、プルリクエストを使用すると簡単になることがよくあります(うまくいけば、ピアコードのレビューに既に使用しているはずです)。

ブランチがその上流(PRのマージ先)で最新であり、そのテストに合格した場合、それらはマージ後も引き続き合格します。マージ後のターゲットブランチの状態は、マージ前のソースブランチの状態と一致します。

PRのソースブランチがターゲットで最新であるかどうか、およびそれがCIビルドに合格しているかどうかの両方を示すことは、(使用するツールに応じて)一般にそれほど難しくありません。これをプルリクエストをマージするための要件として(ポリシーによって、および/またはソフトウェアで適用して)使用できます。


「ブランチがそのアップストリーム(PRのマージ先)で最新であり、そのテストに合格した場合、それらはマージ後も引き続き合格します」-なぜですか?マージは不連続であり、未知数をもたらします。競合と同様に、コードは解決されるまでビルドされない場合もあります。テストを実行し、ブランチマージに合格することを確認する必要があります。安全にプレイしたいのであれば、早送りのものでもいいと思います。Apartsw.com/insights/2016/11/16/…を
Dan Cornilescu

ええと、そのような保証は可能です。私の答えを確認してください。まあ、私は明確にする必要があります:回帰とは、ブランチベースラインの結果よりも悪い結果を意味します(そして、誤検知の可能性を無視して、ベースラインを歪め、全体を脱線させ、人間の介入を必要とする可能性があるため、これらに対処する必要があります)。断続的な偽陰性は単に厄介なものであり、物事を遅くしますが、対処することができます。
Dan Cornilescu 2017年

回帰がないことは保証できません。検出された回帰がないことのみを保証できます。変更によってテストで検出されなかったリグレッションが発生した場合、それはCIツールが保証できないリグレッションです。また、2つの変更セットをマージすると未知数がもたらされますが、他の方向をマージする前に、機能ブランチで(アップストリームをマージすることにより)変更することを選択できます。ソースがターゲットと最新である場合、それは単純なマージ(早送り)であり、その後、ターゲットの状態はマージ前のソースの状態と同じになります。したがって、テストが前にパスした場合、テストはパスします。
エイドリアン

髪を分割します。CIツールをテストで構成して、気になる回帰を検出して保護することができます。私はマージについてあまり議論しません-私の目標はそれらをできるだけ避けることです、それらは全体的に問題です:)
Dan Cornilescu

私の要点は、テストを作成することで、それを保護するのはCIツールではなく、あなたです。CIツールは、ユーザーが提供するテスト以外の保証を提供できません。
エイドリアン

1

ReitveldやZuulのような真の継続的インテグレーションツール(継続的なテストだけではなく)が役立ちますが、それらは、作成したテストやコードレビューと同じくらい優れています。


しかし、Reitveldは、CIツールではなく、協調的なコードレビューツールのように見えますが、何か不足していますか?これは私が見たものです:github.com/rietveld-codereview/rietveld
Dan Cornilescu

Zuulは確かに関連しているようです。もっと詳しく調べます。
Dan Cornilescu 2017

テストは行いませんが、ブランチ管理のいくつかの側面を処理し、ゲートキーパーシステムとして機能します。これは、マージをブロックすることによって不正なコードが侵入しないようにする最善の方法です。
coderanger 2017

あなたの言っていることがわかります。まあ、それは全体的なコード品質を助けることができますが、それ自体は何の保証ももたらしません。すべてのQA検証に個別に合格する2つの完全に優れた変更でも、ブランチで出会うと破損する可能性があります。
Dan Cornilescu 2017

1

GitLABを使用すると、プロジェクト設定でパイプラインが成功した場合にのみマージを許可するように設定できるため、真に継続的な統合を実現でき、それをQAをマージ承認のリストに追加することと組み合わせて、動的環境で品質を保証できます。マスターにマージする前に。


これは機能しますが、前のマージが完了する前に2番目のマージがQAチェックを開始することを許可しない場合にのみ、そうでない場合、2番目のマージは最初のマージを認識せず、リグレッションの余地を残します。言い換えると、マージ(QAチェックを含む)は完全にシリアル化する必要があり、これは大規模なチームには対応できません。
Dan Cornilescu 2018

0

ApartCIは、リグレッションを防止するように設計されたCIシステムであり、フラットまたは増加するブランチ品質レベルを保証します。まだベータ版です。

最新のブランチ品質レベルを満たすか超えるために、変更が検証された後にのみコミットされることを確認するように、集中化された事前コミット検証を調整します。

これは、並行して行われることが多い、従来の開発者主導の事前コミット検証と比較した主な違いです。これにより、一緒にテストされなかった干渉変更によって引き起こされる回帰の余地が残ります。

このツールはまた、簡単にスケーリングできるように設計されています -非常に高い割合の着信候補変更を維持し、同じ統合ブランチで作業する数百人/数千人の開発者をサポートできます。

免責事項:私はツールの作成者であり、ツールを提供する会社の創設者です。広告の謝罪。


免責事項を追加していただいて結構ですが、個人的には質問をして、自社または製品をスパムの形に宣伝することで自己回答することを検討しています。
THelper 2017年

これが許可されているかどうかをメタについて質問しました:meta.devops.stackexchange.com/q/59
THelper

SnapCIもこれを行いました。RIP。
paul_h

@paul_h、何か欠けているものがない限り、SnapCIとその推奨代替GoCDはどちらもコミット後の検証(SCMのポーリングによってトリガーされる)に基づいているため、それらはまだ監視のみです。多分PRチェックを除いて、これらのチェックが完全にシリアル化されない限り、回帰発生率を下げることができるだけでなく、完全に排除することはできません。
Dan Cornilescu 2017

ダン、投票しない、フック。そして、まだトランク/マスターにマージされていない短命PR支店へ- trunkbaseddevelopment.com/game-changers/...
paul_h
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.