コンテンツにスキップ

ワークフロー#

Lagoonは、可能な限り多様な開発ワークフローをサポートしようとしています。特に、チームに対して特定のワークフローを強制することなく、各開発チームが自分たちのコードをどのように開発しデプロイするかを定義できます。

固定ブランチ#

最も直接的なワークフローは、いくつかの固定ブランチに基づいたデプロイメントです:

Lagoonがデプロイすべきブランチ(例えば develop、staging、mainなど、これらは正規表現で ^(develop|staging|main)$となります)を定義し、それを実行します。それで完了です！

新しい機能をテストしたい場合は、ローカルで設定したブランチにそれらをマージしてプッシュし、Lagoonがその機能をデプロイします。問題がなければ、そのブランチをあなたの本番ブランチにマージしてプッシュします。

フィーチャーブランチ#

もう少し高度なものになると、フィーチャーブランチがあります。Lagoonは、デプロイしたいブランチを正規表現で定義する能力をサポートしているので、上記の正規表現をこのように拡張することもできます:^feature\/|^(staging|main)$。これにより、Lagoonはfeature/で始まるすべてのブランチ、およびstagingとmainという名前のブランチをデプロイするよう指示します。私たちの開発ワークフローは以下のようになるかもしれません:

  • 新しいブランチを作成する mainからfeature/myfeatureを呼び出し、feature/myfeatureをプッシュします。
  • Lagoonは、feature/myfeatureブランチを新しい環境としてデプロイし、他の機能とは独立して機能をテストできます。
  • feature/myfeatureをmainブランチにマージすると、それはあなたの本番環境にデプロイされます。

もしご希望であれば、feature/myfeatureや他のフィーチャーブランチを最初にstagingにマージして、複数の機能を一緒にテストすることもできます。その後、mainにマージできます。

このワークフローは、Gitリポジトリのブランチの整理とクリーンさが非常に重要です。各フィーチャーブランチは自身のLagoon環境を作成するため、非常に速く大量の環境を生成することができ、それら全てがリソースを消費します。未使用のブランチは必ずマージするか削除してください。

このため、プルリクエストベースのワークフローを考えることが理にかなっているかもしれません。

プルリクエスト#

さらに高度なワークフローはプルリクエストによるものです。このようなワークフローは、プルリクエスト(またはマージリクエストとも呼ばれます)をサポートするGitホスティングのサポートが必要です。プルリクエストベースのワークフローのアイデアは、ビルド中にLagoonがマージを行ってくれるので、実際にマージする必要はなく、ターゲットブランチと一緒に機能をテストできるというアイデアの背景にあります。

私たちの例では、Lagoonを設定して、ブランチ^(staging|main)$とプルリクエストを.* (すべてのプルリクエストをデプロイする)にデプロイさせます。 これでワークフローは次のようになります:

  1. mainから新しいブランチfeature/myfeatureを作成し、feature/myfeatureをプッシュします(デプロイされるブランチはstagingとmainのみのため、今はデプロイは行われません)。
  2. あなたのGitホスティングでfeature/myfeatureからmainへのプルリクエストを作成します。
  3. Lagoonは今、feature/myfeatureブランチをmainブランチの上にマージし、その結果のコードをデプロイします。
  4. これで、feature/myfeatureブランチの機能をテストできます。まるでmainにマージされたかのように、feature/myfeatureブランチを作成してからmainで起こったすべての変更がそこにありますので、mainブランチの古いバージョンを持っているかもしれないと心配する必要はありません。
    1. マージの競合がある場合、ビルドが失敗し、Lagoonは停止してあなたに通知します。
  5. あなたがプルリクエストのテストを終えた後 リクエストブランチでは、Gitホスティングに戻って実際にコードをmainにマージすることができます。これにより、mainのデプロイがトリガーされます。
  6. プルリクエストがマージされると、自動的にクローズされ、Lagoonはプルリクエストの環境を自動的に削除します。

一部のチームでは、共有のstagingブランチに対してプルリクエストを作成し、その後、別のプルリクエストを介してstagingブランチをmainブランチにマージすることを選択するかもしれません。これは、使用しているGitのワークフローの種類によります。

また、Lagoonでは、タイトルに特定のテキストがあるプルリクエストのみをデプロイするように設定することができます。正規表現として定義された[BUILD]は、タイトルが[BUILD] My Pull Requestのようなプルリクエストのみをデプロイし、タイトルがMy other Pull Requestのようなプルリクエストは自動的にデプロイされません。これにより、環境の数を少なく保つことができ、まだ環境が必要でないプルリクエストを保持すること可能にします。

プルリクエストの自動データベース同期#

自動的なプルリクエストの環境は素晴らしいことです。しかし、それらの環境が作成されたときに別の環境からデータベースが同期されると便利だろうとも思います。Lagoonはそれを扱うことができます！

次の例は、プルリクエスト環境の最初のロールアウトでステージングデータベースを同期します:

.lagoon.yml
tasks:
  post-rollout:
    - run:
        name: IF no Drupal installed & Pullrequest = Sync database from staging
        command: |
            if [[ -n ${LAGOON_PR_BASE_BRANCH} ]] && tables=$(drush sqlq 'show tables;') && [ -z "$tables" ]; then
                drush -y sql-sync @staging default
            fi
        service: cli
        shell: bash

プロモーション#

環境にコードをデプロイする別の方法は、プロモーションワークフローです。

プロモーションワークフローの考え方は、例としてここから来ています。

stagingブランチをmainブランチにマージし、mainに変更がなければ、つまりmainとstagingがGitでまったく同じコードを持っている場合でも、結果として得られるDockerイメージがわずかに異なる可能性があります。これは、最後のstagingデプロイメントと現在のmainデプロイメントの間に、いくつかの上流Dockerイメージが変更されたか、またはさまざまなパッケージマネージャーによってロードされた依存関係が変更された可能性があるためです。これは非常に小さい確率ですが存在します。

そのため、 この状況ではLagoonは一つの環境から別の環境へのLagoonイメージのプロモーションという概念を理解しています。これは基本的に、すでに構築されデプロイされたDockerイメージを一つの環境から取り出し、それらのまったく同じDockerイメージを別の環境で使用するということを意味します。

私たちの例では、main環境からproduction環境へDockerイメージをプロモートしたいと思っています:

  • 最初に、mainという名前の通常のデプロイ環境が必要です。環境が正常にデプロイされていることを確認してください。
  • また、Gitリポジトリにproductionという名前のブランチがないことを確認してください。これがあると、人々がこのブランチにプッシュするなど、奇妙な混乱を引き起こす可能性があります。
  • 次に、lagoon cliを使用してプロモーションデプロイメントをトリガーします:
プロモーションデプロイメントをトリガーする
lagoon deploy promote --project="myproject" --source="main" --destination="production"

これは、ソースmainからデスティネーションproductionへのプロモーションを希望することをLagoonに伝えます。

Lagoonは次のことを行います:

  • .lagoon.ymlとdocker-compose.ymlファイルをロードするために、Gitブランチmainをチェックアウトします(Lagoonが 完全に動作するにはこれらがまだ必要です)。
  • docker-compose.ymlで定義されたサービスに対して、すべてのKubernetes/OpenShiftオブジェクトを作成しますが、環境変数としてLAGOON_GIT_BRANCH=productionを使用します。
  • main環境から最新のイメージをコピーし、それらを使用します(イメージをビルドしたり、上流からタグ付けしたりする代わりに)。
  • 通常のデプロイメントのように、すべてのポストロールアウトタスクを実行します。

他のデプロイメントと同様に、成功または失敗の通知を受け取ります。