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

CAUTION
AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

このページでは、 プロジェクトの管理 — ベストプラクティスチェックリスト.

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

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

AEM内の機能 features-within-aem

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

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

さらに、 リリースノート(AEMの様々なバージョンの場合 )。新機能がいつ追加されたかを確認します。

統合 integrations

AEMは、他のAdobe製品やサードパーティのサービスと統合できます。 統合により、さらなるパワーと機能を自由に利用できます。

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

移行またはアップグレードしますか? migrate-or-upgrade

主な考慮事項は、次のどちらにするかです。

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

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

  • 以下を使用: パッケージマネージャー すべてのコンテンツとアプリケーションコードを古いシステムから新しいシステムに書き出す。
  • アップグレード 古いシステムをインプレースで ほとんどの場合、これが推奨される選択です。

基本的な基本規則 basic-ground-rules

どのプロジェクトと同様に、できるだけ早くグラウンドルールを確立することが重要です。 次の機能が含まれます。

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

    これらは、明確に定義され、プロジェクトに関わるすべてのユーザーに知らせる必要があります。 さらに、次の項目をハイライトすることをお勧めします。

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

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

    できるだけ早く関係者を巻き込むことで、関係者になれるように促すことができます 関係者 このプロジェクトでは、成功への取り組みを増やしています。

    • 顧客側では、作成者が含まれます。作成者は、日々システムを使用する必要があります。
    • 独自のプロジェクトチーム内に、品質保証に責任を持つ担当者も含まれます。顧客の要件を理解するほど、テストの計画がより適切になります。
  • 通信のパス

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

    定義するプロセスは、個々のプロジェクトに応じて異なります。再度、以下を考慮して、これらのシンプルな設定を維持するようにしてください。

    • 任意のサードパーティとやり取りするためのプロセス(および通信のパス)の定義例:設計代理店やサードパーティのソフトウェアサプライヤーなど。
    • 多くの場合、顧客は独自のプロジェクト管理およびレポート作成の手順とツールを持ちます。
  • トラッキングツール

    バグ、タスク、およびプロジェクトのその他の側面に関する情報を追跡するために利用できるツールは多数あります。詳しくは、 使用可能なツールの概要 を参照してください。

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

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

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

    どの情報をどの形式、どの頻度、誰に報告するかを明確に定義します。

  • 用語

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

    • 行われる仮定を定義します。

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

  • 情報の定義と管理
  • 関係者全員に対して、情報が明確に伝達されます。標準的なプロジェクト管理の実践ですが、明確な役割の定義と良いコミュニケーションがプロジェクトを作り、壊すのに十分な頻度で繰り返すことはできません。
  • 追跡される情報は、1 つのバージョンのみ保持されます。例えば、バグトラッキング、問題トラッキングなどです。

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

組織は、主要業績評価指標 (KPI) を使用して、ターゲット到達時の成功を評価します。 これらの指標は測定可能な値で、具体的な目標がどの程度効果的に満たされているかを示すために使用できます。

次の指標があります。

  • ビジネス:

    • 主要なビジネス目標の測定に使用します。
    • ビジネスやシナリオに適した KPI を、その概要、測定方法、使用方法、使用者に関する明確な定義を含めて選択することが重要です。
  • パフォーマンス:

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

指標の中には、特定して定義したターゲット指標に基づくものもありますが、すべてではありません。

ターゲット指標 target-metrics

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

多くの指標を定義できますが、多くの場合、定義した指標はパフォーマンスと同時実行性の目標をカバーしています。 特に、数量化が困難な要因で、多くの場合、 感情的 評価:

  • 「私たちのサイトは 遅すぎる 今日」 — いつ 遅い 条件を満たす?

  • 「すべて」 歯止めをかける 同僚が「」にログインすると、システムは何人の同時ユーザーをサポートできますか。

  • 「私が探すとき、システムは 歯止めをかける " — どの種類の検索リクエストがシステムに影響を与えていますか?

  • 「要る 年齢 「」 — (通常のネットワーク条件下で)許容可能なダウンロード時間はどれくらいか。

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 comments* can be used to include response time information within the source of each page:

    </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
一般的に使用されるプロジェクト管理ツール。
ジラ
ジラ は、ソフトウェアバグの詳細を追跡し管理するためのオープンソースツールです。 必要に応じて、バグの詳細にワークフローを設定できます。
Git
Git は、リビジョン管理ソフトウェアです。
Eclipse

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

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

IntelliJ

幅広い機能を提供するプロフェッショナル(したがって、ライセンスコストが発生する可能性が高い) IDE。

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

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

参考情報 further-reading

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

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

Adobeは、すべてのフェーズとオーディエンスに対して、さらなるベストプラクティスを提供します。

recommendation-more-help
d284b6a8-dae4-4549-aa9e-2b09317eb02a