코드 및 사용자 지정 업그레이드 upgrading-code-and-customizations

업그레이드를 계획할 때 구현의 다음 영역을 조사하고 해결해야 합니다.

개요 overview

업그레이드를 진행하기 전에 AEM의 대상 버전에 대해 철저하게 테스트한 안정적인 애플리케이션 코드 베이스가 있어야 합니다. 테스트의 관찰을 기반으로 사용자 지정 코드를 최적화하는 방법이 있을 수 있습니다. 여기에는 저장소 탐지를 방지하기 위해 코드 리팩터링, 검색을 최적화하기 위한 사용자 지정 색인 지정 또는 JCR에서 순서가 없는 노드를 사용하는 작업이 포함될 수 있습니다.

6.4는 새로운 AEM 버전에서 작동하도록 코드 베이스와 사용자 지정을 업그레이드하는 옵션 외에도 다음과 같이 이전 버전과의 호환성 기능을 사용하여 사용자 지정을 보다 효율적으로 관리하는 데 도움이 됩니다 이 페이지.

위에서 언급했듯이 아래 다이어그램에 표시된 대로 패턴 탐지기 첫 번째 단계에서는 업그레이드의 전반적인 복잡성을 평가하고 호환성 모드에서 실행할지 또는 새로운 AEM 6.4 기능을 모두 사용하도록 사용자 지정을 업데이트할지 여부를 평가하는 데 도움이 됩니다. 자세한 내용은 AEM 6.4의 이전 버전과의 호환성 페이지를 참조하십시오.

코드 기본 업그레이드 upgrade-code-base

버전 제어에서 6.4 코드용 전용 분기 만들기 create-a-dedicated-branch-for-6-4-code-in-version-control

AEM 구현에 필요한 모든 코드와 구성은 일부 버전의 제어를 사용하여 관리해야 합니다. AEM의 대상 버전에서 코드 베이스에 필요한 변경 사항을 관리하기 위해 버전 제어의 전용 분기를 만들어야 합니다. AEM의 Target 버전에 대해 코드 베이스에 대한 반복적인 테스트 및 후속 버그 수정은 이 분기에서 관리됩니다.

AEM Uber Jar 버전 업데이트 update-the-aem-uber-jar-version

AEM Uber jar에는 Maven 프로젝트의 단일 종속으로 모든 AEM API가 포함됩니다 pom.xml. 개별 AEM API 종속성을 포함하지 않고 항상 Uber Jar를 단일 종속으로 포함하는 것이 좋습니다. 코드를 업그레이드할 때 Uber Jar 버전을 AEM의 대상 버전을 가리키도록 변경해야 합니다. 프로젝트가 Uber Jar가 존재하기 전에 AEM 버전에서 개발된 경우 모든 개별 AEM API 종속성은 제거하고 AEM의 대상 버전에 대한 Uber Jar의 단일 포함으로 대체해야 합니다. 그런 다음 새 버전의 Uber Jar에 대해 코드 베이스를 다시 컴파일해야 합니다. 더 이상 사용되지 않는 모든 API 또는 메서드는 AEM의 target 버전과 호환되도록 업데이트해야 합니다.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

관리 리소스 확인자의 단계 사용 중단 phase-out-use-of-administrative-resource-resolver

를 통해 관리 세션 사용 SlingRepository.loginAdministrative() 및 ResourceResolverFactory.getAdministrativeResourceResolver() 는 AEM 6.0 이전의 코드 베이스에서 매우 일반적이었습니다. 이러한 메서드는 너무 광범위한 액세스 수준을 제공하므로 보안상의 이유로 더 이상 사용되지 않습니다. 향후 버전의 Sling에서는 이러한 메서드가 제거됩니다. 대신 서비스 사용자를 사용하도록 모든 코드를 리팩터링하는 것이 좋습니다. 서비스 사용자에 대한 자세한 정보 및 관리 세션을 단계적으로 종료하는 방법은 여기에서 찾을 수 있습니다..

쿼리 및 Oak 색인 queries-and-oak-indexes

코드 베이스를 업그레이드하는 과정의 일부로 코드 베이스에서 쿼리 사용을 철저히 테스트해야 합니다. Jackrabbit 2(6.0 이전 버전의 AEM)에서 업그레이드하는 고객의 경우 Oak가 컨텐츠를 자동으로 색인화하지 않으며 사용자 지정 인덱스를 만들어야 하므로 특히 중요합니다. AEM 6.x 버전에서 업그레이드하는 경우 Oak 색인 정의가 변경되었으며 기존 쿼리에 영향을 줄 수 있습니다.

쿼리 성능을 분석 및 검사하는 몇 가지 도구를 사용할 수 있습니다.

클래식 UI 작성 classic-ui-authoring

클래식 UI 작성은 AEM 6.4에서 계속 사용할 수 있지만 더 이상 사용되지 않습니다. 자세한 내용 여기. 애플리케이션이 현재 클래식 UI 작성 환경에서 실행 중인 경우 AEM 6.4로 업그레이드하고 클래식 UI를 계속 사용하는 것이 좋습니다. 그런 다음 터치 UI로의 마이그레이션을 여러 개발 주기에 걸쳐 완료할 수 있도록 별도의 프로젝트로 계획할 수 있습니다. AEM 6.4에서 클래식 UI를 사용하려면 코드 베이스에 몇 가지 OSGi 구성을 커밋해야 합니다. 구성 방법에 대한 자세한 내용은 다음을 참조하십시오 여기.

6.4 저장소 구조와 정렬 align-repository-structure

업그레이드를 보다 쉽게 하고 업그레이드 중에 구성을 덮어쓰지 않도록 하기 위해 리포지토리는 6.4에서 재구성되어 구성에서 컨텐츠를 분리합니다.

따라서 더 이상 다음 위치에 있지 않도록 많은 설정을 이동해야 합니다 /etc 과거에 그랬던 것처럼. 업데이트된 AEM 6.4로 검토 및 수용해야 하는 전체 저장소 구조 변경 문제를 검토하려면 다음을 참조하십시오 AEM 6.4의 저장소 구조 변경.

AEM 사용자 지정 aem-customizations

AEM 소스 버전의 AEM 작성 환경에 대한 모든 사용자 지정을 식별해야 합니다. 식별되면 각 사용자 지정을 버전 제어에 저장하거나 컨텐츠 패키지의 일부로 백업되는 최소 상태로 저장하는 것이 좋습니다. 모든 사용자 지정 사항은 프로덕션 업그레이드 전에 AEM의 대상 버전을 실행하는 QA 또는 스테이징 환경에서 배포하고 검증해야 합니다.

일반적으로 오버레이 overlays-in-general

/apps 아래의 추가 노드와 함께 /libs 아래에 노드 및/또는 파일을 오버레이하여 기본 제공 AEM 기능을 확장하는 것이 일반적입니다. 이러한 오버레이는 버전 제어에서 추적되고 AEM의 대상 버전에 대해 테스트해야 합니다. 파일(JS, JSP, HTL 등)을 오버레이하는 경우 AEM의 대상 버전에서 보다 쉽게 회귀 테스트를 위해 보강된 기능에 대한 주석을 추가하는 것이 좋습니다. 일반적으로 오버레이에 대한 자세한 내용은 여기. 특정 AEM 오버레이에 대한 지침은 아래에 나와 있습니다.

사용자 지정 검색 Forms 업그레이드 upgrading-custom-search-forms

사용자 정의 검색 패싯이 제대로 작동하려면 업그레이드 후 몇 가지 수동 조정이 필요합니다. 자세한 내용은 사용자 지정 검색 Forms 업그레이드.

자산 UI 사용자 지정 assets-ui-customizations

사용자 지정된 자산 배포를 가진 인스턴스를 업그레이드를 준비해야 합니다. 사용자 지정된 모든 컨텐츠가 새 6.4 노드 구조와 호환되도록 하는 데 필요합니다.

다음을 수행하여 자산 UI에 대한 사용자 지정을 준비할 수 있습니다.

기존 자산에 대한 자산 ID 생성 generating-asset-ids-for-existing-assets

기존 자산에 대한 자산 ID를 생성하려면 AEM 인스턴스를 업그레이드하여 AEM 6.4를 실행합니다. 이 ID를 사용하려면 자산 통찰력 기능. 자세한 내용은 포함 코드 추가.

자산을 업그레이드하려면 JMX 콘솔에서 자산 ID 연결 패키지를 구성합니다. 저장소의 자산 수에 따라, migrateAllAssets 시간이 오래 걸릴 수 있습니다 TarMK의 125,000여 자산에 대해 내부 테스트를 한 시간은 약 1시간입니다.

전체 자산의 하위 세트에 대해 자산 ID가 필요한 경우, migrateAssetsAtPath API.

다른 모든 목적으로 migrateAllAssets() API.

InDesign 스크립트 사용자 지정 indesign-script-customizations

Adobe은 사용자 지정 스크립트를 /apps/settings/dam/indesign/scripts 위치. InDesign 스크립트 사용자 지정에 대한 자세한 내용을 찾을 수 있습니다 여기.

ContextHub 구성 복구 recovering-contexthub-configurations

ContextHub 구성은 업그레이드에 의해 적용됩니다. 기존 ContextHub 구성 복구 방법에 대한 지침을 찾을 수 있습니다 여기.

워크플로우 사용자 지정 workflow-customizations

필요한 기능을 추가하거나 제거하기 위해 즉시 수정 워크플로우를 업데이트하는 것이 일반적인 방법입니다. 사용자 지정된 일반적인 워크플로우는 DAM 자산 업데이트 워크플로우입니다. 사용자 지정 구현에 필요한 모든 워크플로우는 업그레이드 중에 덮어쓸 수 있으므로 백업 및 버전 제어에 저장해야 합니다.

편집 가능한 템플릿 editable-templates

편집 가능한 템플릿의 구조가 AEM 6.2와 6.3 간에 변경되었습니다. 6.2 또는 이전 버전에서 업그레이드하는 경우 및 사이트 컨텐츠가 편집 가능한 템플릿을 사용하여 빌드되는 경우 를 사용해야 합니다 응답형 노드 정리 도구. 이 도구는 after 컨텐츠를 정리하기 위한 업그레이드. 작성 계층과 게시 계층 모두에서 실행해야 합니다.

CUG 구현 변경 cug-implementation-changes

닫힌 사용자 그룹 구현이 이전 버전의 AEM의 성능 및 확장성 제한을 해결하기 위해 크게 변경되었습니다. 이전 버전의 CUG는 6.3에서 더 이상 사용되지 않으며, 새 구현은 Touch UI에서만 지원됩니다. 6.2 이상에서 업그레이드하는 경우 새 CUG 구현으로 마이그레이션하기 위한 지침을 찾을 수 있습니다 여기.

테스트 절차 testing-procedure

업그레이드 테스트 등을 위한 종합적인 테스트 계획을 세워야 한다. 업그레이드된 코드 베이스와 애플리케이션을 먼저 낮은 환경에서 테스트해야 합니다. 발견된 모든 버그는 코드 베이스가 안정될 때까지 반복적으로 수정해야 하며, 높은 수준의 환경만 업그레이드해야 합니다.

업그레이드 프로시저 테스트 testing-the-upgrade-procedure

여기에 설명된 대로 업그레이드 절차는 사용자 지정된 실행 문서에 설명된 대로 개발 및 QA 환경에서 테스트되어야 합니다( 참조) 업그레이드 계획). 업그레이드 실행 장부에 모든 단계가 기록되고 업그레이드 프로세스가 매끄럽게 수행될 때까지 업그레이드 절차를 반복해야 합니다.

구현 테스트 영역 implementation-test-areas-

다음은 환경이 업그레이드되고 업그레이드된 코드 베이스가 배포되면 테스트 계획에서 적용해야 하는 AEM 구현의 중요한 영역입니다.

문서 테스트 계획 및 결과 document-test-plan-and-results

위의 구현 테스트 영역을 포함하는 테스트 계획을 만들어야 합니다. 대부분의 경우 작성 및 게시 작업 목록별로 테스트 계획을 구분하는 것이 적절합니다. 이 테스트 계획은 프로덕션 환경을 업그레이드하기 전에 개발, QA 및 스테이지 환경에서 실행해야 합니다. 스테이지 및 프로덕션 환경을 업그레이드할 때 비교할 수 있도록 테스트 결과 및 성능 지표를 낮은 환경에서 캡처해야 합니다.