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

リリース

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

このシステムはタスクや計画をレビュー済みの pull request に変換します。それらがマージされると、リリース次の疑問に答えます：その作業のうちどれがどこで実行されており、そこへの配置が安全だったか？

リリースとは、特定の Git コミットを固定し、ステージング環境から本番環境へと順次追跡する仕組みです。そのコミットはすでにデプロイブランチ上にある場合もあれば、Coroid が複数の未マージの pull request をまとめて単一のリリース pull request とし、そのマージコミットをリリースとして利用することもあります。各段階で Coroid はコミットを検証し、指定された承認を収集し、CI/CD が報告するデプロイ情報を記録します。Coroid は独自の判断でリリースがデプロイされたと判定することはありません。パイプラインまたは外部デプロイを記録する担当者が確認する必要があります。

Coroidファクトリー

  1. タスクまたは計画

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

  2. プルリクエスト

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

  3. マージ済み

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

リリース

  1. リリース

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

  2. ステージング

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

  3. 本番環境

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

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

1分で理解する概要

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

  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. 「新規リリース」を選択してください。新規リリース、プロジェクトを選択し、「オープンなプルリクエスト」を選択します。オープンなプルリクエストこのオプションを利用するにはGitHubまたはGitLabリポジトリが必要です。Coroidホスト型プロジェクトの場合はコミットがリリースされます。
  2. Coroidは、デプロイブランチへのオープンなプルリクエスト（pull request）を安全性の高い順に一覧表示します。Coroidが作成したpull requestは、そのタスクまたはプランとして表示されます。Coroidは、プロバイダーと自身のレビューですでに把握しているチェック状況、レビュー結果、サイズ、競合、複数のプルリクエストが変更するファイルを考慮します。下書き、チェック失敗、変更要求、フォークからのプルリクエストは除外し、その理由を示します。
  3. 保留するもののチェックを外し、矢印を使って順序を変更します。別のプルリクエストに基づくプルリクエスト（スタック型pull request、または「#12に依存」と記載されたもの）は常にその前のものの後に来ます。
  4. 「リリースを作成」を選択してください。リリースを作成Coroidはデプロイブランチからrelease/<version>を作成し、プルリクエストを順序通りにマージして、各プルリクエストを一覧表示・リンク付きのリリース pull requestを開きます。
  5. pull requestがリリースブランチと競合する場合、バンドル手順で処理が停止し、該当ファイルが表示されます。「編集詳細」を選択してください。Coroidで解決、開発者エージェントがマージしてタスク内で競合を解決します。または除外する、それを含めずに続行します。
  6. リリース pull requestをレビューし、「マージコミット」でマージします。マージコミット。そうするとプロバイダーがまとめられたpull requestをすべてマージ済みとマークします。Coroidはマージコミットをリリースコミットとして固定し、まとめられたプルリクエストをリリース内容として記録し、まだオープンのままのプルリクエストはリリース pull requestへのリンクと共に閉じます。
  7. 各環境で通常通り4つの手順を実行します。

スクワッシュまたはリベースマージも利用可能ですが、プロバイダーは元のプルリクエストをマージ済みとは認識しません。Coroidは代わりにコメントでそれらを閉じます。

メインブランチ上の内容をリリースする

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

  1. 「新規リリース」を選択してください。新規リリース、通常はデプロイブランチ上の最新コミットを選択します。
  2. 「比較対象」の下で比較対象、置き換える環境を選択します。Coroidはそこで実行されている内容とご自身のコミットとの間のプルリクエストおよびコミットを一覧表示し、検証可能なものを選び出します。
  3. 名前とバージョンは空のままでも構いません。Coroidは日付と短いコミット名からリリース名を付け、プロジェクトのバージョンソースがバージョンを入力します。各リリースには次のビルド番号も割り当てられます。
  4. リリースを作成し、4つの手順に従ってください。

パイプラインがマージのたびにデプロイする場合や、誰かが手動でデプロイする場合でも、Coroidに問い合わせずに行っても、各デプロイの情報を報告できます。報告されたコミットに対応するリリースが存在しない場合、Coroidはそのコミット用の観測済みリリースを作成し、Coroidのチェックに合格していないことを明確にマークします。バージョンはパイプラインが報告したもの、またはCoroidがプロジェクトのバージョンを割り当てる場合は次のバージョンになります（1.4.1の後で1.4.0)、そして次のビルド番号です。

緊急修正をデプロイする

オーナーまたは管理者は、以下を有効にできます：これはホットフィックスですリリース作成時に、修正内容の完全なコミットを指定し、通常のタイミングでは対応できない理由を記載します。ホットフィックスは各環境のホットフィックス規則に従い、承認が少なくて済む場合があります。品質チェックや必須のチェックリスト項目は引き続き適用され、ホットフィックスを承認できるのはオーナーと管理者のみです。

障害発生時の復旧処理

ヘルスステップで以下が表示される場合：対応が必要、 を開いてくださいヘルス影響を受けた環境で該当項目を選択し、以前に正常だったコミットを再デプロイします。復旧処理とリリーストレインでは、報告ができないパイプラインを含む各種オプションについて説明します。

チャットやエディターから操作

チャットアシスタントとCoroidのMCPサーバーには同じリリースツールが備わっており、リリースの一覧表示・確認、コミットの選択、デプロイ予定内容のプレビュー、リリース準備、オープンなリリース pull requestのまとめ、チェックの実行、承認、デプロイ依頼、ノートの下書き作成が可能です。まとめ、承認、デプロイには常に人の確認が必要です。詳細はチャットアシスタントとCoroidをMCPサーバーとして利用。

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

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

Coroidの機能と非機能

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