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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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