CI/CDツールのエラーは複数の要因で起こる
CI/CDツールのエラーは、表面上は同じ「失敗」として表示されても、原因はさまざまです。原因を効率よく特定するために、エラーの考え方と、発生をすぐに把握するための仕組みを最初に押さえておきましょう。
ツール・コード・環境の3方向から考える
CI/CDのエラーの原因は、大きく分けてCI/CDツール側、開発したコード側、実行環境や連携先の環境側の3つが考えられます。例えば、ビルドの失敗はコードの誤りだけでなく、実行環境の設定変更や外部サービスの停止で起こることもあります。
エラーが起きたら、直前に何が変わったかを確認しましょう。コードの変更がないのに失敗した場合は、環境やツール側の変化を疑う手がかりとして使えます。提供会社が公開している稼働状況のページも、あわせて確認すると切り分けが進みます。
失敗をすぐ把握できる仕組みを整える
エラーへの対応が遅れると、失敗した状態のまま次の変更が積み重なり、原因の特定が難しくなります。失敗をすぐに把握するために、メールやチャットツールへの通知を設定しておきましょう。
パイプラインとは、ビルドやテスト、デプロイ(本番環境への反映)を順番に自動で進める処理の流れです。通知には、失敗したパイプラインの名前やジョブ(1回分の処理)、実行ログへのリンクを含めると、確認の手間を減らせます。通知を受け取る担当を決め、対応状況をチームで共有しておくことも大切です。特定の担当者だけが対応する状態を避けると、不在時の遅れも減らせます。
CI/CDの自動ビルドが不定期に失敗する場合
同じコードなのに、成功するときと失敗するときがあるという不定期なビルドの失敗は、原因の特定に時間がかかる場合があります。考えられる主な原因を3つ紹介します。いずれか一つではなく、複数が重なっていることもあります。
依存ライブラリやバージョンの変化
ビルドでは、外部で公開されているライブラリ(共通で使うプログラムの部品)を取得して使うことがあります。ライブラリのバージョンを固定していないと、新しいバージョンが公開されたタイミングで動作が変わり、ビルドが失敗する場合があります。
また、ライブラリの取得先が一時的につながりにくい状態だと、ダウンロードに失敗することも考えられます。使用するバージョンを固定する設定や、取得したライブラリをキャッシュ(再利用のための一時保存データ)として保存する仕組みを活用すると、影響を抑えられる可能性があります。
実行環境の資源不足
ビルドを実行する環境のメモリやディスクの容量が不足すると、処理の途中で失敗する場合があります。ビルドの内容が大きくなったり、同じ環境で複数の処理が動いたりすると、資源が足りなくなることがあります。
実行ログに容量不足やメモリ不足を示すメッセージがないかを確認しましょう。クラウドの実行環境であれば、より大きな環境を選べる製品があります。自社の実行環境の場合は、不要なファイルの削除や環境の増強を検討します。
キャッシュや一時ファイルの影響
処理を速くするために使うキャッシュに、古いデータや壊れたデータが残っていると、ビルドが失敗することがあります。自社の実行環境を繰り返し使う場合は、前回の処理で残った一時ファイルが影響する場合もあります。
キャッシュを削除して再実行すると成功する場合は、キャッシュの扱いを見直しましょう。キャッシュを更新する条件を設定する、毎回新しい環境でビルドする設定にするといった方法で、再発を抑えられる場合があります。
CI/CDの自動テストでエラーが起きる場合
自動テストのエラーは、プログラムの不具合を見つけるという本来の役割を果たしている場合と、テスト自体や環境に問題がある場合があります。両者を区別することが大切です。テストの実行で起こり得るエラーの原因を2つ解説します。
結果が安定しないテスト
コードを変えていないのに、成功したり失敗したりするテストがあります。時間や日付に依存する処理、処理の待ち時間の設定が短すぎる処理、テストの実行順序に依存する処理などが原因として考えられます。
結果が安定しないテストを放置すると、本当の不具合による失敗との区別がつかなくなります。失敗の履歴から該当するテストを特定し、待ち時間の調整や、ほかのテストの影響を受けない書き方への修正を検討しましょう。
テスト環境と外部サービスの状態
テストでデータベースや外部のサービスを使う場合、それらの状態によってエラーが起こることがあります。テスト用のデータが前回の実行で書き換わっていた、外部サービスが一時的に応答しなかったといったケースです。
テストのたびにデータを初期化する、外部サービスの代わりに模擬的な応答を返す仕組みを使うといった方法で、環境の影響を減らせる場合があります。外部サービスの利用制限に達していないかも確認しておきましょう。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料請求して、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力(約60秒)でCI/CDツールの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
CI/CDの自動デプロイの反映が遅れる場合
自動デプロイが成功したはずなのに変更が反映されない、反映までに時間がかかるといった問題も起こる場合があります。遅れの原因は、CI/CDツールの中にある場合と、デプロイ先の側にある場合があります。2つに分けて解説します。
順番待ちや承認待ちによる遅れ
CI/CDツールで同時に動かせるジョブの数に上限がある場合、ほかの処理が終わるまでデプロイが順番待ちになることがあります。リリース前などで処理が集中すると、待ち時間が長くなる場合があります。
また、承認フローを設定している場合、承認者の確認が終わるまで処理は止まったままです。実行履歴で、どの段階で時間がかかっているかを確認しましょう。承認依頼の通知や代理承認者の設定を見直すことで、待ち時間を短くできる場合があります。
デプロイ先やキャッシュの影響
CI/CDツールの処理が完了していても、デプロイ先のサーバーやクラウドサービスで切り替えに時間がかかる場合があります。新しいバージョンを順番に反映する方式では、全台のサーバーに行き渡るまで時間を要することもあります。
さらに、ブラウザや配信の仕組みに古いファイルが一時保存されていると、反映されていないように見える場合があります。デプロイ先の状態とキャッシュの設定を確認し、必要に応じて古いデータを消去する処理をパイプラインに組み込みましょう。
CI/CDのパイプライン並列実行で起こり得る不具合
並列実行は処理時間の短縮に役立つ一方、複数の処理が同時に動くことで、順番に実行していたときには起きなかった不具合が生じる場合があります。代表的な2つの原因と、その対策を紹介します。並列化を始める前の確認項目としても活用してください。
共有リソースの競合
並列に動く複数のジョブが、同じデータベースやファイル、テスト用のアカウントを使う場合があります。このとき互いのデータを書き換えてしまい、テストが失敗する現象を競合と呼びます。
対策として、ジョブごとに別のデータベースやデータを用意する、名前に識別子を付けて区別するといった方法があります。同時に使ってはいけない資源がある場合は、その処理だけを順番に実行する設定にできるかも確認しましょう。
実行順序への依存
順番に実行していたときは、前の処理で作られたファイルやデータを、後の処理が暗黙のうちに使っていたというケースがあります。並列実行に切り替えると、前提となる処理が終わる前に後の処理が始まり、失敗する場合があります。
パイプラインの設定で、ジョブ同士の依存関係を明示しておきましょう。前の処理の成果物を次の処理に受け渡す機能を使えば、処理の順序と受け渡すデータを管理できます。並列化する前に、各処理が単独で動くかを確認することも大切です。
CI/CDのエラーに備える運用の仕組み
エラーの発生をゼロにすることは難しいため、起きたときに素早く原因を特定し、復旧できる仕組みを整えておくことが大切です。エラーへの備えとして取り組みたい2つのポイントを紹介します。製品を比較する際の確認項目にもなるでしょう。
ログと履歴による原因の追跡
エラーの原因を特定するには、実行ログと過去の実行履歴が重要な手がかりです。失敗した処理のログだけでなく、直前に成功したときのログと比べると、何が変わったのかを見つけやすくなります。
ログの保存期間は製品やプランによって異なるため、調査に必要な期間を残せるかを確認しましょう。不定期な失敗は、失敗の回数や時間帯を記録して傾向を見ることで、原因の手がかりが得られる場合があります。調査の結果は共有スペースにまとめ、チームの知識として残しましょう。
再実行とリトライの使い分け
一時的な通信の不調などが原因の場合、失敗した処理を再実行すると成功することがあります。製品によっては、失敗時に自動で再実行するリトライの設定ができるものもあります。
ただし、リトライに頼りすぎると、根本的な原因が放置されるおそれがあります。リトライで成功した場合も記録を残し、同じ処理で繰り返し発生していないかを定期的に確認しましょう。再実行で解決しない場合は、ログをもとに原因を調査します。
エラー時の対応機能を確認したいCI/CDツール
ビルドやテストのエラーに備える観点で比較を進める際の候補として、CI/CDツールを紹介します。ログの確認方法や再実行の可否は製品によって異なるため、資料で確認しましょう。
CircleCI (CircleCI)
- コード変更ごとに自動テストで品質を検証
- クラウド・サーバー版で多様な開発環境に対応。
- ワークフローとキャッシュでパイプラインを高速化。
Jenkins (CloudBees, Inc.)
- ビルドとテストを自動化し継続的に変更検証。
- パイプライン定義で標準化CI/CDフロー構築。
- 豊富なプラグインで多様なツールや環境と連携可能。
Travis CI (Travis CI GmbH)
- CI/CDパイプラインの短時間構築
- 並列処理や多環境ビルドに対応
- GitHub等と連携し、コード変更時にビルドとテストを自動実行
CloudBeesCodeShip (CloudBees, Inc.)
- DockerベースのCI/CD環境を迅速に構築
- 主要コードリポジトリと連携可能
- 高度なセキュリティとコンプライアンス対応
OctopusDeploy (Octopus Deploy)
- 多様な技術・プラットフォームに対応
- 自動デプロイ、リリース管理、環境設定、セキュリティ制御機能
- 数千組織の利用で、ソフトウェアデリバリーパイプラインを効率化
GCP Cloud Build (グーグル合同会社)
- 固有の環境と自由なスケーリングができるプライベートプール!
- 15種類のマシンタイプから選択し最大数百の同時ビルド!
- Google社提供のマシンでビルドを大幅高速化!
AzureDevOps (日本マイクロソフト株式会社)
- あらゆる環境でCI/CDが可能
- ソース管理、作業管理などアジャイル開発機能が充実。
- テスト統合、品質保証からデプロイまで包括サポート。
まとめ
CI/CDツールのエラーは、ツール、コード、実行環境、連携先の状態など複数の要因で起こる場合があります。ビルドの不定期な失敗は依存関係や資源不足、テストのエラーは不安定なテストや環境の状態が原因の候補です。デプロイの遅れは順番待ちやキャッシュ、並列実行の不具合は競合や順序への依存を疑いましょう。あわせて、ログや通知、再実行の仕組みを整えておくことが大切です。エラー対応の機能を比較したい方は、ITトレンドの資料請求を活用してください。

