프론트엔드 파이프라인으로 Sites 개발 developing-site-with-front-end-pipeline
프론트엔드 파이프라인을 사용하면 프론트엔드 개발자에게 더 많은 독립성이 주어지고 개발 프로세스가 상당한 속도를 얻을 수 있습니다. 이 문서에서는 이 프로세스의 잠재력을 최대한 활용할 수 있도록 몇 가지 고려 사항과 함께 이 프로세스가 작동하는 방식을 설명합니다.
프론트엔드 빌드 계약 front-end-build-contract
전체 스택 빌드 환경과 마찬가지로 프론트엔드 파이프라인에도 고유한 환경이 있습니다. 개발자는 다음 프론트엔드 빌드 계약이 준수되는 한 이 파이프라인을 유연하게 사용할 수 있습니다.
프론트엔드 파이프라인을 사용하려면 프론트엔드 Node.js 프로젝트가 build script 지시문을 사용하여 배포하는 빌드를 생성해야 합니다. 이는 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 single-source-of-truth
일반적으로 좋은 방법은 AEM에 배포된 내용에 대한 단일 소스 진실을 유지하는 것입니다. Cloud Manager의 목적은 진실의 단일 출처를 명확하게 만드는 것입니다. 그러나 프론트엔드 파이프라인을 통해 코드 일부의 위치를 분리할 수 있으므로, 몇 가지 추가 권한은 프론트엔드 파이프라인의 올바른 설정에 있습니다. 동일한 환경의 동일한 사이트에 배포되는 여러 프론트엔드 파이프라인을 만들지 않도록 주의해야 합니다.
이러한 이유, 특히 여러 프론트엔드 파이프라인이 만들어지는 경우 다음과 같은 체계적인 명명 규칙을 유지하는 것이 좋습니다.
package.json파일의name속성으로 정의된 프런트 엔드 모듈 이름에는 이 파일이 적용되는 사이트의 이름이 포함되어야 합니다. 예를 들어,/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 위치가 있어야 합니다.
- 일반적인 방법은 개발 환경에 대해 수행된 변경 내용을 프로덕션 환경에 배포할
main분기에 다시 쉽게 병합할 수 있도록dev분기를 만드는 것입니다.
- 일반적인 방법은 개발 환경에 대해 수행된 변경 내용을 프로덕션 환경에 배포할
- 파이프라인: 프론트엔드 팀에는 개발 환경에 배포하는 프론트엔드 파이프라인이 있어야 합니다. 해당 파이프라인은 이전 부분에서 설명한 대로 일반적으로
dev분기에 있는 프론트엔드 모듈을 배포합니다.
-
-
그러면 프론트엔드 팀은 CSS 및 JS 코드가 이전 출력과 새 출력 모두에서 작동하도록 합니다.
-
평소대로, 로컬에서 개발하기 위해:
- 프론트엔드 모듈 내에서 실행된
npx aem-site-theme-builder proxy명령은 프론트엔드 모듈의 CSS 및 JS 파일을 로컬dist폴더의 파일로 바꾸는 동안 AEM 환경에서 콘텐츠를 요청하는 프록시 서버를 시작합니다. - 숨겨진
.env파일에서AEM_URL변수를 구성하면 로컬 프록시 서버에서 콘텐츠를 사용하는 AEM 환경을 제어할 수 있습니다. - 따라서 이
AEM_URL의 값을 변경하면 프로덕션 환경과 개발 환경 간을 전환하여 CSS와 JS가 두 환경에 모두 맞도록 조정할 수 있습니다. - 새 출력을 렌더링하는 개발 환경과 이전 출력을 렌더링하는 프로덕션 환경에서 작업해야 합니다.
- 프론트엔드 모듈 내에서 실행된
-
업데이트된 프론트엔드 모듈이 두 환경 모두에서 작동하고 두 환경에 배포되면 프론트엔드 작업이 완료됩니다.
-
-
그러면 백엔드 팀은 전체 스택 파이프라인을 통해 새 HTML 및/또는 JSON 출력을 렌더링하는 코드를 배포하여 프로덕션 환경을 업데이트할 수 있습니다.
-
그러면 프론트엔드 팀은 CSS와 JS를 정리하고 이전 출력에서만 필요했던 것을 제거하여 프론트엔드 파이프라인을 통해 프로덕션에 마지막 업데이트를 배포할 수 있습니다.
추가 리소스 additional-resources
- 사이트 테마 - AEM 사이트 테마를 사용하여 사이트의 스타일 및 디자인을 맞춤화하는 방법에 대해 알아봅니다.
- AEM 사이트 테마 빌더 - Adobe은 새 사이트 테마를 만들기 위한 스크립트 세트로 AEM 사이트 테마 빌더를 제공합니다.