Omnibus GitLab リリースプロセス

私たちの主な目標は、オムニバスパッケージに含まれるGitLabのバージョンを明確にすることです。

公式Omnibus GitLabパッケージの構築方法

公式パッケージのビルドはGitLab Inc.によって完全に自動化されています。

ビルドには2つのタイプがあります：

  • https://packages.gitlab.com へのリリース用パッケージ。
  • S3バケットで利用可能なブランチからビルドされたテストパッケージ。

どちらのタイプも同じインフラストラクチャ上に構築されます。

インフラストラクチャー

各パッケージは、対象となるプラットフォーム上でビルドされます (CentOS 6 パッケージは CentOS6 サーバ上でビルドされ、Debian 8 パッケージは Debian 8 サーバ上でビルドされます)。ビルドサーバの数は様々ですが、プラットフォームごとに少なくとも1つのビルドサーバがあります。

Omnibus GitLab プロジェクトは GitLab CI を完全に利用しています。つまり、Omnibus GitLabリポジトリにプッシュするたびにGitLab CIでビルドが開始され、パッケージが作成されます。

OmnibusのGitLabパッケージを使ってGitLab.comをデプロイしているため、GitLab.comに問題が発生した場合やパッケージのセキュリティリリースに備えて、パッケージをビルドするための別のリモートが必要です。

このリモートはhttps://dev.gitlab.org/ にあります。https://dev.gitlab.org/ 上の Omnibus GitLab プロジェクトと他の公開リモートの唯一の違いは、プロジェクトがアクティブな GitLab CI を持っていて、ビルドサーバ上で実行されるプロジェクトに割り当てられた特定の Runner を持っていることです。これは全てのGitLabコンポーネントについても同様です。例えば、GitLab Shellはhttps://dev.gitlab.org/ 、GitLab.comと全く同じです。

全てのビルドサーバーはGitLab Runnerを実行し、全てのランナーはhttps://dev.gitlab.org/ 上のプロジェクトに接続するためにデプロイキーを使用します。ビルドサーバはhttps://packages.gitlab.com にある公式パッケージリポジトリと、テストパッケージを保存する特別な Amazon S3 バケットにもアクセスできます。

ビルドプロセス

GitLab Incはrelease-toolsプロジェクトを使ってリリースごとのリリース作業を自動化しています。リリースマネージャがリリースプロセスを開始すると、Omnibus GitLabにとって重要なことがいくつか行われます：

  1. プロジェクトのすべてのリモートが同期されます。
  2. コンポーネントのバージョンはGitLab CE/EE リポジトリ（例：VERSION,GITLAB_SHELL_VERSION ）から読み込まれ、Omnibus GitLab リポジトリに書き込まれます。
  3. 特定のGitタグが作成され、Omnibus GitLabリポジトリに同期されます。

https://dev.gitlab.org/ 上の Omnibus GitLab リポジトリが更新されると、GitLab CI ビルドがトリガーされます。

具体的な手順は、Omnibus GitLabリポジトリの.gitlab-ci.yml 。ビルドはすべてのプラットフォームで同時に実行されます。

ビルド中、Omnibus GitLabは外部のライブラリをソースからプルし、GitLab、GitLab Shell、GitLab WorkhorseなどのGitLabコンポーネントはhttps://dev.gitlab.org/ 。

ビルドが完了し、.debまたは.rpmパッケージがビルドされると、ビルドの種類に応じてパッケージはhttps://packages.gitlab.com 、または一時的な（30日以上前のファイルはパージされる）S3バケットにプッシュされます。

コンポーネントのバージョンを手動で指定する場合

開発者マシンで

  1. パッケージ化するGitLabのタグを選んでください（例：v6.6.0 ）。
  2. Omnibus GitLab リポジトリにリリースブランチを作成します (例:6-6-stable)。

  3. パッチリリースなどですでにリリースブランチが存在する場合は、最新の変更をローカルマシンにプルしてください：

    git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # existing release branch

  4. ファイルのリビジョンをconfig/software/ に設定するには、support/set-revisions を使用します。タグ名を受け取り、Git SHA1 を検索して、ダウンロード・ソースをhttps://dev.gitlab.org/ に設定します。EE リリースにはset-revisions --ee を使用します：

    # usage: set-revisions [--ee] GITLAB_RAILS_REF GITLAB_SHELL_REF GITALY_REF GITLAB_ELASTICSEARCH_INDEXER_REF
   
# For GitLab CE:
support/set-revisions v1.2.3 v1.2.3 1.2.3 1.2.3 1.2.3
   
# For GitLab EE:
support/set-revisions --ee v1.2.3-ee v1.2.3 1.2.3 1.2.3 1.2.3

  5. 新しいバージョンをリリース・ブランチにコミットします：

    git add VERSION GITLAB_SHELL_VERSION GITALY_SERVER_VERSION
git commit

  6. GitLab タグに対応する注釈付きタグを Omnibus GitLab に作成します。オムニバスのタグは以下のようになります：MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASE MAJOR.MINOR.PATCH は GitLab のバージョン、OTHER はce 、ee 、rc1 （またはrc1.ee）のようなもの、OMNIBUS_RELEASE は（0 から始まる）数字です：

    git tag -a 6.6.0+ce.0 -m 'Pin GitLab to v6.6.0'
    caution
    ハイフン- は、Omnibus GitLabタグのどこにも使わないでください。

    アップストリームタグをオムニバスタグに変換する例：

    アップストリームタグオムニバスタグ配列
    v7.10.4 7.10.4+ce.0,7.10.4+ce.1 、...
    v7.10.4-ee 7.10.4+ee.0,7.10.4+ee.1 、...
    v7.11.0.rc1-ee 7.11.0+rc1.ee.0,7.11.0+rc1.ee.1 、...

  7. ブランチとタグをhttps://gitlab.com とhttps://dev.gitlab.org/ の両方にプッシュします：

    git push git@gitlab.com:gitlab-org/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0
git push git@dev.gitlab.org:gitlab/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0

    注釈付きタグをhttps://dev.gitlab.org/ にプッシュすると、パッケージがリリースされます。

パッケージの公開

https://dev.gitlab.org/gitlab/omnibus-gitlab/buildsでパッケージビルドの進捗を追跡できます。パッケージはビルドに成功すると自動的にpackagecloudリポジトリにプッシュされます。

クラウドイメージの更新

クラウドイメージのリリースプロセスはhttps://about.gitlab.com/handbook/alliances/cloud-images/に記載されています。

新しいイメージは以下のタイミングでリリースされます：

  1. GitLabの新しい月次リリースがあるとき。
  2. パッチリリースでセキュリティ脆弱性が修正されました。
  3. 画像に影響する重大なイシューを修正するパッチがあります。

新しいイメージは、パッケージリリースから3営業日以内にリリースされるべきです。

イメージ固有のリリース文書：