デプロイ

コードの特定のバージョンを環境にデプロイすると、デプロイが作成されます。通常、環境ごとにアクティブなデプロイは1つのみです。

GitLab:

• 各環境へのデプロイの完全な履歴を提供します。
• デプロイを追跡し、サーバーに何がデプロイされているかを常に把握できます。

Kubernetesのようなデプロイサービスがプロジェクトに関連付けられている場合、それを使用してデプロイを支援できます。

デプロイが作成されたら、ユーザーにロールアウトできます。

手動デプロイを設定する

手動でデプロイを開始する必要があるジョブを作成できます。例:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manualアクションの仕様は次のとおりです:

• GitLab UIで、このジョブに実行（ ）ボタンが表示され、<environment>に手動でデプロイ可能というテキストが表示されます。
• deploy_prodジョブを手動でトリガーする必要があります。

実行（ ）は、パイプライン、環境、デプロイ、ジョブの各ビューに表示されます。

デプロイごとに新たに含まれたマージリクエストを追跡する

GitLabは、デプロイごとに新たに含まれたマージリクエストを追跡できます。デプロイが成功すると、システムは最新のデプロイと前回のデプロイの間でコミットの差分を計算します。追跡情報は、デプロイAPIでフェッチするか、マージリクエストページのマージ後パイプラインで確認できます。

追跡を有効にするには、次のいずれかの条件を満たすように環境を設定します:

• 環境名で/を含むフォルダーを使用しない（長期またはトップレベルの環境）。

• 環境の階層がproductionまたはstagingのいずれかである。

  .gitlab-ci.ymlでenvironmentキーワードを使用する設定例を次に示します:

  # Trackable
  environment: production
  environment: production/aws
  environment: development
  
  # Non Trackable
  environment: review/$CI_COMMIT_REF_SLUG
  environment: testing/aws

設定変更は新しいデプロイにのみ適用されます。既存のデプロイレコードでは、マージリクエストのリンクまたはリンク解除は行われません。

ローカルでデプロイをチェックアウトする

Gitリポジトリには、デプロイごとに参照が保存されます。そのため、現在の環境の状態はgit fetchするだけで把握できます。

Gitの設定で、[remote "<your-remote>"]ブロックに次のフェッチ行を追加します:

fetch = +refs/environments/*:refs/remotes/origin/environments/*

古いデプロイをアーカイブする

プロジェクトで新しいデプロイが行われると、GitLabはそのデプロイ用の特別なGit refを作成します。これらのGit refsはリモートのGitLabリポジトリから取り込まれるため、プロジェクト内のデプロイ数が増えるにつれて、git-fetchやgit-pullなどのGit操作が遅くなることがあります。

Git操作の効率を維持するため、GitLabは最新のデプロイrefs（最大50,000）のみを保持し、それ以外の古いデプロイrefsは削除します。アーカイブされたデプロイは、監査目的でUIまたはAPIを使用して引き続き参照できます。またアーカイブ後でも、コミットSHAを指定することで、デプロイされたコミットをリポジトリから引き続きフェッチできます（例: git checkout <deployment-sha>）。

デプロイのロールバック

特定のコミットにデプロイをロールバックすると、新しいデプロイが作成されます。このデプロイには固有のジョブIDが割り当てられます。これは、ロールバック先のコミットを参照します。

ロールバックを成功させるには、デプロイプロセスがジョブのscriptに定義されている必要があります。

実行されるのはデプロイジョブのみです。以前のジョブが生成したアーティファクトを、デプロイ時に再生成する必要がある場合、パイプラインページから必要なジョブを手動で実行する必要があります。たとえば、Terraformを使用しており、planとapplyのコマンドが複数のジョブに分かれている場合、デプロイまたはロールバックのためにジョブを手動で実行する必要があります。

デプロイを再試行またはロールバックする

デプロイに問題がある場合は、再試行またはロールバックできます。

デプロイを再試行またはロールバックするには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 操作 > 環境を選択します。
3. 環境を選択します。
4. デプロイ名の右側で、次のいずれかを行います:
   • デプロイを再試行するには、環境に再デプロイを選択します。
   • デプロイをロールバックするには、以前に成功したデプロイの横にある環境のロールバックを選択します。

関連トピック

• 環境
• デプロイのダウンストリームパイプライン
• Deploy to multiple environments with GitLab CI/CD（ブログ投稿）
• レビューアプリ
• 外部デプロイツールのデプロイを追跡する

トラブルシューティング

デプロイを操作する際に、次の問題が発生する可能性があります。

デプロイrefsが見つからない

GitLabは、Gitリポジトリのパフォーマンスを維持するため、古いデプロイrefsを削除します。

GitLab Self-ManagedでアーカイブされたGit refsを復元する必要がある場合は、Railsコンソールで次のコマンドを実行するように管理者に依頼してください:

Project.find_by_full_path(<your-project-full-path>).deployments.where(archived: true).each(&:create_ref)

パフォーマンス上の懸念から、GitLabは将来このサポートを廃止する可能性があります。この機能の動作について議論したい場合は、GitLabイシュートラッカーでイシューをオープンしてください。