Enterprise DevOps enterprise-devops
DevOps では、以下の目的に必要なプロセス、メソッドおよびコミュニケーションを扱います。
- 様々な環境にわたるソフトウェアのデプロイメントを容易にする。
- 開発、テスト、デプロイメントチーム間のコラボレーションを簡素化する。
DevOps は、次のような問題を回避することを目的としています。
- 手動によるエラー。
- 要素の抜け（ファイルや設定の詳細など）。
- 不一致（開発者のローカル環境とその他の環境など）。
環境 environments
Adobe Experience Manager（AEM）のデプロイメントは通常、次のような複数の環境で構成され、それぞれが様々なレベルで様々な目的に使用されます。
開発 development
開発者は、必要な機能をすべて備えた、提案されたプロジェクト（web サイト、モバイルアプリケーション、DAM 実装など）の開発とカスタマイズを担当します。開発者は、次の作業を行います。
- テンプレート、コンポーネント、ワークフロー、アプリケーションなど、必要な要素の開発とカスタマイズ
- デザインの実現
- 必要な機能を実装するために必要なサービスおよびスクリプトの開発
開発環境の設定には様々な要素が影響しますが、次のもので構成されます。
- 統合コードベースを提供するバージョン管理を備えた統合開発システム。この統合コードベースは、各開発者が使用する個々の開発環境からコードを結合し、統合するために使用します。
- 各開発者の個人環境。通常はローカルマシン上に存在します。コードは適切な間隔で、バージョン管理システムと同期されます。
システムの規模によっては、開発環境にオーサーインスタンスとパブリッシュインスタンスの両方を含めることができます。
品質保証 quality-assurance
品質保証チームは、この環境を使用して、新しいシステムのデザインと機能を包括的にテストできます。適切なコンテンツを含むオーサー環境とパブリッシュ環境の両方を持ち、完全なテストスイートを実施するために必要なすべてのサービスを提供する必要があります。
ステージング staging
ステージング環境は、実稼動環境（設定、コード、コンテンツ）のミラーである必要があります。
- 実際のデプロイメントの実装に使用するスクリプトをテストするために使用します。
- また、実稼動環境にデプロイする前の最終テスト（デザイン、機能、インターフェイス）にも使用できます。
- ステージング環境を実稼動環境と同一にすることが不可能な場合もありますが、パフォーマンスと負荷のテストができるように、できる限り近い環境にする必要があります。
実稼動 - オーサーとパブリッシュ production-author-and-publish
実稼動環境は、実装を実際にオーサリングおよび公開するために必要な環境で構成されます。
実稼動環境は、少なくとも 1 つのオーサーインスタンスと 1 つのパブリッシュインスタンスで構成されます。
プロジェクトの規模に応じて、多くの場合、複数のオーサーインスタンスや複数のパブリッシュインスタンス、またはその両方で構成されます。下位レベルでは、リポジトリーが複数のインスタンスにクラスター化される場合もあります。
作成者 author
オーサーインスタンスは通常、内部ファイアウォールの内側に配置されます。この環境では、ユーザーやユーザーの同僚が、以下のようなオーサリングタスクを実行します。
- システム全体の管理
- コンテンツの入力
- コンテンツのレイアウトとデザインの設定
- パブリッシュ環境に対するコンテンツのアクティベート
アクティベートされたコンテンツはパッケージ化され、オーサー環境のレプリケーションキューに配置されます。次に、レプリケーションプロセスは、そのコンテンツをパブリッシュ環境に転送します。
パブリッシュ環境で生成されたデータをオーサー環境にリバースレプリケートするには、オーサー環境のレプリケーションリスナーがパブリッシュ環境をポーリングし、そのようなコンテンツをパブリッシュ環境のリバースレプリケーションアウトボックスから取得します。
公開 publish
パブリッシュ環境は「非武装地帯」（DMZ）内にあります。この環境では、訪問者は公開されているかイントラネット内かにかかわらず、（web サイトやモバイルアプリケーションの形式などの）コンテンツにアクセスして操作します。パブリッシュ環境では、次の処理が行われます。
- オーサー環境からレプリケートされたコンテンツを保持します
- そのコンテンツを訪問者が利用できるようにします
- コメントやその他のフォーム送信など、訪問者によって生成されたユーザーデータを保存します。
- オーサー環境にリバースレプリケーションできるように、そのようなユーザーデータをアウトボックスに追加するよう設定できます
パブリッシュ環境では、コンテンツがリアルタイムで動的に生成され、個々のユーザーに合わせて、コンテンツをパーソナライズできます。
コードの移動 code-movement
コードは常に下から上に生成されます。
- コードはまずローカルで、その後統合開発環境で開発される
- 続いて、QA 環境で十分なテストを実施する
- その後、ステージング環境でさらにテストする
- その後初めてコードは実稼動環境にデプロイされる
コード（カスタマイズされた web アプリケーション機能やデザインテンプレートなど）は、異なるコンテンツリポジトリ間でパッケージを書き出したり読み込んだりすることによって転送されます。場合によっては、このレプリケーションを自動プロセスとして設定できます。
AEM プロジェクトでは、多くの場合、次のようにコードのデプロイメントをトリガーします。
- 自動：開発環境および QA 環境への転送の場合。
- 手動：ステージング環境および実稼動環境へのデプロイメントは、より制御された方法で行われるので、多くの場合は手動ですが、必要に応じて自動化も可能です。
コンテンツの移動 content-movement
実稼動用に作成されているコンテンツは、実稼動オーサーインスタンスで 常に オーサリングする必要があります。
コンテンツは、下位環境から上位環境へ移動するコードに従うことはできません。ローカルマシン以下の環境で作成者にコンテンツを作成させ、それを実稼動環境へ移動するのは適切な方法ではなく、エラーや不整合の原因となる可能性が高いからです。
実稼動コンテンツを実稼動環境からステージング環境へ移動して、ステージング環境で効率的かつ正確なテスト環境が提供されることを確認する必要があります。
コンテンツは次のような転送が可能です。
- 異なる環境間 - パッケージを書き出したり読み込んだりします。
- 異なるインスタンス間 - コンテンツを直接レプリケート（AEM レプリケーション）します（HTTP または HTTPS 接続を使用）。
