私の会社はCI / CDを統合しています。これまでのところ、私が理解しているものからCIを実装しています。現在、開発者がコードをgitリポジトリにプッシュすると、CIパイプラインが実行されます。
現在、CIパイプラインには、プロジェクトの構築と静的コード分析の実行が含まれており、コーディング標準に適合していることを確認しています。次にテストを実施します。ビルドと静的コードの分析には、現在約3分かかります。私が読んだことからすぐに問題を修正することは、CI / CDにとって重要です。単体テストを追加すると、パイプラインの実行に約10分かかることが予想されます。
したがって、私の質問は、CIパイプラインが完了するのを待つか、次のタスクに進んでパイプラインの問題が存在する場合はそれを修正するためにプル/マージリクエストを行う必要があるかということです。または、座ってパイプラインの実行を監視する必要がありますか？
回答:
座ってパイプラインの実行を監視しますか？
いいえ、それはあなたが効率的に働く方法ではありません。
開発者がコミットをソース管理リポジトリにプッシュすると、CI / CDパイプラインがトリガーされます。
開発者は、必要に応じて、適切に作成されたプルリクエストをいつでも投稿できます。通常、「進行中のビルド」/「失敗したビルド」/「成功したビルド」を表す視覚的なマークがあります。
通常、これらの基準がすべて満たされるといつでも分岐をマージできます。
これらの基準のいずれかが満たされない場合、それらを修正する必要がありますが、開発者はこのタスクを実行する時間または優先度がある場合はいつでもそれを実行します。
パイプラインが10分未満になるように最善を尽くすことをお勧めします。これを有効にするためにテストを並行して実行できます。jonasが答えると、プルラインの作成に時間を費やすことができます（パイプラインの実行中）。
コンテキストの切り替えは生産性に悪影響を与えるため、別のタスクを取り上げるよりも、その時間を利用して、行った変更に関連する他の作業に取り組むことをお勧めします。これに関連して更新される可能性のあるドキュメントがあるかもしれません。それが注目に値する機能である場合、彼はそれを操作する方法を示す短いgifを作成できます。コードの変更をもう一度見ても、次回のコードの改善方法を考えるのに役立ちます。今回は、他の開発者のプルリクエストとコード変更のレビューにも使用できます。
彼らがその10分で別の機能の開発に取り掛かった場合、彼らがそれに戻るまでに10分より長くなる可能性が高く、その仕事は彼らの心の新鮮さを失います。CIが失敗すると、何が問題だったかを覚えてコードを修正するのが難しくなります。
では、バージョン管理ツールがGitおよびCIツールのJenkinsであると想定しましょう。したがって、Devは問題の機能ブランチを作成します。次のスキャンでこの機能ブランチを検出してCIステップを実行するCIツールにマルチブランチパイプラインまたはワークフローがあります。
したがって、確認する必要があるのは次のとおりです。
PR / MRを上げる前は、CIジョブはグリーンです。緑でない場合は、PR / MRを上げる必要はありません。明らかに、開発者は他のタスクを実行してから、戻ってこのタスクの問題を修正できます。これは、タスクの優先度に応じた選択です。CIパラメーターを確認することで、PRの発生を制御することもできます（開発者がそれほど信頼しておらず、壊れたビルドのPRを継続的に発生させる場合）。
PRが発生すると、コードレビュー担当者が問題がなければ、レビューとマージを行います。コードレビューアは他の開発者でもかまいません。彼/彼女の責任は、コードをレビューし、それが「完了の定義」の基準内にあるかどうかを確認することです。DoDは主にアジャイル用語ですが、アジャイルとDevOpsは連携しています。
コードがマージされると、メインブランチのCIは緑色になります。そうでない場合は、コードをロールバックし、問題を修正する必要があります。通常、メインブランチも環境にデプロイされ、ロールバックしないと、環境全体が破壊されるためです。
明らかに、ビルド後のアクションはコミッターに通知します。開発者はビルドを壊したので、開発者は他のタスクを実行でき、とにかくメールを受け取ります。