リリース設定はプロジェクトごとに管理されます。以下を開いてください：リリース、次にリリース設定、プロジェクトを選択します。合計4つの画面があり、それぞれが1つの質問に答えます。
- 環境
- リリースはどこへ進むのか？ 経由地点を追加し、順序を決定してください。
- 承認ルール
- 事前に満たす必要がある条件は何か？ 環境ごとに承認者、役割、チェックリスト、緊急修正のルールが設定されます。
- デプロイパイプライン
- 誰がデプロイし、Coroidはどのように結果を把握するのか？ 貴社のパイプラインまたはCoroidがデプロイを開始し、報告用のトークンによりCI/CDが結果を確認します。
- バージョン管理
- これはどのバージョンですか？ バージョンの出所、ビルドで受け取る内容、そしてCoroidが実際に動作する内容を確認する仕組みについて説明します。
リリース設定を変更できるのはオーナーと管理者のみで、他のユーザーは閲覧のみ可能です。まずはリポジトリを接続してください。すべてのリリースはそのリポジトリ内のコミットを参照します。
環境
リリースはどこへ、そしてどの順序でデプロイされるか？
各プロジェクトには最初から本番環境が含まれています。ステージングやQAなど、他のデプロイ先を追加するには環境を追加を使用します。各環境に名前を付けてください。Coroidは名前からキーを自動生成します。例えばstagingのようになります。パイプラインで利用されるようになったら、そのキーは安定して保持してください。CI/CDはデプロイを報告する際にこのキーを使用します。
順序は次に続く環境で設定します。何も指定しない場合の後に続くステージング、ステージングの後に続く本番環境という設定では、デプロイ経路は「ステージング → 本番」となります。リリースページにはこの順序でロールアウト経路が表示され、承認ルールでは前の環境でのデプロイが成功したことを条件に設定できます。
承認ルール
リリースがここにデプロイされる前に満たす必要がある条件とは？
上部で環境を選択します。ルールは環境ごとに設定されるため、ステージングは緩やかで本番環境は厳格に設定できます。
- 必要な承認数：承認が必要な人数。0に設定すると、チェックが完了次第すぐにリリースがデプロイされます。
- 承認可能なユーザー：承認を実行できる組織内の役割。
- 申請者と承認者を分ける：デプロイを開始した人が承認者になれず、リリースノートを編集した人も承認できません。
- 品質チェックが合格：常に有効です。プロジェクトの品質グラフに
release_validationトリガーが正確なコミットに対して実行されます。そのグラフはプロジェクトの品質設定から公開できます。 - 前の環境を先に通過：現在の環境にデプロイする前に、その前に続く環境へのデプロイが完了している必要があります。
- 承認済みリリースノート：現在のノートに承認が必要で、以降の編集には新たな承認が求められます。
- チェックリスト：リリースページ上で確認される手動の手順。例えば「データベースのマイグレーションを確認済み」などです。項目を必須または任意に設定でき、必須項目には一時的な例外を許可できます。オーナーまたは管理者が理由と最大24時間の有効期限を記録し、その例外は特定のコミットと環境にのみ適用されます。
- 緊急修正ルール：緊急修正用の緩やかなルール。承認数や前の環境・ノート承認の適用有無が調整されます。品質チェックと必須のチェックリスト項目は常に適用され、緊急修正の承認はオーナーと管理者のみが行えます。
以下を選択してください：ルールを公開をクリックして保存します。公開するとルールの新しいバージョンが作成されます。旧バージョンで得られた承認は無効になるため、進行中のリリースでは再度承認を求められます。公開されたルールが設定されていない環境ではチェックに合格できず、画面にその旨が表示されます。
デプロイパイプライン
誰がデプロイを開始し、Coroidがその結果をどのように把握するのか？
上部で環境を選択し、デプロイの開始方法を指定します：
- 自社のパイプラインが自動でデプロイ：現在のプロセスを維持します。CoroidはCI/CDからの報告や、オーナーまたは管理者がリリースページで外部デプロイを記録した際にデプロイ情報を記録します。
- CoroidがGitHub Actionsワークフローを開始またはCoroidがGitLab CI/CDパイプラインを開始：プロジェクトのリポジトリが該当プロバイダー上にある場合に表示されます。リリースコミットを指すブランチまたはタグ、GitHub用のワークフローファイル、デプロイを実行するジョブの正確な名前を入力します。Coroidは実行開始前に参照をチェックし、成功と判断する前に指定されたジョブを確認します。
以下の項目の下にデプロイメントレポート環境用のレポートトークンを作成し、それを CI/CD にシークレットとして保存します。Coroid はトークンを一度だけ表示し、そのハッシュ値のみを保持します。トークンを置き換えると直ちに古いトークンは無効になります。同じ画面には、パイプラインで必要なエンドポイント、プロジェクトID、環境キーが表示され、レポートが正常に届いているかどうかも確認できます。デプロイメントイベントとCIセットアップイベントのフォーマットとサンプルについてはこちらを参照してください。
バージョン管理
このリリースのバージョンは何か、そしてビルドでそれをどのように指定するか？
各リリースのバージョンの取得元を選択できます。Coroidが次のバージョンを提案したり、Coroidがリポジトリ内のファイルからバージョン情報を読み取ったり、パイプラインが直接バージョンを報告したりします。すべてのリリースには順番に増加するビルド番号も付与されます。画面にはCoroidがパイプラインに渡す値が一覧表示され、これらをビルドに追加するよう依頼するための「新規作業」を開くことも可能です。また、各環境ごとのバージョンURLも登録できるため、Coroidが各環境で実行される内容を確認できます。ビルドにバージョンを組み込むDockerにはWeb、サーバー、iOS、Androidビルドに関する詳細と手順が記載されています。
組織間での設定の移行
設定のエクスポートおよびインポートでは、環境やその順序、パイプライン構成、バージョン管理、バージョンURL、公開済みのルール（ホットフィックスルールを含む）が対象となります。ただし、レポートトークンやビルド番号はエクスポートされません。インポート後は新しいトークンを作成し、各プロジェクトごとに独自のビルド番号を使用します。