チェックリスト - 詳細情報 the-checklist-further-reference

このページでは、プロジェクトの管理 - ベストプラクティスチェックリストで扱ったドキュメントや原則を、拡張および補足する詳細情報を提供します。

AEM - 何を使用しますか? aem-what-will-you-be-using

CAUTION
このセクションのリストは完全なものではなく、概要を示しています。

AEM 内の機能 features-within-aem

AEM を実装するとき(特に初回)は、AEM の機能とワークフローを見直して、必要な範囲を確認する必要があります。

次のように、使用する AEM の機能と、デザインへの影響を検討します。

また、リリースノートでをチェックして、AEM の様々なバージョンで新機能が追加された時期を確認します。

統合 integrations

AEM は、他のアドビ製品やサードパーティのサービスと統合できます。これらのワークフローにより、自由にパワーと機能を高めることができます。

詳しくは、ソリューションの統合を参照してください。

移行かアップグレードか migrate-or-upgrade

主な考慮点は、次のどちらを実行するかです。

  • 既存のインストールをアップグレードする。
  • コンテンツを現在のシステムから新しいインストールに移行する。

以前のバージョンから現在のバージョンに移行する場合、次の 2 つのオプションがあります。

  • パッケージマネージャーを使用して、旧システムから新システムにすべてのコンテンツとアプリケーションコードをエクスポートする。
  • 既存の旧システムをアップグレードする。通常は、この方法を選択することをお勧めします。

基本的なルール basic-ground-rules

あらゆるプロジェクトと同様に、できるだけ早い時期に基本原則を確立することが重要です。そのルールには、以下が含まれます。

NOTE
これらは一般的な項目です。AEM に関連した具体例については、ベストプラクティスチェックリストで扱っています。
  • 役割

    役割は、明確に定義し、プロジェクトに関わるすべてのユーザーに知らせる必要があります。また、以下を強調することをお勧めします。

    • 意思決定者
    • 連絡先
  • 責務

    • 各役割に対して、プロジェクトに関連した責務を明確に定義すると、混乱を防ぐことができます。
  • 関与

    できるだけ早期に関係者を巻き込み、プロジェクトの​ ステークホルダー ​になるよう促すことができます。そうすることで、成功へのコミットメントが高まります。

    • お客様側では、この役割には、日常的にシステムを操作する作成者が含まれます。
    • 自身のプロジェクトチーム内では、この関与には、品質保証を担当する人も含まれます。お客様の要件を理解すればするほど、より適切にテストを計画できるようになります。
  • コミュニケーション経路

    • コミュニケーション経路は過度に形式化すべきではありませんが、具体的に定義することで、主要な人々に常に情報を提供し、最新の状態に保つことができるようになります。外部の関係者とのコミュニケーションには、特に注意が必要です。
  • プロセス

    定義するプロセスは、個々のプロジェクトに応じて異なります。ここでも、次の点を考慮して、これらのプロセスをシンプルに保つようにしてください。

    • サードパーティ(特に設計会社やサードパーティ製ソフトウェアのサプライヤーなど)とやり取りするプロセス(およびコミュニケーション経路)の定義。
    • 多くの場合、お客様にはプロジェクト管理とレポーティングを行う独自の手順とツールがあります。
  • トラッキングツール

    プロジェクトに関するバグやタスクなどの情報をトラッキングできるツールは多数あります。詳しくは、使用できるツールの概要を参照してください。

    • ここで注意すべき重要な点は、情報のコピーを 1 つだけ保持し、情報を共有することです(したがって、使用中のツールにアクセスする)。このワークフローは、メンテナンスを容易にし、不一致を防ぐのに役立ちます。
  • 範囲

    様々なレベルで、プロジェクトでカバーする内容を明確に定義します。

    • 個々のリリース(反復リリースプロセスを使用する場合、顧客に提供されるか社内テストチームに提供されるかに関係なく)。
    • AEM プロジェクト。
    • プロジェクト全体(サードパーティ製ソフトウェア、テストへの影響、組織の問題、その他多くを含みます)。
    • プロジェクトの範囲内に​ ない ​ものを示すことが役に立つ場合もあります。このアイデアは、必須の問題に限定されるべきですが、混乱や誤認を防ぐのに役立ちます。
  • レポート

    レポートする情報、形式、頻度およびレポート先を明確に定義します。

  • 用語

    • 使用する略語やお客様固有の用語を定義します。
  • 前提

    • あらゆる想定事項を定義します。

この情報は、プロジェクトハンドブック内で定義できます。また、Wiki の使用も、継続的な変化に効率よく対応するために役立ちます。これらの前提がどこで定義されるかに関わらず、重要な要因は以下のとおりです。

  • 情報の定義と管理
  • 情報は、関係者全員に明確に伝えます。標準的なプロジェクト管理手法ではありますが、役割定義が明確であるかや、コミュニケーションが良好であるかによって、プロジェクトの成否が左右されるということを繰り返し意識する必要があります。
  • 例えば、バグトラッキングや問題のトラッキングなど、トラッキングされる情報は 1 つのバージョンしか保持されません。

主要業績評価指標とターゲット指標 key-performance-indicators-and-target-metrics

組織は、目標達成の成功度合いを評価するために、主要業績評価指標(KPI)を使用します。この指標は測定可能な値であり、具体的な目標がいかに効果的に達成されたかを示すことができます。

以下の指標があります。

  • ビジネス:

    • 主要なビジネス目標を測定します。
    • 実際のビジネスやシナリオに適した KPI を選択することが重要です。何が KPI であるか、どのように測定するか、誰がどのように使用するかを明確に定義する必要があります。
  • パフォーマンス:

    • システムのパフォーマンスの測定方法を定義します。
    • 例として、ページの読み込み時間、サーバーの応答時間、データベースのクエリパフォーマンスなどがあります。

指標の一部は、特定および定義されたターゲット指標をベースとすることができますが、すべてそのようにする必要はありません。

ターゲット指標 target-metrics

指標を使用すると、web サイトの品質に関する定量的な測定値を定義できます。基本的には、パフォーマンスの達成目標の定義であり、KPI(主要業績評価指標)を定義する際に使用できます。

多くの指標を定義できますが、多くの場合、定義した指標はパフォーマンスと同時性に関する目標を定義するものです。特に、量的に示すことが難しく、感情 ​によって評価される傾向にある、次のような要素について定義します。

  • 「今日は web サイトが​ あまりにも遅い」- 遅い ​というのはいつからですか?

  • 「同僚がログインするとすべてが​ 止まってしまう」- システムでサポートできる同時ユーザー数は何人ですか?

  • 「検索するとシステムが​ 停止してしまう」- システムに影響を与えている検索リクエストはどれですか?

  • 「ファイルのダウンロードに​ 長い時間 ​がかかる」-(標準ネットワーク条件下で)許容されるダウンロード時間はどのくらいですか?

Target 指標は、プロジェクトの開始時に次の目的で定義されます。

  • 提供できる web サイトの期待されるディメンションを示す
  • 達成したい最低品質を示す
  • これらの要因の測定方法を定義する
  • 主要業績評価指標のベースとして使用される

ターゲット指標を定義する際は、常に注意する必要があります。

  • 高く設定しすぎると、達成できない可能性がある
  • 低く設定しすぎると、変動が目立たない可能性がある
  • 繰り返し、一貫して測定できるようにする
  • 異なる要因を測定するようバランスを提供する
  • 特定の指標はテスト環境に関連するが、一部の指標は、実稼動 web サイトで測定可能かつ再現可能な実際のシナリオを反映する必要がある
  • Web サイトに対する指標の重要性に従って指標を優先順位付けする
  • 指標を監視できるセットに制限する

これらの指標は、プロジェクトの開発時に必要に応じて更新したり、調整したりできます。プロジェクトが正常に実装されたら、これらの指標を使用してインストール環境を制御したり、継続中の操作に必要なサービスレベルの監視や維持を行ったりできます。

適切に使用すると、これらの指標は役立つツールとなりますが、無責任に使用すると時間を無駄にすることになります。何をどのように測定するのか、およびその理由を必ず理解するようにします。

NOTE
この節では、考慮すべき基本原則と問題について説明します。インストールはそれぞれ異なるので、測定する実際の値は異なる傾向があります。

すべての基礎となるプロジェクトデザイン everything-rests-on-your-project-design

すべての測定指標は、プロジェクトデザインの影響を受けます。逆に、問題が多数ある場合は、デザインの変更によって解決されるのが最善です。

したがって、デザインを決定する​ 前に ​ターゲット指標を定義します。これにより、これらの要因に基づいてデザインを最適化できます。プロジェクトの開発後、基本的な設計原則に対して最適化するのは困難です。

Web サイトの構造を作成する際には、AEM の web サイトで推奨される構造に従います。次の問題や原則を必ず理解しておいてください。

  • Web サイトのコンテンツを構築する方法。
  • テンプレートとコンポーネントの動作方法。
  • キャッシュの動作方法。
  • パーソナライズされたコンテンツの影響。
  • 検索機能の仕組み。
  • CSS と関連テクノロジーを使用して、コンパクトで冗長でない HTM Lコードを作成する方法。

デザインがガイドラインに従っていないと感じる場合、または意味の一部が不明な場合は、これらの問題を明確にしてください。プログラミング段階またはコンテンツへの入力を開始する前に行います。

インフラストラクチャ infrastructure

インフラストラクチャを定義または評価するには、次のようなターゲット値を定義すると役立ちます。

  • 訪問者/日(平均とピークの両方)
  • ヒット/日(平均とピークの両方)
  • 使用可能にする web ページの数
  • web コンテンツの量

使用時の状況、および web サイトの戦略的意義に応じてインフラストラクチャを定義することで、インフラストラクチャの評価と選択に役立ちます。

  • サーバーの数
  • AEM インスタンス(オーサーおよびパブリッシュ)の数

パフォーマンス performance

評価できるパフォーマンス要因はいくつかあります。

  • 個々のページの応答時間は、次を考慮します。

    • オーサー環境での応答時間
    • パブリッシュ環境での応答時間
  • 検索リクエストの応答時間

この節とパフォーマンスの最適化を合わせて読むと、実際のパフォーマンス測定技術の詳細を把握できます。

個々のページの応答時間 response-times-for-individual-pages

Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。

応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。この値が達成可能かつ維持可能な数値と証明されれば、Web サイトのパフォーマンスを監視したり、潜在的な問題の進行を示したりするために使用できます。

オーサー環境とパブリッシュ環境でのターゲットの違い

オーサー環境とパブリッシュ環境では、対象ユーザーが異なるので、目標とする応答時間が異なります。

  • オーサー環境

    この環境は、コンテンツの入力および更新を行う作成者が使用する環境なので、以下のように設定することが必要です。

    • コンテンツページやページ内の各要素を更新する際に、多数のリクエストを発生させる少数のユーザーに対応する
    • コンテンツを Web サイトにできる限り速く展開し、生産性を最大限に高める
  • パブリッシュ環境

    この環境には、ユーザー向けに提供するコンテンツが置かれます。

    • 速さは重要ですが、多くの場合、オーサー環境より遅くなる

    • パフォーマンス強化メカニズムの追加は、多くの場合、次のように適用されます。

      • コンテンツがキャッシュされる
      • 負荷分散が適用される

目標応答時間の設定 setting-target-response-times

達成可能な(平均的な)応答時間は、どのようにして決定できるでしょうか。この質問と答えは、多くの場合、経験の問題です。

  • Web サイトでのエクスペリエンス
  • AEM の使用経験
  • 平均応答時間を超える複雑なページの認識(可能な場合は個別に最適化する必要があります)

ただし、制御された状況では、次のガイドラインを適用できます。

  • ページに対するリクエストの 70 %に 100 ms 未満で応答。
  • ページに対するリクエストの 25 %に 100 ms ~ 300msで応答。
  • ページに対するリクエストの 4 %に 300 ms ~ 500ms 未満で応答。
  • ページに対するリクエストの 1 %に 500 ms ~ 1000 ms で応答。
  • どのページについても、応答時間が 1 秒を超えてはいけません。

以上の数値は、次の条件を前提としています。

  • パブリッシュ環境で測定(オーサー環境や CFC のオーバーヘッドではない)
  • サーバー上で測定(ネットワークオーバーヘッドを考慮しない)
  • キャッシュされない(AEM 出力キャッシュや Dispatcher キャッシュがない)
  • 多数の依存ファイル(HTML、JS、PDF など)を伴う複雑な要求のみ
  • 他のシステム負荷なし

応答時間の監視に使用できるメカニズムはいくつかあります。

  • AEM の request.log を使用した応答時間の監視

    パフォーマンス分析は、リクエストログから始めることをお勧めします。この情報を使用すると、個々のリクエストの応答時間を確認できます。詳しくは、パフォーマンスの最適化を参照してください。

  • HTML コメントを使用した応答時間の監視

    HTML コメント を使用すると、各ページのソース内に次のように応答時間の情報を含めることができます。

    </body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

検索リクエスト search-requests

検索リクエストは、次の両方の点で、web サイトに重大な影響を与える可能性があります。

  • 検索自体のの応答時間

    • 高速な検索機能は、Web サイトの品質の目標です。
  • 全般的なパフォーマンスへの影響

    • 検索機能は、コンテンツのセクション(大きい可能性が高い)や、特別に抽出されたインデックスをスキャンする必要があるので、この機能は最適化されていないと、システム全体のパフォーマンスに影響を与える可能性があります。

検索リクエストのターゲット設定も、以下のような経験に基づいて行います。

  • AEM の 経験
  • 他の目標と比較した、検索の使用頻度の評価
  • 永続性マネージャー
  • 検索インデックス
  • 検索機能の複雑さ。検索語句を 1 つ入力できる基本的な検索機能は、AND や OR、NOT を使用して複雑な検索文を作成できる高度な検索機能よりも迅速です。

これらの検索リクエストは、プロジェクトの最初の時点から計画し、統合する必要があります。監視には次のメカニズムを使用できます。

  • AEM request.log を使用した検索応答時間の監視

    この場合も、request.log を使用すると、検索リクエストの応答時間を監視できます。詳しくは、パフォーマンスの最適化を参照してください。

  • 検索応答時間を測定するためのプログラムされたメカニズム

    検索リクエストに関して収集する情報、および検索リクエストのパフォーマンスをカスタマイズするには、プロジェクトのソースコードに情報の収集を含めることをお勧めします。詳しくは、パフォーマンスの最適化を参照してください。

同時並行性 concurrency

オーサー環境とパブリッシュ環境の両方で、ユーザーや訪問者が Web サイトを使用できるようにします。ユーザー数は、通常、テスト時に使用したユーザー数より多く、変動し、予測が困難です。パフォーマンスに悪影響を及ぼすことなく、同時に使用するユーザーや訪問者の平均数に合わせて web サイトを設計します。この場合も、request.log を使用して、同時実行テストを実行します。詳しくは、パフォーマンスの最適化を参照してください。

同時ユーザー数の目標は、環境の種類に応じて異なります。

  • オーサー環境

    • 通常、同時ユーザー数は正確に見積もることができます。同時にアクティブとなる作成者の数は把握できなくても、作成者の総数はわかります。
  • パブリッシュ環境

    • パブリッシュ環境の予測はより困難なので、ターゲット値を選択する必要があります。この値も、現在の web サイトでの経験と、新しい web サイトに対する現実的な期待に基づく必要があります。
    • 特別なイベント(例えば人気のあるコンテンツを新規公開する場合)では、予測を超えたり、(イベントのチケットの発売時に報道されたりすると)処理能力を超えたりすることもあります。

処理能力とボリューム capacity-and-volume

関連する指標について説明する前に、いくつかの用語の大まかな定義を示します。

  • ボリューム

    • システムが処理し、提供する出力の量です。
  • 処理能力

    • ボリュームを提供するシステムの能力です。
    • 次の表に示すように、処理能力とボリュームの測定方法は各手順で異なります。最高のパフォーマンスを得るには、処理能力が各手順のボリュームに釣り合い、処理能力とボリュームの両方がすべての手順で共有されていることを確認します。例えば、リクエストごとにサーバーでナビゲーションを計算する代わりに、クライアントコンピューターで計算したり、キャッシュに格納したりできます。
  • 処理能力とボリューム

    table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3
    対象/場所 処理能力 ボリューム
    クライアント ユーザーのコンピューターの処理能力。 ページレイアウトの複雑さ。
    ネットワーク ネットワークの帯域幅。 ページ(コード、画像など)のサイズ。
    Dispatcher キャッシュ Web サーバーのサーバーメモリ(メインメモリとハードドライブ)。 Web サーバー(メインメモリとハードドライブ)。キャッシュされたページの数とサイズ。
    出力キャッシュ AEM サーバーのサーバーメモリ(メインメモリとハードドライブ)。 出力キャッシュ内のページの数とサイズ、ページあたりの依存関係の数。Dispatcher キャッシュを使用すると、このボリュームが少なくなります。
    Web サーバー Web サーバーの処理能力。 リクエストの数。キャッシュを使用すると、このボリュームが少なくなります。
    テンプレート Web サーバーの処理能力。 テンプレートの複雑さ。
    リポジトリ リポジトリのパフォーマンス。 リポジトリから読み込まれたページの数。

その他の指標 other-metrics

前の節では、定義が必要な主な指標について説明しました。

具体的な要件に応じて、個別に、または上記の分類を考慮して、追加の指標を個別に定義すると便利です。

ただし、web サイトのあらゆる側面を測定および定義しようとするのではなく、簡単かつ確実に機能する、正確で中核的な少しの指標を使用することをお勧めします。Web サイトは、その性質上、ユーザーに引き渡されるとすぐに変更と進化が始まります。

セキュリティ security

セキュリティはきわめて重要であり、対処すべき課題として深刻性を増しています。プロジェクトの早期の段階からセキュリティについて検討し、計画する必要があります​

セキュリティチェックリストでは、デプロイ時に AEM インストールを確実に保護するための手順が詳細に説明されています。その他のセキュリティ要素については、セキュリティ(開発時)およびユーザー管理とセキュリティを参照してください。

並列タスクと反復タスク parallel-and-iterative-tasks

NOTE
次のとおりです。
  • AEM プロジェクトの​ 最初の ​実装に関連する概要が提供されています。
  • 抽象的な概要を示すことを意図しています。具体的なフェーズやマイルストーン、タスクについては、プロジェクトチェックリストを参照してください。
  • どの時間スケールも理論上のものです。

標準的な AEM プロジェクトを新規に実装するには、以下のようなタスクを検討する必要があります。

  • 営業プロセスからの引き継ぎ。
  • お客様アプリケーションの実装(開発)。
  • お客様サイトでのインフラストラクチャ(および関連プロセス)の導入と設定(インフラストラクチャ)。
  • コンテンツの作成(または移行)(コンテンツ)。
  • 運用への引き継ぎ(メンテナンス/サポート)。
  • リリースのフォローアップ。

chlimage_1-2

すべての面で、反復アプローチを使用することをお勧めします。

chlimage_1-3

NOTE
現実的な条件下で実稼動環境でのチューニング、最適化、ユーザートレーニングを可能にするため、プロジェクトの立ち上げを​ ソフトローンチ(利用を制限、複数回繰り返し)と​ ハードローンチ(完全に利用可能 - ライブ状態)とに分割。
NOTE
プロジェクトのライフサイクルで実行(または評価)する必要のあるタスクの例については、プロジェクトチェックリストを参照してください。

各カテゴリについての留意事項を次に示します。

  • 開発

    • 基本アーキテクチャを最初に定義します。

    • 開発にはいくつかの繰り返し(スプリント)を使用します。

      • 最初のスプリントは最初の全開発サイクルに相当します。
      • 最初のスプリントの結果として、テスト環境への最初のデプロイを行います。
      • すべてのスプリントが実行可能な結果を持ちます。
      • スプリントごとにお客様の承認(最低限の構造テストとフィードバック)を得ます。
    • プロジェクトの進行中に利用可能な AEM バージョンが最終的に更新されるように計画します。

    • スプリント中にテストと最適化が行われるように計画します。

    • 安定化フェーズと最適化フェーズを計画します。

    • 今後のリリース対象として計画する項目のログを作成します。

    • パートナーの関与と引き継ぎを計画します。

  • インフラストラクチャ

    • 基本アーキテクチャを最初に定義します。

      • パフォーマンス要件を定義します。
      • パフォーマンス目標を定義します(つまり、期待事項を明確に定義します)。
      • サイジングを含め、ハードウェアとインフラのアーキテクチャを定義します。
      • デプロイメントを定義します。
    • 最初のスプリントと初期設定の準備にいくつかの繰り返しを使用します。

      • 開発環境。
      • 開発プロセス。
      • テスト環境。
      • デプロイメントプロセス(設定管理を含む)。
    • 複数の負荷テストを計画します。

    • スプリント中にテストと最適化が行われるように計画します。

    • 安定化と最適化のフェーズを計画します。

    • できるだけ早く実稼働環境にデプロイします(運用チームがシステムをセットアップして経験を積めるようにします)。

    • 指定されたユーザーと定義済みのロールをできるだけ早く使用します。

    • トレーニング(管理者向けトレーニングなど)を計画します。

    • 運営への引き継ぎを計画します。

  • コンテンツ

    • 基本アーキテクチャの概要は次のとおりです。

      • コンテンツ階層を稼働させます。
      • コンテンツの概念の定義に役立ちます。
      • MSM の使用方法とレイアウトを定義します。
      • 役割、グループ、ワークフロー、権限を定義します。
    • オフラインページの作成が有益かどうかを検討します。

    • 初期ページとコンテンツの早期作成を計画します(テストとフィードバックで使用するため)。

    • 既存のコンテンツの移行を計画します。

    • リファクタリングの後で「スプリント中の移行」を計画します。

    • 「コンテンツのバーンダウン」(実稼動コンテンツ用のサイトマップ)を計画します。

時間と労力の見積もり estimating-time-and-effort

結果のタスクリストに応じて、(上位レベルの)タスク定義に対する時間と労力の初期見積もりを作成できます。この見積もりには、誰(顧客またはパートナー)がいつ、何を行うかを示す指標が含まれています。

次のリストは、関連する作業の標準的な概算と相互関係、つまりコストを示しています。

CAUTION
これらの数値は、初期見積もりにのみ使用できます。経験豊富な AEM 開発者が、詳細な分析を行う必要があります。
フェーズ
労力
開発
すべての開発要件をカバーする各コンポーネントノードの概算時間は 2~4 時間です。
開発者テスト
開発の 15%
フォローアップ
開発の 10%
ドキュメント化
開発の 15%
JavaDoc ドキュメント
開発の 10%
バグ修正
開発の 15%
プロジェクト管理
進行中のプロジェクトの管理と統制に要するプロジェクトコストの 20%

詳細な計画を行うと、使用可能なリソースまたは必要なリソースを期限やコストに関連付けることができます。

参照アーキテクチャ reference-architecture

参照アーキテクチャの目的は、AEM アーキテクチャにテンプレートソリューションを提供することです。参照アーキテクチャを使用すると、拡張、信頼性、セキュリティなどの、大規模法人システムで一般的に発生する問題に対処できます。

次のサイト指標を定義する必要があります。

分類
定義
インターネットサイトの数
イントラネットサイトの数
コードベースの数(インターネットとイントラネットが異なる場合など)
個々のページの数
1 日あたりのサイト訪問の数
1 日あたりのページビューの数
1 日あたりのデータ転送量(GB)
同時ユーザーの数(閉じられたユーザーグループ)
同時訪問者の数(公開)
同時作成者の数
登録済み作成者の数
営業日あたりのページアクティベーションの数
デプロイ時のページアクティベーションの数

使用可能なツールの概要 overview-of-potential-tools

次のリストは、使用可能なツールを示しています。このリストはあくまでもツールの紹介を目的としており、広範なレコメンデーションリストではなく、その他の任意のツールが使用できないわけではありません。

製品
説明
AEM

AEM は、アプリケーションの監視、テスト、調査、デバッグに役立つ、次のような様々なメカニズムを備えています。

Selenium
Selenium は、オープンソースのテストツールです。テストはブラウザーで直接実行され、ユーザーの作業をエミュレートします。
Microsoft® Project
一般的に使用されるプロジェクト管理ツール。
Jira
Jira は、ソフトウェアのバグを詳細にトラッキングし、管理するためオープンソースツールです。必要に応じて、バグの詳細にワークフローを組み込むこともできます。
Git
Git は、リビジョン管理ソフトウェアです。
Eclipse

Eclipse は、様々なプロジェクトで構成されるオープンソース IDE です。ライフサイクルに沿ってソフトウェアを構築、デプロイ、管理するための拡張可能なフレームワーク、ツール、ランタイムで構成されるオープン開発プラットフォームの構築に重点を置いています。

詳しくは、Eclipse を使用して AEM プロジェクトを開発する方法を参照してください。

IntelliJ

包括的な機能を提供する、プロフェッショナル向けの(ライセンス費用が発生する)IDE です。

詳しくは、IntelliJ IDEA を使用して AEM プロジェクトを開発する方法を参照してください。

Maven
Maven は、プロジェクトの構築プロセス(ソフトウェアとドキュメント)を管理できるソフトウェアプロジェクトの管理ツールおよび総合ツールです。

参考情報 further-reading

また、次の各節では、特に注目すべき内容を取り上げています。

ベストプラクティス best-practices

アドビでは、以下のようなすべてのフェーズとオーディエンスに対して詳細なベストプラクティスを提供しています。

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2