프론트엔드 파이프라인으로 Sites 개발 developing-site-with-front-end-pipeline

Last update: Tue Mar 04 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

주제:
개발

작성 대상:

관리자
개발자

프론트엔드 파이프라인을 통해 프론트엔드 개발자의 독립성을 높이고 개발 속도를 크게 높일 수 있습니다. 이 문서에서는 프로세스의 작동 방식을 설명하고 프로세스를 최대한 활용할 수 있는 주요 고려 사항을 소개합니다.

TIP

프론트엔드 파이프라인 사용 방법 및 이점을 아직 잘 모르는 경우 빠른 사이트 생성 여정 안내서를 참조하십시오. 새 사이트를 빠르게 배포하고 백엔드 개발과 독립적으로 테마를 맞춤화하는 방법에 대한 예를 제공합니다.

AEM Cloud Manager의 프론트엔드 파이프라인 설정 및 빌드 프로세스 이해 front-end-build-contract

전체 스택 빌드 환경과 마찬가지로 프론트엔드 파이프라인에도 고유한 환경이 있습니다. 개발자는 프론트엔드 빌드 계약을 따르는 경우 이 파이프라인을 유연하게 사용할 수 있습니다.

프론트엔드 파이프라인을 사용하려면 프론트엔드 Node.js 프로젝트가 build 스크립트 지시문을 사용하여 배포하는 빌드를 생성해야 합니다. Cloud Manager에서 npm run build 명령을 사용하여 프론트엔드 빌드에 대한 배포 가능한 프로젝트를 생성하기 때문에 이 요구 사항이 존재합니다.

dist 폴더의 결과 콘텐츠는 Cloud Manager이 최종적으로 배포하여 정적 파일로 제공합니다. 이러한 파일은 AEM 외부에서 호스팅되지만 배포된 환경에서 /content/... URL을 통해 사용할 수 있습니다.

지원되는 Node.js 버전 node-versions

프론트엔드 빌드 환경은 다음 Node.js 버전을 지원합니다.

18
16
14(기본값)
12

NODE_VERSION 환경 변수를 사용하여 원하는 버전을 설정할 수 있습니다.

AEM에서 프론트엔드 파이프라인 이름 지정 및 관리에 대한 우수 사례 single-source-of-truth

AEM 배포의 모범 사례는 신뢰할 수 있는 단일 소스를 유지 관리하는 것입니다. Cloud Manager은 이러한 원칙을 강화하기 위해 고안되었습니다. 그러나 프론트엔드 파이프라인을 사용하면 코드의 일부를 분리할 수 있으므로 적절한 설정이 필수적입니다. 충돌을 방지하려면 여러 프론트엔드 파이프라인이 동일한 환경 내의 동일한 사이트에 배포되지 않도록 하십시오.

이러한 이유, 특히 여러 프론트엔드 파이프라인이 만들어지는 경우 Adobe에서는 체계적인 명명 규칙을 유지하는 것이 좋습니다. 다음 권장 사항을 사용할 수 있습니다.

package.json 파일의 name 속성으로 정의된 프런트 엔드 모듈 이름에는 이 파일이 적용되는 사이트의 이름이 포함되어야 합니다. 예를 들어, /content/wknd에 있는 사이트의 경우 프런트 엔드 모듈의 이름은 wknd-theme과(와) 같습니다.
프론트엔드 모듈이 동일한 Git 저장소를 다른 모듈과 공유하는 경우, 해당 폴더의 이름은 프론트엔드 모듈과 동일하거나 동일한 이름을 포함해야 합니다. 예를 들어, 프론트엔드 모듈의 이름이 wknd-theme인 경우 바깥쪽 폴더 이름은 wknd-theme-sources과(와) 같습니다.
Cloud Manager 프론트엔드 파이프라인의 이름에는 프론트엔드 모듈의 이름도 포함되어야 하며 배포(프로덕션 또는 개발)할 환경도 추가해야 합니다. 예를 들어, 이름이 wknd-theme인 프론트엔드 모듈의 경우 파이프라인의 이름을 wknd-theme-prod과(와) 같이 지정할 수 있습니다.

이러한 규칙은 다음과 같은 배포 실수를 방지합니다.

프론트엔드 모듈을 잘못된 사이트에 적용.
동일한 사이트를 적용하는 여러 프론트엔드 모듈을 만들어 서로 덮어씁니다.
동일한 소스에 대해 여러 프론트엔드 파이프라인을 만들기 때문에 경쟁 조건이 발생할 수 있으며 배포 순서를 보장할 수 없습니다.

AEM의 안정성을 위한 프론트엔드 및 백엔드 개발 조정 separation-of-concerns

문제 분리에 대한 핵심 모범 사례는 계약 간의 경계를 정의하는 계약을 신중하게 디자인하고 관리하는 것입니다. 프론트엔드 파이프라인에서 이 계약은 사이트에서 렌더링한 HTML 및 JSON 출력입니다. 이 출력의 안정성을 유지하면 프론트엔드 파이프라인이 최대 가치를 제공하여 프론트엔드 팀이 독립적으로 작업할 수 있습니다.

현재 프론트엔드 파이프라인과 동기적으로 전체 스택 파이프라인을 실행하는 내장 기능은 없습니다. 따라서 프론트엔드 개발을 전체 스택 파이프라인과 분리할 때는 경계를 정의하는 계약을 신중하게 관리하는 것이 중요합니다. 이 계약은 일반적으로 Experience Manager에서 렌더링한 HTML, JSON 또는 둘 다로 구성됩니다. 이 계약에 대한 모든 변경 사항은 원활한 전환과 적절한 업데이트 순서를 보장하기 위해 서로 다른 파이프라인을 관리하는 팀 간에 신중하게 조정되어야 합니다.

HTML 또는 JSON 출력을 변경할 때, 특히 두 영역이 모두 영향을 받는 경우에는 일반적으로 다음 단계를 권장합니다.

백엔드 팀은 먼저 새로운 HTML 또는 JSON 출력으로 개발 환경을 설정합니다.
1. 전체 스택 파이프라인을 통해 필요한 새 HTML 또는 JSON 출력 또는 두 가지 모두를 렌더링하는 데 필요한 코드를 배포합니다.
2. 프론트엔드 팀이 이전에 액세스할 수 없었던 환경에 대한 작업인 경우 다음 단계를 수행해야 합니다.
  1. URL: 프론트엔드 팀은 해당 개발 환경의 URL을 알고 있어야 합니다.
  2. ACL: 프론트엔드 팀에게는 "기여자" 권한과 유사한 권한이 있는 로컬 AEM 사용자가 제공되어야 합니다.
  3. Git: 프론트엔드 팀에는 해당 개발 환경을 특별히 타겟팅하는 프론트엔드 모듈에 대한 별도의 Git 위치가 있어야 합니다.
    
    일반적인 방법은 dev 분기를 만들어 개발 환경에서 변경한 내용을 관리하는 것입니다. 이 방법을 사용하면 프로덕션 환경에 배포하는 데 사용되는 main 분기로 다시 쉽게 병합할 수 있습니다.
  4. 파이프라인: 프론트엔드 팀에는 개발 환경에 배포하는 프론트엔드 파이프라인이 있어야 합니다. 해당 파이프라인은 이전 부분에서 설명한 대로 일반적으로 dev 분기에 있는 프론트엔드 모듈을 배포합니다.
그러면 프론트엔드 팀은 CSS 및 JS 코드가 이전 출력과 새 출력 모두에서 작동하도록 합니다.
1. 평소대로 로컬에서 개발하려면 다음을 수행합니다.
  1. npx aem-site-theme-builder proxy 명령은 AEM 환경에서 콘텐츠를 검색하는 프록시 서버를 시작합니다. 프론트엔드 모듈의 CSS 및 JS 파일을 로컬 dist 폴더의 파일로 대체합니다.
  2. 숨겨진 .env 파일에서 AEM_URL 변수를 구성하면 로컬 프록시 서버에서 콘텐츠를 사용하는 AEM 환경을 제어할 수 있습니다.
  3. 따라서 AEM_URL의 값을 변경하면 프로덕션 환경과 개발 환경 간을 전환하여 두 환경에 모두 맞도록 CSS와 JS를 조정할 수 있습니다.
  4. 새 출력을 렌더링하는 개발 환경과 이전 출력을 렌더링하는 프로덕션 환경에서 작업해야 합니다.
2. 업데이트된 프론트엔드 모듈이 두 환경 모두에서 작동하고 두 환경에 배포되면 프론트엔드 작업이 완료됩니다.
그러면 백엔드 팀은 전체 스택 파이프라인을 통해 새 HTML 또는 JSON 출력 또는 두 가지 모두를 렌더링하는 코드를 배포하여 프로덕션 환경을 업데이트할 수 있습니다.
프론트엔드 팀은 프론트엔드 파이프라인을 사용하여 CSS 및 JS를 정리하고, 이전 출력에만 필요한 요소를 제거하며, 프로덕션에 최종 업데이트를 배포할 수 있습니다.

추가 리소스 additional-resources

AEM 사이트 테마를 사용하여 사이트의 스타일 및 디자인을 맞춤화하는 방법에 대해 알아봅니다.

사이트 테마를 참조하세요.
Adobe는 새 사이트 테마를 만들기 위한 스크립트 세트로 AEM 사이트 테마 빌더를 제공합니다.

AEM 사이트 테마 빌더 보기

recommendation-more-help

fbcff2a9-b6fe-4574-b04a-21e75df764ab