의 이 부분에서 AEM Headless 개발자 여정, headless 애플리케이션을 라이브로 배포하는 방법에 대해 알아봅니다.
AEM Headless 번역 여정의 이전 문서인 AEM Assets API를 통해 콘텐츠를 업데이트하는 방법에서 API를 통해 AEM의 기존 Headless 콘텐츠를 업데이트하는 방법에 대해 알아보았습니다. 여기에서 알게 된 내용은 다음과 같습니다.
이 문서는 이러한 기본 사항을 기본으로 하며, 이를 통해 자체 AEM Headless 프로젝트를 준비하여 실행하는 방법을 이해할 수 있습니다.
이 문서는 AEM Headless 게시 파이프라인을 이해하고 애플리케이션을 실행하기 전에 알아야 하는 성능을 고려하는 데 도움이 됩니다.
AEM SDK를 사용하여 사용자 정의 코드를 빌드하고 배포합니다. 시작하기 전에 Headless 애플리케이션을 개발하고 테스트해야 하는 주요 도구입니다. 다음 아티팩트가 포함되어 있습니다.
AEM SDK 외에도 로컬에서 코드 및 콘텐츠를 개발 및 테스트하는 데 도움이 되는 추가 도구가 필요합니다.
AEM은 Java™ 애플리케이션이므로 AEM as a Cloud Service 개발을 지원하려면 Java™ 및 Java™ SDK를 설치해야 합니다.
Git은 소스 제어를 관리하고 Cloud Manager의 변경 사항을 체크인한 다음 프로덕션 인스턴스에 배포하는 데 사용됩니다.
AEM은 Apache Maven을 사용하여 AEM Maven Project 원형에서 생성된 프로젝트를 빌드합니다. 모든 주요 IDE는 Maven에 대한 통합 지원을 제공합니다.
Node.js는 AEM 프로젝트의 프론트엔드 에셋으로 작업하는 데 사용되는 JavaScript 런타임 환경입니다. ui.frontend
하위 프로젝트. Node.js는 JavaScript 종속성을 관리하는 데 사용되는 npm(사실상 Node.js 패키지 관리자)과 함께 배포됩니다.
다음으로 AEM 환경의 구성 부분을 살펴보겠습니다.
전체 AEM 환경은 작성자, 게시와 Dispatcher로 구성됩니다. 라이브로 전환되기 전에 코드와 컨텐츠를 보다 쉽게 미리 볼 수 있도록 로컬 개발 런타임에서 동일한 구성 요소를 사용할 수 있습니다.
Author 서비스는 내부 사용자가 콘텐츠를 만들고 관리하고 미리 보는 곳입니다.
Publish 서비스 는 "라이브" 환경으로 간주되며 일반적으로 최종 사용자는 이 환경을 사용하여 상호 작용합니다. Author 서비스에서 편집 및 승인된 콘텐츠는 Publish 서비스로 배포(복제)됩니다. AEM Headless 애플리케이션의 가장 일반적인 배포 패턴은 애플리케이션의 프로덕션 버전을 AEM Publish 서비스에 연결하는 것입니다.
Dispatcher는 AEM Dispatcher 모듈로 보강된 정적 웹 서버입니다. 게시 인스턴스에서 생성된 웹 페이지를 캐시하여 성능을 개선합니다.
로컬 개발 프로젝트는 Apache Maven을 기반으로 빌드되어 소스 제어에 Git을 사용합니다. 프로젝트를 업데이트하려면 개발자는 Eclipse, Visual Studio Code 또는 IntelliJ 등 권장되는 통합 개발 환경을 사용할 수 있습니다.
Headless 애플리케이션에서 수집하는 코드 또는 콘텐츠 업데이트를 테스트하려면 로컬 AEM 런타임에 업데이트를 배포합니다. 여기에는 AEM 작성자 및 게시 서비스의 로컬 인스턴스가 포함됩니다.
가장 중요한 위치에서 업데이트를 테스트해야 하므로 로컬 AEM 런타임에서 각 구성 요소의 차이를 메모해 두십시오. 예를 들어 작성자의 콘텐츠 업데이트를 테스트하거나 게시 인스턴스의 새 코드를 테스트합니다.
프로덕션 시스템에서 Dispatcher 및 http Apache 서버는 항상 AEM 게시 인스턴스 앞에 있습니다. 캐싱 및 보안 서비스를 AEM 시스템에 제공하므로 Dispatcher에 대한 코드 및 콘텐츠 업데이트를 테스트해야 합니다.
AEM Headless 프로젝트를 시작하도록 준비하려면 프로젝트의 모든 구성 부분이 제대로 작동하는지 확인하십시오.
이를 위해서는 코드, 콘텐츠 및 구성과 같은 모든 것을 통합하고 Go-Live 준비를 위해 로컬 개발 환경에서 테스트해야 합니다.
로컬 개발 환경은 다음 세 가지 주요 영역으로 구성됩니다.
로컬 개발 환경이 설정되면 정적 노드 서버를 로컬로 배포하여 React 앱에 제공하는 콘텐츠를 시뮬레이션할 수 있습니다.
로컬 개발 환경 및 콘텐츠 미리 보기에 필요한 모든 종속성 설정에 대해 자세히 알아보려면 를 참조하십시오. 프로덕션 배포 설명서.
이제 아래에 요약된 모범 사례를 따라 AEM Headless 애플리케이션을 시작할 수 있도록 준비해야 합니다.
다음을 참조하십시오 추가 리소스 cdn 및 캐싱에 대한 자세한 내용은 을 참조하십시오.
Last-modified-since
리소스를 새로 고칩니다._reference
출력을 사용하여 전체 JSON 파일을 구문 분석하지 않고도 자산 다운로드를 시작합니다.프로덕션에 배포는 다음을 보유하고 있는지 여부에 따라 달라질 수 있습니다 기존 Maven을 사용하여 배포하거나 Adobe Managed Services(AMS)에 있으므로 Cloud Manager를 사용하는 AEM 인스턴스.
의 경우 기존 Maven을 사용한 배포(AMS 이외), WKND 자습서 개요를 참조하십시오.
Cloud Manager를 사용하는 AMS 고객의 경우 모든 것이 테스트되고 제대로 작동하는지 확인한 후 코드 업데이트를 Cloud Manager의 중앙 집중식 Git 저장소.
업데이트가 Cloud Manager에 업로드된 후 다음을 사용하여 AEM에 배포합니다. Cloud Manager의 CI/CD 파이프라인.
사용자가 AEM Headless 애플리케이션 사용 시 최상의 사용자 경험이 있으면 아래에 설명된 핵심 성능 지표를 모니터링해야 합니다.
다음 모범 사례에 따라 디버깅에 대한 일반적인 방식을 사용합니다.
지원이 더 필요한 경우 지원을 통해 버그를 효율적으로 기록하려면 다음 단계를 완료하십시오.
축하합니다! AEM Headless 개발자 번역 여정을 완료하셨습니다! 이제 다음 사항을 이해할 수 있어야 합니다.
첫 번째 AEM Headless 프로젝트를 이미 시작했거나 이제 모든 지식을 갖추고 있습니다. 좋습니다!
그러나 AEM에서 헤드리스 매장을 중단할 필요는 없습니다. 다음에서 여정의 시작 부분에서는 AEM이 headless 전달 및 기존 전체 스택 모델을 지원하는 방법뿐만 아니라 두 가지 모두의 장점을 결합한 하이브리드 모델을 지원하는 방법에 대해 논의했습니다.
이러한 유연성이 프로젝트에 필요한 사항인 경우 여정의 선택적 추가 부분으로 계속 진행하십시오. AEM으로 단일 페이지 애플리케이션(SPA)을 만드는 방법
CDN 캐시