デプロイ

コードのバージョンを環境にデプロイすると、デプロイが作成されます。通常、環境ごとにアクティブなデプロイは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で、そのジョブの実行（ ）ボタンと、**Can be manually deployed to **というテキストが表示されます。
• deploy_prodジョブは手動でトリガーする必要があります。

パイプライン、環境、デプロイ、およびジョブビューで実行（ ）を見つけることができます。

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

GitLabは、デプロイごとに新しく含まれるマージリクエストを追跡できます。デプロイが成功すると、システムは最新のデプロイと以前のデプロイ間のコミット差分を計算します。Deployment 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-refはリモートの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. デプロイ名の右側:
   • デプロイを再試行するには、環境に再デプロイを選択します。
   • デプロイにロールバックするには、以前に成功したデプロイの横にある環境のロールバックを選択します。

関連トピック

• 環境
• デプロイメントのダウンストリームパイプライン
• GitLab CI/CDを使用して複数の環境にデプロイする（ブログ投稿）
• レビューアプリ
• 外部デプロイツールのデプロイを追跡する

トラブルシューティング

デプロイを使用すると、次の問題が発生する可能性があります。

デプロイrefsが見つかりません

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

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

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

GitLabは、パフォーマンス上の懸念から、将来このサポートを削除する可能性があります。GitLabイシュートラッカーでイシューを開いて、この機能の動作について話し合うことができます。