프론트엔드 파이프라인으로 Sites 개발 developing-site-with-front-end-pipeline
프론트엔드 파이프라인을 사용하면 프론트엔드 개발자에게 더 많은 독립성이 부여되며 개발 프로세스가 상당한 속도를 낼 수 있습니다. 이 문서에서는 이 프로세스의 잠재력을 최대한 활용할 수 있도록 몇 가지 고려 사항과 함께 이 프로세스가 작동하는 방식을 설명합니다.
프론트엔드 빌드 계약 front-end-build-contract
와 유사 전체 스택 빌드 환경, 프론트엔드 파이프라인에는 자체 환경이 있습니다. 개발자는 다음 프론트엔드 빌드 계약이 준수되는 한 이 파이프라인을 유연하게 사용할 수 있습니다.
프론트엔드 파이프라인을 사용하려면 프론트엔드 Node.js 프로젝트가 build 배포되는 빌드를 생성하는 스크립트 지시문입니다. 이는 Cloud Manager가 명령을 사용하기 때문입니다 npm run build 프론트엔드 빌드에 대해 배포 가능한 프로젝트를 생성하려면 다음을 수행하십시오.
의 결과 콘텐츠 dist 폴더는 정적 파일로 제공하는 Cloud Manager에서 최종적으로 배포하는 것입니다. 이러한 파일은 AEM 외부에서 호스팅되지만 /content/... 배포된 환경의 URL.
노드 버전 node-versions
프론트엔드 빌드 환경은 다음 Node.js 버전을 지원합니다.
- 12
- 14(기본값)
- 16
- 18
다음을 사용할 수 있습니다. NODE_VERSION 환경 변수 원하는 버전을 설정합니다.
단일 진실 소스 single-source-of-truth
일반적으로 좋은 방법은 AEM에 배포된 내용에 대한 단일 소스 진실을 유지하는 것입니다. Cloud Manager의 목표는 해당 단일 소스 정보를 명확하게 만드는 것입니다. 그러나 프론트엔드 파이프라인을 통해 코드 일부의 위치를 분리할 수 있으므로, 몇 가지 추가 권한은 프론트엔드 파이프라인의 올바른 설정에 있습니다. 동일한 환경의 동일한 사이트에 배포되는 여러 프론트엔드 파이프라인을 만들지 않도록 주의해야 합니다.
이러한 이유, 특히 여러 프론트엔드 파이프라인이 만들어지는 경우 다음과 같은 체계적인 명명 규칙을 유지하는 것이 좋습니다.
- 프론트엔드 모듈의 이름으로,
name의 속성package.json에 적용되는 사이트의 이름이 포함되어야 합니다. 예를 들어 다음 위치에 있는 사이트의 경우/content/wknd를 설정하는 경우 프론트엔드 모듈의 이름은wknd-theme. - 프론트엔드 모듈이 동일한 Git 저장소를 다른 모듈과 공유하는 경우, 해당 폴더의 이름은 프론트엔드 모듈과 동일하거나 동일한 이름을 포함해야 합니다. 예를 들어 프론트엔드 모듈의 이름이 인 경우
wknd-theme, 바깥쪽 폴더 이름은wknd-theme-sources. - Cloud Manager 프론트엔드 파이프라인의 이름에는 프론트엔드 모듈의 이름도 포함되어야 하며 배포(프로덕션 또는 개발)되는 환경도 추가해야 합니다. 예를 들어 이라는 프론트엔드 모듈의 경우
wknd-theme, 파이프라인의 이름을 다음과 같이 지정할 수 있습니다.wknd-theme-prod.
이러한 규칙은 다음 배포 오류를 효율적으로 방지해야 합니다.
- 프론트엔드 모듈을 잘못된 사이트에 적용
- 동일한 사이트를 적용하는 여러 프론트엔드 모듈을 만들어 서로 덮어쓰기
- 동일한 소스에 대해 여러 프론트엔드 파이프라인을 만들기 때문에 경쟁 조건이 발생할 수 있으며 배포 순서를 보장할 수 없습니다.
문제 분리 separation-of-concerns
어떠한 우려의 분리에도 적용되는 또 다른 좋은 관행은 우려를 분리하는 계약이 어떻게 설계되고 관리되는지에 특별한 주의를 기울이는 것이다. 프론트엔드 파이프라인의 경우, 해당 코드를 나머지 코드와 분리하는 계약은 사이트에서 렌더링한 HTML 및 JSON입니다. 해당 HTML과 JSON이 안정적으로 유지되는 경우 프론트엔드 파이프라인은 프론트엔드 팀을 완전히 독립적으로 만들어 최대 가치를 제공합니다.
현재 프론트엔드 파이프라인과 동기적으로 전체 스택 파이프라인을 실행하는 특정 기능은 없습니다. 이러한 이유로 프론트엔드 개발을 전체 스택 파이프라인과 분리할 때 이러한 두 가지 우려 영역을 분리하는 계약에 추가 주의가 필요합니다. 일반적으로 해당 계약은 Experience Manager이 렌더링하는 HTML 및/또는 JSON입니다. 따라서 해당 계약에 대한 변경 사항은 해당 변경 사항의 순서를 지정하는 방법에 동의할 수 있도록 다양한 파이프라인을 운영하는 팀 간에 잘 계획되어야 합니다.
일반적으로 두 가지 우려 영역에 모두 영향을 주는 HTML 및/또는 JSON 출력을 변경해야 할 때 다음 단계를 권장합니다.
-
백엔드 팀은 먼저 새 HTML 및/또는 JSON 출력으로 개발 환경을 설정합니다.
-
전체 스택 파이프라인을 통해 원하는 새 HTML 및/또는 JSON 출력을 렌더링하는 데 필요한 코드를 배포합니다.
-
프론트엔드 팀이 이전에 액세스할 수 없었던 환경의 경우 다음 단계를 수행해야 합니다.
- URL: 프론트엔드 팀은 해당 개발 환경의 URL을 알고 있어야 합니다.
- ACL: 프론트엔드 팀에는 "기여자" 권한과 유사한 권한이 있는 로컬 AEM 사용자가 있어야 합니다.
- Git: 프론트엔드 팀에는 해당 개발 환경을 특별히 타겟팅하는 프론트엔드 모듈에 대한 별도의 Git 위치가 있어야 합니다.
- 일반적인 방법은 를 만드는 것입니다.
dev분기 - 개발 환경에 대해 수행된 변경 내용을 쉽게 다시 병합할 수 있습니다.main프로덕션 환경에 배포할 분기입니다.
- 일반적인 방법은 를 만드는 것입니다.
- 파이프라인: 프론트엔드 팀에는 개발 환경에 배포하는 프론트엔드 파이프라인이 있어야 합니다. 해당 파이프라인은 일반적으로
dev앞에서 설명한 대로 분기.
-
-
그러면 프론트엔드 팀은 CSS 및 JS 코드가 이전 출력과 새 출력 모두에서 작동하도록 합니다.
-
평소대로, 로컬에서 개발하기 위해:
- 다음
npx aem-site-theme-builder proxy프론트엔드 모듈 내에서 실행된 명령은 프론트엔드 모듈의 CSS 및 JS 파일을 로컬의 CSS 및 JS 파일로 대체하면서 AEM 환경에서 콘텐츠를 요청하는 프록시 서버를 시작합니다dist폴더를 삭제합니다. - 구성
AEM_URL숨겨진 변수의 변수.env파일을 사용하면 로컬 프록시 서버가 콘텐츠를 사용하는 AEM 환경을 제어할 수 있습니다. - 값 변경
AEM_URL따라서 프로덕션 환경과 개발 환경 간을 전환하여 두 환경에 모두 적합하도록 CSS와 JS를 조정할 수 있습니다. - 새 출력을 렌더링하는 개발 환경과 이전 출력을 렌더링하는 프로덕션 환경에서 작업해야 합니다.
- 다음
-
업데이트된 프론트엔드 모듈이 두 환경 모두에서 작동하고 두 환경에 배포되면 프론트엔드 작업이 완료됩니다.
-
-
그러면 백엔드 팀은 전체 스택 파이프라인을 통해 새 HTML 및/또는 JSON 출력을 렌더링하는 코드를 배포하여 프로덕션 환경을 업데이트할 수 있습니다.
-
그러면 프론트엔드 팀은 CSS와 JS를 정리하고 이전 출력에서만 필요했던 것을 제거하여 프론트엔드 파이프라인을 통해 프로덕션에 마지막 업데이트를 배포할 수 있습니다.
추가 리소스 additional-resources
- 사이트 테마 - AEM 사이트 테마를 사용하여 사이트의 스타일 및 디자인을 맞춤화하는 방법에 대해 알아봅니다.
- AEM 사이트 테마 빌더 - Adobe은 새 사이트 테마를 만들기 위한 스크립트 세트로 AEM 사이트 테마 빌더를 제공합니다.