BAsixs(ベーシックス)

「あたりまえ」をアップデートしつづける

AEM as a Cloud:複数環境を適切に使用する

読了目安 : 6

  • 投稿日 :
  • 最終更新日 :

この記事を書いた人

プロフィールアイコン(写真):シニアエンジニア 湯澤
湯澤シニアエンジニア(ビジネス・アーキテクツ)

新卒でIT大手企業に入るも、大企業ならではの見通しの悪さや動きの遅さに我慢ができず転職。ちょうどインターネットが出てきた時代(1994年)だったので、かかわる仕事がしたいと思い出版社(音楽、コンピューター関連)に転職。インターネットの初めてをいろいろ担当。日本最初のメルマガ、日本最初のストリーミング放送、日本最初のカートシステム等。その後、EコマースASP会社(日商1億程度)のCTOを経て、ビジネス・アーキテクツに転職。エンジニア、パートナー開発を経て現在は主にインフラエンジニア、サーバーエンジニアを担当。プロジェクトによってはディレクターも兼務する。

Webアプリケーションを開発する際は、いろいろ工夫して環境を整備する必要があります。一般的には、開発環境、検証(ステージング)環境、本番環境のように複数環境を用意して開発を進めることが多いと思います。

このコラムではAEM as a Cloud(以下、AEM Cloud)の場合、それぞれの環境をどう使い分けるのか?の一例をご紹介します。

AEM as a Cloud:複数環境を適切に使用する

はじめに

Webアプリケーションを開発する上で、いろいろ工夫して環境整備をしているかと思います。一般的に開発環境、ステージング環境、本番環境のように複数環境を用意して開発を進めるのが一般的かと思います。

このコラムはAEM Cloudの場合に、その環境の使い分けをどうするのかの一例になります。
AEM Cloudについては、以下の記事をご覧ください。
コスト削減を実現しつつAEMを使えるクラウドサービス | BAsixs(ベーシックス)

今回説明するプロジェクトについて

以下を前提として説明します。

  • グローバルサイト
  • B to Bのコーポレートサイト
  • 別のCMSからAEM Cloudへの移行
  • 制作会社と事業会社のそれぞれで役割を持って開発を行う
  • 全ての言語サイトを一度に公開するのではなく、言語ごとに徐々に公開していく

今回、例として説明するプロジェクトでは、事業会社と制作会社での役割分担は以下のようになっていました。

初期開発時

  • 制作会社
    • AEM Cloudの設定全体・コンポーネント・ページの開発を行い、一部コンテンツの入力も行う
  • 事業会社
    • コンテンツの入力と、一部コンポーネントを使用したページの制作を行う

運用時

  • 制作会社
    • 設定全体、コンポーネントの開発を行う
  • 事業会社
    • コンポーネントを使用したページの制作とコンテンツの入力を行う

AEM Cloudでの複数環境

まずはじめにAEM Cloudでの環境について、さらにその作った環境内でのセグメントについても説明します。

AEM Cloudでは環境を複数用意でき、それぞれを独立して運用することが可能です。もちろん、そのそれぞれに独自ドメインを割り当てることも可能で、IP制限等もこの環境ごとに定義できます。

今回の例では、環境を3つ用意しました。

本番環境
実際にインターネットに公開するための環境で、どのユーザーもアクセス可能な環境になります。

なお今回のように新規の構築になる場合に限っては、ステージングを経由せず最初から本番環境を使用することもできます。本番環境といってもまだ公開されていないためです。

ステージング環境
今回の例では、コンテンツの公開前確認は本番環境内のセグメント(後述)を利用します。そのためステージング環境は、開発したコンポーネントやページに対するUATに使用します。

CMSを使用したサイトのステージング環境は、コンテンツに対するステージングなのか、それとも開発したコンポーネントやページに対するステージングなのか、またはその両方なのかが曖昧になりがちです。そのため、どのパターンなのかを最初に明確にしておくことが大切です。

開発環境
開発環境は、今回のプロジェクトではいくつかの役割がありました。代表的なものは以下の2つです。

  • 開発者が開発したものを、制作会社の他のメンバーが確認するため
  • UATが始まる前に、制作しているものがお客さまの要望にあっているかをAEM Cloud環境で確認するため

環境内セグメント

環境内セグメントは一般的に、AuthorセグメントとPublishセグメントの2つがあります。

Authorセグメントは名前の通り、コンテンツの編集や確認をするセグメントで、個々のコンテンツをPublishすることによって、Publishセグメントで見ることができるようになります。また、ドメイン名は各環境ごとに異なりますが、セグメントの場合は同一ドメイン名のままURIが変わります。

そして最も大きな違いは、PublishセグメントがAEM Cloudにログインすることなく閲覧が可能という点です。ただし、Authorセグメントを利用するためには、AEM Cloudにログインする必要があります。

コンテンツの検証は通常、本番環境でのAuthorセグメントを使用することが多いと思います。今回の例でも、事業会社のコンテンツ更新についてはこの方針にしています。

ただ上記の通り、Authorセグメントを閲覧するには、基本的にAEM Cloudへのログインが必須となるため注意が必要です。
Authorセグメントでログインせずにコンテンツを確認するには、プレビューという機能を使うことで可能になります。通常のAuthorセグメントとは別のURLが割り振られます。

多くの人が検証する場合には、このプレビュー機能を使ったり、ステージング環境のPublishセグメントの使用を検討する必要があります。

ローンチ機能

もうひとつAEM Cloudの環境として重要になる機能としてローンチ機能が存在します。これは複数機能の開発や、複数公開日のコンテンツ更新を同時に走らせる場合に有効です。

Gitについてご存知であれば、近い機能を想像していただければと思います。

ローンチ機能の中である時点でのサイトのコピーを取り、実際の本番環境とは独立した環境を作成できます。その独立した環境をローンチと呼びます。ローンチは複数作成することが可能です。

そのローンチ内での更新は、本番環境に影響することなく更新を進められます。

例えば、2024年8月公開のコンテンツと2024年9月公開のコンテンツを、別々のローンチとして準備したとします。この場合、8月には8月用のローンチを公開し、9月にはそのあとで別途進めていた9月用のローンチを公開、という複数の開発進行と公開準備をお互いに影響することなく進めることが可能です。

さらに、ローンチ作成時点から公開までの間にサイト更新があった場合でも、それを自動的にローンチに取り込むことも可能です。

CI/CDパイプラインとの連携

AEM Cloudの開発では、Gitのコード管理とCI/CDパイプラインを使用してそれぞれの環境にコードをデプロイすることになります。

したがって、本番・ステージング・開発それぞれの環境用にGitのリポジトリを使用して開発を進めます。

まとめ

AEM Cloudでは、ここでは書ききれなかったことも含めさまざまな環境の使い分けができます。ただそれだけに、複雑になりすぎないよう注意が必要です。

開発をはじめる前に、各環境の目的や役割を慎重に検討・設計する必要があります。