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 接続を使用）。
