- 自動ビルド
- 自動テスト (非推奨)
- 自動コード品質
- 自動 SAST
- 自動シークレット検出
- 自動依存関係スキャン
- 自動ライセンスコンプライアンス（非推奨）
- コンテナの自動スキャン
- 自動レビューアプリ
- 自動DAST
- 自動ブラウザのパフォーマンステスト
- 自動負荷パフォーマンステスト
- 自動デプロイ
- 自動コードインテリジェンス
自動DevOpsのステージ
以下のセクションでは、AutoDevOpsのステージについて説明します。それぞれがどのように機能するかを理解するために、注意深く読んでください。
自動ビルド
Auto Buildは、既存のDockerfile または Heroku buildpacksを使用してアプリケーションのビルドを作成します。出来上がったDockerイメージはコンテナレジストリにプッシュされ、コミットSHAまたはタグでタグ付けされます。
Dockerfileを使った自動ビルド
プロジェクトのリポジトリにDockerfile がルートに含まれている場合、Auto Build はdocker build を使って Docker イメージを作成します。
Auto Review AppsとAuto Deployも使用していて、独自のDockerfile を提供する場合は、以下のいずれかを行う必要があります：
-
デフォルトの Helm Chartはこのポートが利用可能であると想定しているため、アプリケーションを
5000ポートに公開します。 - Auto Deploy Helm チャートをカスタマイズすることで、デフォルト値をオーバーライドできます。
クラウドネイティブビルドパックを使用した自動ビルド
Auto Buildはプロジェクトが存在するDockerfile 場合、 Dockerfileそのプロジェクトを使ってアプリケーションをビルドします。存在Dockerfile しない場合 Dockerfile、Auto BuildはCloudNative Buildpacksを使ってアプリケーションを検出し、Dockerイメージにビルドします。この機能はpack コマンドを使用します。デフォルトのビルダーは heroku/buildpacks:18 ですが、CI/CD 変数AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDERを使用して別のビルダーを選択できます。
各ビルドパックでは、Auto Buildがアプリケーションを正常にビルドするために、プロジェクトのリポジトリに特定のファイルが含まれている必要があります。その構造は、選択したビルダーとビルドパックに固有です。例えば、Herokuビルダー（デフォルト）を使用する場合、アプリケーションのルートディレクトリには、アプリケーションの言語に適したファイルが含まれている必要があります：
- Python プロジェクトの場合は、
Pipfileまたはrequirements.txtファイルです。 - Rubyプロジェクトの場合は、
GemfileまたはGemfile.lockファイル。
その他の言語やフレームワークの要件については、Heroku buildpacks documentationを参照してください。
ビルドコンテナへのボリュームのマウント
変数BUILDPACK_VOLUMES を使って、ボリュームマウント定義をpack コマンドに渡すことができます。マウントは--volume 引数を使ってpack build に渡されます。各ボリューム定義には、ホストパス、ターゲットパス、書き込み可能かどうか、1つ以上のボリュームオプションなど、build pack が提供する機能を含めることができます。
複数のボリュームを渡すには、パイプ（| ）を使用します。リストの各項目は、個別の--volume 引数を使用してbuild back に渡されます。
この例では、3 つのボリュームが/etc/foo 、/opt/foo 、/var/opt/foo としてコンテナにマウントされています：
buildjob:
variables:
BUILDPACK_VOLUMES: /mnt/1:/etc/foo:ro|/mnt/2:/opt/foo:ro|/mnt/3:/var/opt/foo:rw
ボリュームの定義の詳細については、pack build ドキュメントを参照してください。
Herokuishを使った自動ビルド（非推奨）
GitLab 14.0のCloud Native Buildpacksに置き換えられました。
GitLab 14.0以前では、Herokuishは Dockerfile がないプロジェクトのデフォルトのビルド方法でした。 Herokuishは、CI/CD変数AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED をfalse に設定することで、まだ使うことができます。
TRACE=true を設定して、冗長ロギングを有効にしてください。Heroku から Cloud Native ビルドパックへの移行
Cloud Native Buildpacksを使ったビルドは、以下の注意点を除き、Herokuishを使ったビルドと同じオプションをサポートしています：
- ビルドパックはCloud Native Buildpackでなければなりません。Herokuのビルドパックは、Herokuの
cnb-shimを使用してCloud Native Buildpackに変換できます。 -
BUILDPACK_URLはpack](https://buildpacks.io/docs/app-developer-guide/specify-buildpacks/) でサポートされているフォーマット[でなければなりません。 - ビルドされたイメージには
/bin/herokuishコマンドが存在せず、コマンドの前に/bin/herokuish procfile execを付ける必要がなくなりました（不可能でもありません）。その代わりに、カスタムコマンドは正しい実行環境を得るために、/cnb/lifecycle/launcherを先頭に付ける必要があります。
自動テスト (非推奨)
Auto TestはHerokuishと Heroku buildpacksを使用して、プロジェクトを分析して言語とフレームワークを検出することで、アプリケーションに適切なテストを実行します。いくつかの言語とフレームワークは自動的に検出されますが、言語が検出されない場合は、カスタムビルドパックを作成することができます。現在サポートされている言語を確認してください。
Auto Test は、アプリケーションにすでにあるテストを使用します。テストがない場合、追加するかどうかはあなた次第です。
現在サポートされている言語
Auto Testは比較的新しい機能拡張なので、まだすべてのビルドパックが対応しているわけではありません。Herokuが公式にサポートしている言語はすべてAuto Testをサポートしています。HerokuのHerokuishビルドパックでサポートされている言語はすべてAuto Testをサポートしていますが、特にマルチビルドパックはサポートしていません。
サポートされているビルドパックは以下のとおりです：
- heroku-buildpack-multi
- heroku-buildpack-ruby
- heroku-buildpack-nodejs
- heroku-buildpack-clojure
- heroku-buildpack-python
- heroku-buildpack-java
- heroku-buildpack-gradle
- heroku-buildpack-scala
- heroku-buildpack-play
- heroku-buildpack-php
- heroku-buildpack-go
- buildpack-nginx
上記のリストにないビルドパックが必要な場合は、カスタムビルドパックを使用するとよいでしょう。
自動コード品質
13.2でGitLab StarterからGitLab Freeに移行しました。
Auto Code QualityはCode Qualityイメージを使って、現在のコードに対して静的解析やその他のコードチェックを実行します。レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトできます。マージリクエストウィジェットは、ソースブランチとターゲットブランチ間の差分も表示します。
自動 SAST
- GitLab Ultimate10.3から導入されました。
- 13.1から全階層で利用可能になった機能。
Static Application Security Testing(SAST) 現在のコードの静的解析を実行し、潜在的なセキュリティのイシューをチェックします。Auto SASTステージには、GitLab Runner11.5以上が必要です。
レポートを作成した後、後でダウンロードしてチェックアウトできるアーティファクトとしてアップロードされます。マージリクエストウィジェットは、Ultimateライセンスのセキュリティ警告も表示します。
詳細については、静的アプリケーションセキュリティテスト(SAST) を参照してください。
自動シークレット検出
- GitLab 13.1 で導入されました。
- GitLab 13.3で全階層で利用可能になった選択機能。
Secret DetectionはSecret Detection Dockerイメージを使って現在のコードに対してSecret Detectionを実行し、漏れたシークレットをチェックします。Auto Secret DetectionにはGitLab Runner11.5以上が必要です。
レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードして評価することができます。マージリクエストウィジェットは、Ultimateライセンスのセキュリティ警告も表示します。
詳細については、シークレット検出を参照してください。
自動依存関係スキャン
Dependency Scanningはプロジェクトの依存関係を分析し、潜在的なセキュリティ問題をチェックします。Ultimate以外のライセンスでは自動依存関係スキャンのステージはスキップされ、GitLab Runner11.5以上が必要です。
レポートの作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトすることができます。マージリクエストウィジェットには、検出されたセキュリティ警告が表示されます、
詳細については、「依存関係のスキャン」を参照してください。
自動ライセンスコンプライアンス（非推奨）
この機能はGitLab 15.9で非推奨となり、GitLab 16.3ではライセンスコンプライアンスレポートのサポートを削除しました。自動ライセンスコンプライアンスはまだパイプラインに存在しますが、結果は出力されません。
代わりにAuto Dependency Scanningを使ってください。
コンテナの自動スキャン
コンテナ用の脆弱性静的解析は、Dockerイメージの潜在的なセキュリティ問題をチェックするためにTrivyを使用します。Ultimate以外のライセンスでは、Auto Container Scanningステージはスキップされます。
レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトできます。マージリクエストは検出されたセキュリティ問題を表示します。
詳細については、コンテナスキャンを参照してください。
自動レビューアプリ
多くのプロジェクトではKubernetesクラスターが利用できないため、これはオプションのステップです。要件が満たされない場合、ジョブは静かにスキップされます。
レビューアプリはブランチのコードに基づいた一時的なアプリケーション環境であり、開発者、デザイナー、QA、プロダクトマネージャー、その他のレビュアーがレビュープロセスの一環としてコードの変更を実際に見て操作できるようにします。自動レビューアプリはブランチごとにレビューアプリを作成します。
Auto Review AppsはアプリケーションをKubernetesクラスターにのみデプロイします。クラスターがない場合はデプロイは行われません。
レビューアプリには、プロジェクトID、ブランチまたはタグ名、一意の番号、およびAuto DevOpsのベースドメイン（13083-review-project-branch-123456.example.com など）の組み合わせに基づく一意のURLがあります。マージリクエストウィジェットには、レビューアプリへのリンクが表示され、簡単に発見できます。マージリクエストをマージした後など、ブランチやタグが削除されると、レビューアプリも削除されます。
レビューアプリは、カスタマイズできる Helm のauto-deploy-appチャートを使ってデプロイされます。アプリケーションは環境のKubernetes名前空間にデプロイされます。
GitLab 11.4以降では、ローカルのTillerが使用されます。以前のバージョンのGitLabでは、プロジェクトのネームスペースにTillerがインストールされていました。
自動DAST
Dynamic Application Security Testing(DAST) は、人気の高いオープンソースツールOWASP ZAProxyを使用して、現在のコードを分析し、潜在的なセキュリティ問題をチェックします。Ultimate以外のライセンスでは、Auto DASTステージはスキップされます。
- デフォルトのブランチでは、ターゲットブランチを上書きしない限り、DAST はその目的専用にデプロイされたアプリケーションをスキャンします。アプリは、DAST の実行後に削除されます。
- 機能ブランチでは、DAST はレビューアプリをスキャンします。
DAST スキャンが完了すると、セキュリティ警告がセキュリティダッシュボードとマージリクエストウィジェットに表示されます。
詳細については、動的アプリケーションセキュリティテスト(DAST) を参照してください。
DAST ターゲットのオーバーライド
自動デプロイされたレビューアプリの代わりにカスタムターゲットを使用するには、DAST_WEBSITE CI/CD変数をDASTがスキャンするURLに設定します。
自動DASTの無効化
DASTを無効にすることができます：
-
DAST_DISABLEDCI/CD 変数を"true"に設定することで、すべてのブランチで DAST: を無効にできます。 -
DAST_DISABLED_FOR_DEFAULT_BRANCH変数を"true"に設定することで、デフォルトブランチでのみ使用できます。 -
REVIEW_DISABLED変数を"true"に設定することで、フィーチャーブランチでのみ使用できます。 これはレビューアプリも無効にします。
自動ブラウザのパフォーマンステスト
GitLab 10.4から導入されました。
AutoBrowser Performance Testingは、Sitespeed.ioコンテナでウェブページのブラウザパフォーマンスを測定し、各ページの総合パフォーマンススコアを含むJSONレポートを作成し、レポートをアーティファクトとしてアップロードします。デフォルトでは、レビュー環境と本番環境のルートページをテストします。追加のURLをテストしたい場合は、ルートディレクトリの.gitlab-urls.txt という名前のファイルに、1行に1ファイルずつパスを追加します。たとえば
/
/features
/direction
ソースブランチとターゲットブランチ間のブラウザーパフォーマンスの違いは、マージリクエストウィジェットにも表示されます。
自動負荷パフォーマンステスト
GitLab 13.2で導入されました。
AutoLoad Performance Testingは、k6 コンテナでアプリケーションのサーバーパフォーマンスを測定し、いくつかの主要な結果メトリクスを含む JSON レポートを作成し、レポートをアーティファクトとしてアップロードします。
初期設定が必要です。特定のアプリケーションに合わせたk6テストを書く必要があります。テストはまた、CI/CD変数経由で環境の動的URLをピックアップできるように設定する必要があります。
ソースブランチとターゲットブランチ間の負荷性能テスト結果の違いは、マージリクエストウィジェットにも表示されます。
自動デプロイ
GitLab 13.6から導入された、Kubernetesクラスターに加えてAmazon Elastic Compute Cloud (Amazon EC2)へのデプロイも選択できるようになりました。
Auto DeployはAuto DevOpsのオプションステップです。要件を満たしていない場合、ジョブはスキップされます。
ブランチまたはマージリクエストがプロジェクトのデフォルトブランチにマージされた後、Auto DeployはKubernetesクラスタ内のproduction 環境にアプリケーションをデプロイします。名前空間はプロジェクト名と一意のプロジェクトIDに基づき、project-4321.
Auto Deployはデフォルトではステージング環境やカナリア環境へのデプロイを含みませんが、Auto DevOpsテンプレートにはこれらのタスクを有効にしたい場合のジョブ定義が含まれています。
CI/CD変数を使用して、ポッドレプリカを自動的にスケールしたり、Auto DevOpshelm upgrade コマンドにカスタム引数を適用したりすることができます。これはAuto Deploy Helmチャートをカスタマイズする簡単な方法です。
Helmはauto-deploy-appチャートを使用して、環境用のKubernetesネームスペースにアプリケーションをデプロイします。
GitLab 11.4以降では、ローカルのTillerが使用されます。GitLabの以前のバージョンでは、プロジェクトのネームスペースにTillerがインストールされていました。
auto-deploy-image の変更を壊すため、Auto DevOps プロジェクトで予期せぬ失敗を引き起こすかもしれません。GitLab 14.0にアップグレードする前に、アップグレードガイドに従って環境をアップグレードしてください。GitLab デプロイトークン
GitLab 11.0で導入されました。
GitLabデプロイトークンは、Auto DevOpsが有効化され、Auto DevOps設定が保存されると、内部および非公開プロジェクト用に作成されます。デプロイトークンはレジストリへの永続的なアクセスに使用できます。GitLab デプロイトークンを手動で取り消した後は、自動的に作成されません。
GitLab デプロイトークンが見つからない場合は、CI_REGISTRY_PASSWORD 。
CI_REGISTRY_PASSWORD はデプロイ中にのみ有効です。Kubernetesはデプロイ中にコンテナイメージを正常にプルできますが、ポッドの立ち退き後など、イメージを再度プルする必要がある場合、KubernetesはCI_REGISTRY_PASSWORD を使用してイメージをフェッチしようとするため、プルできません。Kubernetes 1.16+の場合。
Kubernetes 1.16 以降では、extensions/v1beta1 バージョンのDeployment のサポートを含む多くのAPI が削除されました。
Kubernetes 1.16+クラスターでAuto Deployを使用するには：
-
GitLab 13.0以降で初めてアプリケーションをデプロイする場合は、設定は必要ありません。
-
GitLab 12.10以前では、
.gitlab/auto-deploy-values.yamlファイルで以下を設定してください：deploymentApiVersion: apps/v1 -
AUTO_DEVOPS_POSTGRES_CHANNELが1に設定された PostgreSQL データベースがクラスター内部にインストールされている場合、PostgreSQL をアップグレードするためのガイドに従ってください。 -
アプリケーションを初めてデプロイする場合で、GitLab 12.9 または 12.10 を使用している場合は、
AUTO_DEVOPS_POSTGRES_CHANNELを2に設定します。
AUTO_DEVOPS_POSTGRES_CHANNEL バージョン2 にオプトインすると、バージョン1 の PostgreSQL データベースが削除されます。バージョン2 にオプトインする前に、PostgreSQLのアップグレードガイドに従ってデータベースのバックアップと復元を行ってください（GitLab 13.0では、データベースの削除をトリガーするために追加のCI/CD変数が必要です）。マイグレーション
GitLab 11.4 で導入されました。
プロジェクトのCI/CD変数DB_INITIALIZE とDB_MIGRATE を設定することで、PostgreSQLのデータベース初期化とマイグレーションをアプリケーションポッド内部で実行するように設定できます。
存在する場合、DB_INITIALIZE はHelmのポストインストールフックとしてアプリケーションポッド内でshellコマンドとして実行されます。データベースの初期化ステップが成功しないと実行できないアプリケーションもあるので、GitLabは最初のリリースをアプリケーションのデプロイなしで、データベースの初期化ステップだけをデプロイします。データベースの初期化が完了した後、GitLabはアプリケーションデプロイを標準とした2つ目のリリースをデプロイします。
ポストインストールフックは、デプロイが成功した場合、DB_INITIALIZE 以降は処理されないことを意味します。
存在する場合、DB_MIGRATE は Helm pre-upgrade フックとしてアプリケーションポッド内で shell コマンドとして実行されます。
たとえば、Cloud Native BuildpacksでビルドされたイメージのRailsアプリケーションでは、次のようになります：
-
DB_INITIALIZEをRAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:setup -
DB_MIGRATEに設定できます。RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:migrate
リポジトリにDockerfile が含まれていない限り、イメージは Cloud Native Buildpacks でビルドされます。これらのイメージで実行するコマンドの前に/cnb/lifecycle/launcher を付けて（Herokuish を使用している場合は/bin/herokuish procfile exec を付けて）、アプリケーションの実行環境をレプリケートする必要があります。
auto-deploy-appチャートのアップグレード
アップグレードガイドに従って、auto-deploy-app Chart をアップグレードすることができます。
作業者
ウェブアプリケーションの中には、「ワーカープロセス」のために特別なデプロイを実行しなければならないものがあります。たとえば Rails アプリケーションでは、メール送信のようなバックグラウンドタスクを実行するために個別のワーカープロセスを使用するのが一般的です。
Auto Deploy で使用されるデフォルトの Helm チャ ートはワーカープロセスの実行をサポートしています。
ワーカーを実行するには、ワーカーが標準的なヘルスチェックに応答できることを確認する必要があります。標準的なヘルスチェックでは、ポート5000 で正常な HTTP 応答が期待されます。Sidekiq については、sidekiq_alive gemを使うことができます。
Sidekiqを使用するには、デプロイがRedisインスタンスにアクセスできることも確認する必要があります。Auto DevOpsはこのインスタンスをデプロイしてくれません：
- 独自のRedisインスタンスをメンテナーしてください。
- CI/CD 変数
K8S_SECRET_REDIS_URLにこのインスタンスの URL を設定し、デプロイに渡せるようにします。
ヘルスチェックに応答するようにWorkerを設定したら、Railsアプリケーション用にSidekiq Workerを実行します。.gitlab/auto-deploy-values.yaml ファイル で以下を設定することで、ワーカーを有効にできます：
workers:
sidekiq:
replicaCount: 1
command:
- /cnb/lifecycle/launcher
- sidekiq
preStopCommand:
- /cnb/lifecycle/launcher
- sidekiqctl
- quiet
terminationGracePeriodSeconds: 60
コンテナでのコマンド実行
リポジトリにカスタムDockerfileが含まれていない限り、デフォルトではHerokuishを使用してAuto Buildでビルドされたアプリケーションは、以下のようにコマンドをラップする必要があるかもしれません：
/bin/herokuish procfile exec $COMMAND
コマンドをラップする必要があるいくつかの理由：
-
kubectl execを使ったアタッチ。 - GitLabウェブターミナルを使用します。
例えば、アプリケーションのルートディレクトリから Rails コンソールを起動するには、次のように実行します：
/bin/herokuish procfile exec bin/rails c
Cloud Native Buildpacksを使用する場合は、/bin/herokuish procfile exec の代わりに次のようにします。
/cnb/lifecycle/launcher $COMMAND
自動モニタリング (削除)
この機能はGitLab 14.7で非推奨となり、16.0で削除されました。
自動コードインテリジェンス
GitLab 13.5 で導入されました。
GitLabコードインテリジェンスは、対話型開発環境(IDE)、型シグネチャ、シンボルドキュメント、ゴーゴー定義などのコードナビゲーション機能を追加します。LSIFによって提供され、Go言語を使用するAuto DevOpsプロジェクトでのみ利用可能です。GitLabは、より多くのLSIFインデクサが利用可能になるにつれて、より多くの言語のサポートを追加する予定です。アップデートはコードインテリジェンス・エピックで確認できます。
このステージはデフォルトで有効になっています。無効にするにはCODE_INTELLIGENCE_DISABLED CI/CD 変数を追加してください。Auto DevOpsジョブの無効化については、こちらをご覧ください。