チームを減速せずに自動テストをCI/CDに統合する| Abhishek Verma | 9月、2025年

自動化は配信を加速することになっています。しかし、多くのチームでは、反対のチームが行われます。パイプラインは長期にわたる回帰パックで詰まり、Flaky Failuresブロックリリース、開発者はテストの実行を完全にスキップし始めます。

私はこれを直接見ました。私たちのジェンキンスのパイプラインはかつて膨らみました 90分、そして開発者はフィードバックを待つのが嫌いでした。修正は、テストを削除するのではなく、です それらを戦略的にCI/CDに統合します そのため、自動化はチームを遅くするのではなく、スピードアップします。

これは、CI/CD内の自動化を合理化するために使用したアプローチです。

⸻

1.テストスイートをティアします

すべてのテストが等しいわけではありません。それらをカテゴリに分割します：

• 煙検査（5〜10分） →クリティカルフローのみ。すべてのコミットで実行します。

• 回帰テスト（30〜60分） →完全なカバレッジ。毎晩またはオンデマンドを実行します。

• パフォーマンス/セキュリティテスト →スケジュールされており、ビルドをブロックしないでください。

結果：開発者は、1時間待たずに高速フィードバック（ログインまたはチェックアウトを破りましたか？）を取得します。

⸻

2。テストを並行して実行します

60分の回帰は、並行して実行できる場合、60分を意味しません。

• 使用 並列実行をテストします またはJunit 5。

•INFRAをスケーリングします Dockerizedセレングリッド または、browserstack/ソースラボなどのクラウドプラットフォーム。

•テストデータの衝突に注意してください（各テストは独立している必要があります）。

📌結果：並列化だけでランタイムを65％削減しました。

⸻

3.高速で失敗し、スマートに失敗します

すべての障害でパイプラインをブロックしないでください。

•停止するジョブを構成します 重大な煙の故障 のみ。

•回帰障害の場合→マージを許可しますが、調査のためのフラグの結果。

•一時的な障害のためにRETRYロジックを追加します。

📌結果：問題が発生しながら、ビルドが流れ続けます。

⸻

4。レポートを最適化します

開発者は、生のログを掘るのが嫌いです。

• 使用 魅力/範囲のレポート クリアスクリーンショット +エラーメッセージ付き。

•要約されたSlack/Teamsの通知を送信します。

•タグ障害（クリティカル対マイナー）。

📌結果：より速いトリアージ=より速い修正。

⸻

5。CI/CD統合の例（Jenkins）

典型的なパイプラインは次のように見えました：

pipeline {
stages {
stage('Build') { steps { sh 'mvn clean package' } }
stage('Smoke Tests') { steps { sh 'mvn test -Psmoke' } }
stage('Deploy to Staging') { steps { sh './deploy.sh' } }
stage('Regression Tests') { steps { sh 'mvn test -Pregression' } }
}
post {
always {
allure includeProperties: false, jdk: '', results: [[path: 'allure-results']]
}
}
}

煙検査→高速検証。

回帰→ステージングに並列化されています。

Allure→Readableレポート。

⸻

6。学んだ教訓

•階層化テストは、開発者の信頼を復元しました。

•並列実行には、適切なテストデータ分離が必要です。

•クリアレポートは、合格テストと同じくらい重要でした。

⸻

結論

CI/CDの自動化はバランスについてです。すべてのテストを同じように扱うと、パイプラインが窒息します。

その代わり、 ティアテスト、並列化の実行、失敗スマート、およびレポートの最適化。このようにして、自動化は、それを減速する代わりに配達を本当にサポートします。

codantあなたのパイプラインは今日どれくらい時間がかかりますか？聞いてみたいです。