CoroidあなたのAIソフトウェアファクトリー
ドキュメント

リリース

マージから本番環境へのデプロイまで、特定のコミットを追跡し、チェック項目や承認、実際にデプロイされた内容の証拠を確認できます。

このAIソフトウェアファクトリーは、タスクや計画をレビュー済みのプルリクエストに変換します。それらがマージされると、リリースが次の疑問に答えます：その作業のうちどれがどの環境で実行されており、そこへの配置が安全だったか？

リリースでは特定の Git コミットを固定し、Staging や本番環境といった各環境を通じてそのコミットを追跡します。そのコミットはすでにデプロイブランチ上にある場合もあれば、Coroid が複数の開いている pull request をまとめて 1つのリリース pull request にし、そのマージコミットをリリースとする場合もあります。各ステップで Coroid はコミットをチェックし、指定された承認を収集し、CI/CD が報告するデプロイ情報を記録します。Coroid は単独の判断でリリースがデプロイされたと判定することはありません。パイプラインまたは外部デプロイを記録する担当者が確認する必要があります。

Coroidファクトリー

  1. タスクまたは計画

    エージェントが計画・構築・テストを実施

  2. プルリクエスト

    証拠に基づきレビューが行われる

  3. マージ済み

    ユーザーまたはリポジトリのルールによりマージされる

リリース

  1. リリース

    ピン留めされた1つのコミット

  2. ステージング

    チェック・承認・デプロイ

  3. 本番環境

    チェック・承認・デプロイ

このファクトリーではレビュー済みかつマージ済みの成果物が生成されます。リリースは1つのマージ済みコミットを取り、各環境へと進められます。

1分で理解する概要

  • リリース：1つのコミット、名称、そして任意のバージョン。バージョン例えば 2.4.0は任意のため、タグなしでも継続的デリバリーが可能です。
  • 環境：ユーザーに届くまでの途中のステップで、Staging や本番環境などが該当します。各プロジェクトで独自のステップとその順序が定義されます。
  • ロールアウト：リリースが現在到達している環境を指します。
  • 作業：リリース用に計画されたタスクと、マージされた変更内容で、全体に対する完了割合で表示されます。
  • 各環境での4つのステップ：チェック項目、承認、デプロイ、ヘルスチェック。リリースページでは常に処理が必要なステップが最初に表示されます。
  • バンドル：開いている pull request から構築されるリリースです。Coroid がそれらを指定した順序で1つのリリースブランチにマージし、1つのリリース pull request を作成します。バンドルリリースには5番目のステップバンドルがチェック項目の前にあります。

リリースを一目で確認する

「リリース」を開くリリースは各プロジェクトのメインサイドバー、または特定のプロジェクトのリリースタブにあります。一覧には各リリースの作業進捗、環境へのロールアウト状況、ステータスが表示されます。タブを使って進行中、既にリリース済み、または終了したリリースを切り替えられます。

リリースを選択してそのページを開きます。

  1. 1ステータス。 リリース全体の現状を示します。
  2. 2ロールアウトと作業内容。 これまでに到達した環境と完了した計画済み作業。該当するステップを確認するには、任意の項目を選択してください。
  3. 3手順。 選択した環境における4つの手順。操作が必要な手順が開いています。
  4. 4配信される内容。 コミット内で確定されたマージ済みの変更点、計画された作業、および前回のデプロイ以降のコミット内容。
ステージング環境に到達し、本番環境へのデプロイ準備が整ったリリースです。

ロールアウト追跡も切り替え機能として利用できます。該当環境を選択すると、その環境の4つのステップが表示されます。ページはリリースがまだ到達していない最初の環境から開くため、次に行うべき作業がすぐに確認できます。

各環境での4つのステップ

  1. 1チェック

    Coroid

    指定されたコミットに対して品質チェックが実施され、必須のチェックリスト項目が確認されます。

  2. 2承認

    貴社のチーム

    設定されたルールに従い、該当する人々がこの環境向けのコミットを承認します。

  3. 3デプロイ

    貴社のCI/CD

    Coroidまたは自動的に貴社のパイプラインがデプロイを開始し、結果を報告します。

  4. 4ヘルス状態

    Coroid

    確定したデプロイの後、キャニオン・チェックにより環境が監視されます。

すべての環境で同じ4つの手順が繰り返されます。各手順では担当者が明記されています。

チェック項目「チェック項目を実行」を選択チェック項目を実行。Coroidがプロジェクトのリリース検証用Quality Graphを正確なコミットに対して実行し、関連するすべての変更がそのコミット内に含まれていることを確認します。該当環境に必要なチェックリスト項目もすべて完了している必要があります。リリースを妨げる要因がある場合、その内容がこのステップに記載されます。コミットや関連変更を変更すると以前のチェック結果は無効となり、再度実行するよう求められます。

承認チェック項目が通過すると、設定されたルールで許可されたユーザーが承認できます。このステップには必要な承認数と役割が表示されます。リリースノートの承認が必須の場合、ノートの承認もここで行います。

デプロイチェック項目と承認が完了すると、リリースは該当環境へのデプロイ準備が整います。Coroidがその環境用にGitHub ActionsまたはGitLab CI/CDに接続されている場合、オーナーまたは管理者が～にデプロイを選択すると、Coroidが正確なコミットのためのパイプラインを開始します。そうでない場合はパイプラインが自動でデプロイし、結果を報告します。いずれの場合も、成功が確認されて初めてこのステップが緑色に変わります。

ヘルスチェックデプロイが成功すると、キャニオン用のQuality Graphが設定されている場合、Coroidがそれを実行します。キャニオンが正常であれば環境は健全と判断されます。異常な場合は対応が必要と表示され、復旧オプションが提供されます。キャニオンが設定されていない場合、健全と仮定するのではなく、ヘルス状態は不明のままです。

ステータスの意味

ステータス意味
下書きまだコミットが固定されていません。バンドルリリースはリリース pull request がマージされるまで下書きのままです。
準備中コミットは固定されていますが、まだ一部でチェックや承認が不足しています。
ブロック中チェック項目は実行されましたが、何らかの理由でリリースが停止しています。
準備完了少なくとも1つの環境においてチェックと承認が完了しました。まだデプロイは行われていません。
配信中現在、デプロイが実行中です。
部分的に配信済み一部の環境にはリリースが到達しましたが、すべての環境には到達していません。
配信済みすべての環境にリリースが到達しました。
失敗またはキャンセルリリースは停止し、今後続行されません。
履歴記録デプロイ証拠が存在する前に作成されたもので、デプロイの証明とはみなされません。

準備完了「準備完了」だけではデプロイされたことにはならない。確認済みのデプロイメントがあって初めて、リリースはロールアウト工程で前進する。

ワークフロー

プロジェクトのリリースを設定する

これはプロジェクトごとに1回だけ行います。開くにはリリースを選択し、リリース設定を選んでプロジェクトを指定します。

  1. 「環境」では、ステージングを本番環境より先に配置するなど、適用順序を設定する。

  2. 「承認ルール」では、各環境ごとに承認数や対象ロール、チェック項目などのルールを定義する。ルールが公開されていなければ、環境のチェックを通過できない。

  3. 「デプロイパイプライン」では、Coroidがデプロイを開始するか、自社のパイプラインが実行するかを選択する。その後、報告用のトークンを作成し、CI/CDがデプロイ内容をCoroidに伝えられるようにする。

  4. 「バージョニング」では、各リリースのバージョン情報の取得元を指定し、環境ごとにバージョンURLを設定して、Coroidがそこで実行される内容を確認できるようにする。

リリース設定では各画面の手順を案内する。ビルドにバージョン情報を組み込むでは、バージョン情報がアプリケーションにどのように反映されるかを説明する。

計画した作業をリリースする

同時にリリースする内容が事前に決まっている場合に使用する。

  1. コミットが特定される前にリリースを作成する。最初はドラフト状態になる。
  2. リリースに含めるタスクの対象リリースを設定する。それらは「 計画タスク」に表示され、タスクが完了するにつれて作業バーが埋まっていく。
  3. 作業がマージされたら、「詳細を編集」を選び、リリースするコミットを指定する。Coroidがそのコミットに含まれるマージ済みの変更内容を確認する。
  4. 最初の環境で4つの手順を踏み、次の環境でも同様に進める。

未マージのプルリクエストをまとめる

Coroidやチーム内で待機中の複数のプルリクエストをまとめて一緒にリリースしたい場合に利用します。

  1. チェックアウト合計額を修正#12チェックを通過
  2. 注文エクスポート機能を追加#15Coroidタスク承認済み
  3. 検索インデックスを再構築#18下書き
  1. Coroidの順序では最も安全なものが先頭に来ます。ユーザーがチェックを入れて並べ替えられます。
  2. 一つのリリースブランチに、順番通りにプルリクエストがマージされます。
  3. 1つのリリースpull request。マージされると、そのコミットが配信されます。

リリースpull requestをマージコミットで統合し、プロバイダーがバンドルされた各pull requestのマージを認識できるようにします。

Coroidが内容と順序を提案します。ユーザーがそれを調整し、Coroidがプルリクエストを1つのリリースブランチにマージして、1つのリリースpull requestを作成します。そのマージコミットがリリースとなります。
  1. 選択してください新規リリース、プロジェクトを選択し、選択してください未解決のPull Request。このオプションを利用するにはGitHubまたはGitLabリポジトリが必要なため、Coroidがホストするプロジェクトでは代わりにコミットがリリースされます。
  2. Coroidは、最も安全な順でデプロイメントブランチに未解決のPull Requestを整理します。Coroidが作成したpull requestは、タスクまたは計画として表示されます。Coroidは、プロバイダーや自身のレビューで既に把握されているチェック項目、レビュー結果、サイズ、競合状況、複数のPull Requestが触れるファイル情報を考慮して判断します。下書き状態のもの、チェックに失敗したもの、変更要求があるもの、フォークからのPull Requestは除外され、その理由も明記されます。
  3. 保留にするもののチェックを外し、矢印を使って順序を変更します。別のPull Requestをベースにするもの（スタック型のpull requestや「#12に依存」と記載されたもの）は、常にそれより後ろに配置されます。
  4. 選択してくださいリリースを作成Coroidはrelease/<version>をデプロイメントブランチから作成し、Pull Requestを順番にマージした上で、各Pull Requestを一覧表示・リンク付きで記載したリリース pull requestを開きます。
  5. もし pull request がリリースブランチと競合する場合、バンドル手順 で処理が停止し、該当ファイルが表示されます。以下を選択してください：Coroid で解決するこれにより開発者エージェントがマージし、タスク内で競合を解決します。またはそれを除外するこれにより、そのまま続行できます。
  6. リリース pull requestをレビューし、 merge commitでマージします。merge commit。そうするとプロバイダーがバンドルされた pull request をすべてマージ済みと判定します。Coroid は merge commitをリリースコミットとして固定し、バンドルされたプルリクエストを実際にデプロイされる内容として記録し、リリース pull requestへのリンクと共に未クローズのものを閉じます。
  7. 各環境に対して、通常通り4つの手順を実施してください。

スクワッシュやリベースによるマージも可能ですが、プロバイダー側では元のプルリクエストがマージ済みとは判定されません。その代わりに Coroid がコメントを付けてそれらを閉じます。

mainブランチの内容をリリースする

マージされた内容をそのままリリースする継続的デリバリーの場合に使用する。

  1. 「新規リリース」を選び、通常はデプロイブランチの最新コミットを指定する。
  2. 「比較対象」では、置き換える環境を選択する。Coroidが現在の環境で実行中の内容と指定したコミットの間のプルリクエストやコミットを一覧表示し、検証可能なものを選び出す。
  3. 名前やバージョンを空欄のままにしても構わない。Coroidが日付と短縮コミット名からリリース名を生成し、プロジェクトのバージョン情報源がバージョンを補完する。各リリースには次のビルド番号も割り当てられる。
  4. リリースを作成し、4つの手順に従う。

Coroidに問い合わせることなくマージのたびにパイプラインがデプロイする場合でも、各デプロイメントを報告することは可能だ。報告されたコミットに対応するリリースが存在しない場合、Coroidが観測されたリリースを作成し、Coroidのチェックを通過していないことを明確に标记する。

緊急修正をリリースする

オーナーまたは管理者が「これはホットフィックス」を有効にしてリリースを作成し、修正内容の完全なコミットを指定し、通常のタイミングでは対応できない理由を記載する。ホットフィックスは各環境のホットフィックスルールに従い、承認数を減らすことができる。ただし品質チェックや必須のチェック項目は引き続き適用され、ホットフィックスの承認はオーナーと管理者のみが行える。

障害発生時の復旧方法

ヘルスチェックで「対応が必要」と表示された場合は、「ヘルス影響を受けた環境で以前の正常なコミットを選び、再デプロイします。復旧とリリーストレインレポートできないパイプラインを含む各種オプションについて説明します。

チャットまたはエディターから操作可能

チャットアシスタントと Coroid のMCPサーバーには同じリリースツールが備わっており、リリースの一覧表示・詳細確認、コミットの選択、出荷予定内容のプレビュー、リリース準備、未マージプルリクエストのバンドル、チェック実行、承認、デプロイメント依頼、ノートの下書きが可能です。バンドル、承認、デプロイメントには常に人の確認が必要です。詳細はチャットアシスタントおよびCoroid のMCPサーバー。

複数のプロジェクトを同時にリリース

リリーストレインとは、同時にかつ順番にリリースする必要がある複数のプロジェクトのリリースをまとめたもので、例えばAPIとそれに依存するアプリケーションが該当します。詳細はこちら：復旧とリリーストレイン。

Coroidの機能と非機能

  • Coroid は固定、チェック、記録を行います。リポジトリと CI/CD がビルドおよびデプロイを担当します。
  • プルリクエストをバンドルする際、Coroid がリリースブランチとリリース pull requestを作成します。ただし、リリース pull requestを自動でマージすることはありません。
  • Coroid がパイプラインを開始するのは、接続されており、オーナーまたは管理者がデプロイを指示した場合のみです。
  • デプロイ要求自体は証拠にはなりません。ロールアウトトラックが進行するのは、パイプラインが成功を確認するか、誰かが検証済みの外部デプロイメントを記録した場合のみです。
  • リリースノートは編集・承認する下書き文書です。Coroid がそれらを外部に公開することはありません。
  • スプリントは計画期間であり、デプロイ境界ではありません。1つのスプリントで複数のリリースが生まれ、1つのリリースに複数のスプリントの作業が含まれることもあります。