Orbitリリース

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

Releases タブは git タグをバージョン履歴に変え、読みやすくします。タグ付きのデプロイメント全てが順番に表示され、コミット、作成者、ステータス、リポジトリ内のタグへの直接リンクが含まれます。

Releases の場所

Orbit を開き、プロジェクトをクリックして、プロジェクトタブストリップの Deployments グループから Releases を選びます。ページは Releases という題で、タグベースのデプロイメントとして説明されます。git タグがタグパターンに一致するとリリースが作成されます。

隣の Deployments タブはタグの有無を問わず全てのビルドを一覧表示します。Releases はフィルター済みの表示です。バージョンとしてマークした物だけです。

タグパターンの設定

Releases はパターンから始まります。Settings を開き、Git tag deploys カードを探して、v* や release-* のようなグロブを入力します。空のままにするとタグデプロイが完全に無効になります。そのため、そのフィールドのプレースホルダーは v* (disabled) と書いてあります。

パターンを設定すると、一致するタグをプッシュすると本番環境にデプロイされ、その結果がリリースとして記録されます。パターンがないと、Releases タブは空の状態を表示し、タグをプッシュして Settings でパターンを設定するよう促します。

タグパターンは、本番ブランチへのプッシュと並行して、本番環境への第二の明確なパスを提供します。デプロイをマージの副作用ではなく意図的な行為にしたいチームは、しばしばブランチの自動デプロイをオフにして、タグだけから本番環境を駆動します。

リリースをカットする

あなた側の全フローは 2 つの git コマンドです:

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit はタグを受け取り、パターンと照合し、タグ付きコミットを本番環境にデプロイし、リリースとして記録します。このタブに Building バッジ付きで表示され、デプロイされると Deployed に移動するか、ビルドがエラーになると Failed に移動します。

軽量タグではなく、注釈付きタグを使用してください。注釈付きタグはメッセージ、作成者、日付を含み、全てがリリースに反映されます。

既存のデプロイメントにタグを付ける

リリースを取得するために git タグをプッシュする必要はありません。任意のデプロイメントはその詳細ページからタグ付けでき、バージョン番号のような見た目のタグがここで検出されます。

バージョンのような見た目のタグは、1.4、1.4.0、v1.4.0、v2.0.0-rc1 のようなものです。その他は平まなデプロイメントタグのままで、リリースエントリを作成しません。

これは、パターンを設定する前にリリースが出ていた場合や、ホットフィックスが手動でデプロイされてバージョン履歴に入れたい場合の逃げ道です。

リリースを読む

各リリース行は以下を表示します:

タグはリリースのタイトルとして。
コミットとそのメッセージ。
作成者は、by 名前 として表示。
デプロイされた環境。タイプごとに色分け。
ステータスバッジ: Deployed、Building、Failed。
リポジトリ内のタグへの View on リンク。
下層デプロイメントへのリンク。

View on リンクはプロバイダーごとに正しい場所を指します。GitHub 上のリリースページ、GitLab のタグページ、または Bitbucket のそのタグでのソースです。

リリースノート

リポジトリ内のタグのリリースを公開すると、ノートが引き取られてデプロイメントに添付されるため、Releases タブはリポジトリで書いたのと同じテキストを表示し、2 つのコピーを保つ必要はありません。

これにより、リポジトリがリリースノートを書く単一の場所になります。コントリビューターが既にいる場所で一度書くと、ここに表示されます。

タグごとに 1 つのリリース

リストはタグで重複排除されます。タグが複数回デプロイされた場合、たとえば最初のビルドが失敗して再試行した場合、そのタグの最新のデプロイメントだけが表示されます。

上部のカウンターは合計を示し、リストはプロジェクト全体の履歴ではなく、最近のタグ付きデプロイメントの広いウィンドウをカバーします。

リリースを上手く使う

ブランチではなくマージ時にタグを付けてください。 実際に本番ブランチにあるコミットにタグを付けてください。マージされていない機能ブランチコミットにタグを付けると、このリストのリリースと main の何かが対応しないリリースが生成されます。

セマンティックバージョンを使用してください。 正しくソートでき、バージョンのような見た目として認識され、誰もが既に読み方を知っています。

タグを移動しないでください。 既存のタグを新しいコミットを指すように再ポイントすることは、このリストのリリースとリポジトリ内のタグが何がシップされたかについて同意しなくなることを意味します。代わりに新しいパッチバージョンをカットしてください。

タグプッシュがパターンに一致する場合、本番環境に直接デプロイされます。それ以外は何もバイパスしません。デプロイロック、承認要件、フリーズウィンドウは設定通り適用されます。しかし、それは誤ってプッシュされたタグが本番環境デプロイであり、ドラフトではないことを意味します。利用可能なゲートについては Deploying Your Project を参照してください。

リリースをロールバックする

リリースはデプロイメントなので、リリースをロールバックすることは通常のロールバックフロー、つまりデプロイメントを開いて前回成功したものを復元することです。Rolling Back a Deployment を参照してください。

その後、悪いものを削除するのではなく、修正用に新しいタグをカットしてください。失敗したリリースが履歴に表示されたままであることは、有用な情報であり、クラッターではありません。

トラブルシューティング

タグはプッシュされたがリリースが表示されない。 Settings でパターンをチェックしてから、タグが実際にリモートに到達したかどうかをチェックしてください。git push origin v1.4.0 は 1 つのタグをプッシュします。git push だけではなくプッシュしません。

リリースが Failed を表示している。 ビルドが失敗しました、ブランチプッシュの場合と同じです。デプロイメントを開いてログを読んでください。Reading Build Logs。

View on リンクが見当たらない。 プロジェクトに接続されたリポジトリがないため、リンク先がありません。1 つを接続してください。Connecting a GitHub Repository を参照してください。

手動でタグ付けされたデプロイメントが一覧表示されていない。 タグはバージョンのような見た目ではありません。v1.4.0 のような名前に変更してください。

リリースノートが空。 ノートはリポジトリ内の公開リリースから引き取られます。リリースオブジェクトのない裸のタグにはプルするノートはありません。

次のステップ

Deploying Your Project デプロイサイクル全体とそのゲート用。
Rolling Back a Deployment リリースが問題になった場合。
Orbit Timeline Annotations リリースが何を変更したかを記録する。