프론트엔드 파이프라인으로 Sites 개발
- 주제:
- 개발
작성 대상:
- 관리자
- 개발자
프론트엔드 파이프라인을 통해 프론트엔드 개발자의 독립성을 높이고 개발 속도를 크게 높일 수 있습니다. 이 문서에서는 프로세스의 작동 방식을 설명하고 프로세스를 최대한 활용할 수 있는 주요 고려 사항을 소개합니다.
AEM Cloud Manager의 프론트엔드 파이프라인 설정 및 빌드 프로세스 이해
전체 스택 빌드 환경과 마찬가지로 프론트엔드 파이프라인에도 고유한 환경이 있습니다. 개발자는 프론트엔드 빌드 계약을 따르는 경우 이 파이프라인을 유연하게 사용할 수 있습니다.
프론트엔드 파이프라인을 사용하려면 프론트엔드 Node.js
프로젝트가 build
스크립트 지시문을 사용하여 배포하는 빌드를 생성해야 합니다. Cloud Manager에서 npm run build
명령을 사용하여 프론트엔드 빌드에 대한 배포 가능한 프로젝트를 생성하기 때문에 이 요구 사항이 존재합니다.
dist
폴더의 결과 콘텐츠는 Cloud Manager이 최종적으로 배포하여 정적 파일로 제공합니다. 이러한 파일은 AEM 외부에서 호스팅되지만 배포된 환경에서 /content/...
URL을 통해 사용할 수 있습니다.
지원되는 Node.js 버전
프론트엔드 빌드 환경은 다음 Node.js
버전을 지원합니다.
- 18
- 16
- 14(기본값)
- 12
NODE_VERSION
환경 변수를 사용하여 원하는 버전을 설정할 수 있습니다.
AEM에서 프론트엔드 파이프라인 이름 지정 및 관리에 대한 우수 사례
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의 안정성을 위한 프론트엔드 및 백엔드 개발 조정
문제 분리에 대한 핵심 모범 사례는 계약 간의 경계를 정의하는 계약을 신중하게 디자인하고 관리하는 것입니다. 프론트엔드 파이프라인에서 이 계약은 사이트에서 렌더링한 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
명령은 AEM 환경에서 콘텐츠를 검색하는 프록시 서버를 시작합니다. 프론트엔드 모듈의 CSS 및 JS 파일을 로컬dist
폴더의 파일로 대체합니다.- 숨겨진
.env
파일에서AEM_URL
변수를 구성하면 로컬 프록시 서버에서 콘텐츠를 사용하는 AEM 환경을 제어할 수 있습니다. - 따라서
AEM_URL
의 값을 변경하면 프로덕션 환경과 개발 환경 간을 전환하여 두 환경에 모두 맞도록 CSS와 JS를 조정할 수 있습니다. - 새 출력을 렌더링하는 개발 환경과 이전 출력을 렌더링하는 프로덕션 환경에서 작업해야 합니다.
-
업데이트된 프론트엔드 모듈이 두 환경 모두에서 작동하고 두 환경에 배포되면 프론트엔드 작업이 완료됩니다.
-
-
그러면 백엔드 팀은 전체 스택 파이프라인을 통해 새 HTML 또는 JSON 출력 또는 두 가지 모두를 렌더링하는 코드를 배포하여 프로덕션 환경을 업데이트할 수 있습니다.
-
프론트엔드 팀은 프론트엔드 파이프라인을 사용하여 CSS 및 JS를 정리하고, 이전 출력에만 필요한 요소를 제거하며, 프로덕션에 최종 업데이트를 배포할 수 있습니다.
추가 리소스
-
AEM 사이트 테마를 사용하여 사이트의 스타일 및 디자인을 맞춤화하는 방법에 대해 알아봅니다.
사이트 테마를 참조하세요.
-
Adobe는 새 사이트 테마를 만들기 위한 스크립트 세트로 AEM 사이트 테마 빌더를 제공합니다.
Experience Manager
- 개요
- 릴리스 정보
- 릴리스 정보
- AEMaaCS 기능 릴리스 정보
- AEMaaCS 유지 관리 릴리스 정보
- Cloud Manager 릴리스 정보
- 마이그레이션 도구 릴리스 정보
- Experience Manager 강화 커넥터용 Workfront 릴리스 정보
- 베리에이션 생성 릴리스 정보
- 범용 편집기 릴리스 정보
- 새로운 기능
- AEM Cloud Service의 주요 변경 사항
- 사용 중단 및 제거된 기능과 API
- 프리릴리스 채널
- 보안
- AEM as a Cloud Service 보안 개요
- AEM as a Cloud Service에 대한 고급 네트워킹 구성
- AEM as a Cloud Service에 대한 IMS 지원
- AEM as a Cloud Service에 대한 Same Site 쿠키 지원
- 메일 서비스에 대한 OAuth2 지원
- WAF 규칙이 포함된 트래픽 필터 규칙
- Adobe Developer Console에서 JWT 자격 증명 사용 중단
- AEM as a Cloud Service에 대한 IMS 통합 설정
- Sling 서비스 사용자 매핑 및 서비스 사용자 정의의 모범 사례
- 온보딩
- AEM as a Cloud Service 마이그레이션 여정
- Sites
- AEM Cloud Service의 AEM Sites에 대한 주요 변경 사항
- Sites 및 Edge Delivery Services
- 작성
- 관리
- AEM as a Cloud Service와 통합
- AEM as a Cloud Service용 실제 사용 모니터링
- Assets
- 개요 및 새로운 기능
- Assets as a Cloud Service 주요 변경 사항
- Assets 아키텍처
- 지원되는 파일 형식
- 자산 마이크로서비스 개요
- Assets에서의 접근성
- Assets as a Cloud Service Ultimate
- Assets as a Cloud Service Ultimate 활성화
- Assets as a Cloud Service Prime
- Assets Collaborator 사용자
- AEM Assets를 통합하면서 Edge Delivery Services용 콘텐츠 작성
- 디지털 자산 관리
- 마이크로 프론트엔드 자산 선택기
- 마이크로 프론트엔드 대상 선택기
- 자산 공유
- 자산 재처리
- 자산 마이크로서비스 사용 시작하기
- 자산 추가 및 업로드
- 자산 검색
- 일반적인 자산 관리 작업
- 게시 관리
- 3D 자산 미리보기
- 이미지용 스마트 태그
- 비디오 자산에 스마트 태그 지정
- 자산 구성 방법
- Adobe Stock 자산 사용
- 컬렉션 관리
- 메타데이터 개요
- Adobe Creative Cloud와 통합
- 메타데이터 추가 또는 편집 방법
- 폴더 자산 및 컬렉션 검토
- Assets Insights 사용 및 구성
- 메타데이터 프로필
- 메타데이터 스키마
- 비디오 자산 관리
- MSM을 사용하여 자산 재사용
- 자산 다운로드
- 편집할 자산 체크인 및 체크아웃
- 비공개 폴더 생성 및 공유
- 자산용 Digital Rights Management
- 자산에 워터마크 추가
- Creative Cloud API를 사용하여 자산 처리
- 이미지용 색상 태그
- PDF 문서 관리
- Assets 구성, 관리 및 확장
- 자산 공유 및 배치
- 콘텐츠 조각
- Dynamic Media
- Dynamic Media 여정: 기본 사항
- Experience League의 Dynamic Media 뉴스레터 아카이브
- Dynamic Media 설정
- Dynamic Media를 사용하여 작업
- Dynamic Media 구성
- Dynamic Media Prime 및 Ultimate
- Dynamic Media Prime 및 Ultimate 활성화
- 옵션 - Dynamic Media, 일반 설정 구성
- 옵션 - Dynamic Media, 게시 설정 구성
- Dynamic Media 문제 해결
- Dynamic Media 별칭 계정 구성
- Dynamic Media에서의 접근성
- Dynamic Media 자산 관리
- 이미지 품질 최적화 모범 사례
- 이미지 프로필
- 비디오 프로필
- Dynamic Media 이미지 사전 설정 관리
- Dynamic Media 이미지 사전 설정 적용
- Dynamic Media 뷰어 사전 설정 관리
- Dynamic Media 뷰어 사전 설정 적용
- 일괄 처리 집합 사전 설정
- Dynamic Media의 방식으로 CDN 캐시 무효화
- Dynamic Media Classic의 방식으로 CDN 캐시 무효화
- 스마트 이미징
- 클라이언트측 디바이스 픽셀 비율을 활용한 스마트 이미징
- Dynamic Media 자산 전송
- Dynamic Media 템플릿
- Dynamic Media의 핫링크 보호 활성화
- 3D 지원
- Dynamic Media 제한 사항
- 이미지 세트
- 파노라마 이미지
- 혼합 미디어 세트
- 스핀 세트
- Dynamic Media의 비디오
- 슬라이드 배너
- 대화형 이미지
- 대화형 비디오
- 360 VR 비디오
- Dynamic Media 뷰어를 Adobe Analytics 및 Adobe Experience Platform 태그와 통합
- 빠른 보기를 사용하여 사용자 정의 팝업 만들기
- 반응형 사이트에 최적화된 이미지 게재
- Dynamic Media 자산 미리보기
- 페이지에 Dynamic Media 자산 추가
- 웹 페이지에 Dynamic Video 또는 Dynamic Image 뷰어 임베드
- 웹 애플리케이션에 URL 연결
- 규칙 세트를 사용하여 URL 변환
- Dynamic Media 자산 게시
- Dynamic Media의 선택적 게시를 사용하여 작업
- 선택기를 사용하여 작업
- 콘텐츠 FAQ의 HTTP2 게재
- Flash 뷰어 서비스 종료
- DHTML 뷰어 서비스 종료
- OpenAPI 기능이 포함된 Dynamic Media
- Assets 보기로 작업
- Content Hub
- 개요
- Content Hub 배포
- 브랜드 승인 자산을 Content Hub로 업로드 또는 가져오기
- Content Hub 사용자 인터페이스 구성
- Content Hub에 대한 자산 승인
- Content Hub에서 자산 검색
- 자산 속성
- Content Hub에서 자산 공유
- Content Hub를 사용하여 자산 다운로드
- Content Hub에서 라이선스가 부여된 자산 관리
- Content Hub에서 컬렉션 관리
- Content Hub에서 Adobe Express를 사용하여 이미지 편집
- Content Hub의 Asset Insights
- Content Hub에 대해 자주 묻는 질문
- 모범 사례
- Adobe Workfront와 통합
- Adobe Express와 통합
- Creative Cloud와 통합
- Forms
- 개요
- 설정 및 마이그레이션
- 통합
- 서비스
- Adobe Sign과 AEM Forms as a Cloud Service 통합
- DocuSign과 AEM Forms as a Cloud Service 통합
- Adobe Analytics에 적응형 양식 통합
- 적응형 양식 분석 보고서 보기 및 이해
- Adobe Workfront Fusion에 적응형 양식 제출
- Microsoft Power Automate와 적응형 양식 통합
- AEM Sites 페이지에 적응형 양식 임베드
- 외부 웹 페이지에 핵심 구성 요소 기반 적응형 양식 임베드
- 외부 웹 페이지에 기초 구성 요소 기반 적응형 양식 임베드
- Adobe Marketo Engage와 적응형 양식 통합
- Forms 데이터 모델
- 서비스
- 적응형 양식
- 적응형 양식 조각 만들기
- AEM Sites 페이지 또는 경험 조각에 적응형 양식 추가
- 핵심 구성 요소
- 적응형 양식 만들기
- 적응형 양식 만들기
- 핵심 구성 요소 기반 적응형 양식의 레이아웃 설정
- 적응형 양식 조각 만들기
- 적응형 양식의 테마 만들기 - 핵심 구성 요소
- 핵심 구성 요소 기반 적응형 템플릿 만들기
- XFA Forms 템플릿 기반 적응형 양식(핵심 구성 요소) 만들기
- 적응형 양식의 기록 문서 생성
- 기계 번역 또는 인간 번역을 사용하여 적응형 양식 번역
- 리디렉션 페이지 또는 감사 메시지 구성
- 반복 가능한 섹션으로 양식 만들기
- 적응형 양식에 대한 제출 액션 구성
- Azure Blob Storage에 적응형 양식 제출
- Microsoft에 적응형 양식 제출
- Microsoft® SharePoint에 적응형 양식 연결
- AEM 적응형 양식과 AEM Workflow 통합
- 적응형 양식의 REST 엔드포인트에 제출 액션 구성
- 적응형 양식의 이메일 보내기 제출 액션 구성
- 적응형 양식에서 Google reCAPTCHA 사용
- 적응형 양식 핵심 구성 요소의 hCaptcha 사용
- 적응형 양식 핵심 구성 요소의 Turnstile Captcha 사용
- 적응형 양식에서 사용자 정의 오류 핸들러 추가
- 핵심 구성 요소 기반 적응형 양식의 로케일 추가
- 적응형 양식에 대한 JSON 스키마 디자인 (핵심 구성 요소)
- 적응형 양식에 버전 관리, 댓글 및 주석 추가
- 적응형 양식 비교
- 사용자 정의 제출 액션 만들기
- Experience Manager Forms에서 게시 관리
- 핵심 구성 요소 기반 적응형 양식의 규칙 편집기 소개
- 핵심 구성 요소 기반 적응형 양식의 사용자 정의 함수 소개
- Forms 포털 및 해당 구성 요소 소개
- 적응형 양식 만들기
- 기초 구성 요소
- 적응형 양식 키워드
- 양식 미리보기
- 인터랙티브 커뮤니케이션
- Forms 중심 워크플로
- 커뮤니케이션 API
- 트랜잭션 보고서
- 개발자 API 참조
- 문제 해결
- Screens
- Content and Commerce
- Edge Delivery Services
- Edge Delivery Services 개요
- AEM과 함께 Edge Delivery Services 사용
- 작성 방법 선택
- WYSIWYG 작성
- 문서 기반 작성
- 애플리케이션 빌드
- 애플리케이션 실행
- Forms 빌드
- 개요
- WYSIWYG 작성
- Edge Delivery Services용 Forms Universal Editor 소개 - 전체 안내서
- 범용 편집기를 사용하여 작성을 시작하는 방법 - 단계별 자습서
- Universal Editor 인터페이스 안내서: 도구, 기능 및 탐색 설명
- 모바일 친화적인 Forms 만들기: 범용 편집기의 반응형 디자인
- 아름다운 Forms 디자인: 범용 편집기를 위한 스타일 및 테마 지정 가이드
- Forms에 동적 동작 추가: 규칙 편집기에 대한 전체 안내서
- 양식 제출 안내서: 양식 제출 작업 구성 및 사용자 지정
- 스팸으로부터 Forms 보호: reCAPTCHA 보안 추가
- Forms 게시 및 배포 방법: 범용 편집기 게시 안내서
- 사용자 지정 양식 구성 요소 빌드: 유니버설 편집기에 대한 개발자 안내서
- 문서 기반 작성
- 첫 번째 양식 작성: Google Sheets 및 Excel로 빠른 시작 안내서
- Google Sheets 또는 Excel을 사용하여 Forms을 만드는 방법: 단계별 안내서
- 적응형 양식 블록의 다양한 구성 요소
- 양식을 Google Sheets에 연결: 데이터 수집 설정 안내서
- 양식을 라이브로 만들기: 게시 및 데이터 수집 안내서
- 아름다운 Forms 디자인: 스타일 및 사용자 지정 안내서
- 성공 메시지 만들기: 양식의 감사 페이지 사용자 지정
- 양식 제출 안내서: Forms 제출 서비스 사용
- 동적 양식 필드: URL에서 옵션 로드
- 스마트 동작 추가: 양식 규칙 및 논리 안내서
- 동적 Forms 만들기: 반복 가능한 섹션 추가
- Forms 보호: reCAPTCHA 보안 추가
- Edge Delivery 리소스
- Headless
- 생성형 AI
- 구현
- AEM as a Cloud Service용 애플리케이션 구현
- Cloud Manager 사용
- AEM as a Cloud Service용 개발
- AEM 프로젝트 구조
- AEM 프로젝트 저장소 구조 패키지
- AEM as a Cloud Service SDK
- AEM 신속한 개발 환경
- AEM as a Cloud Service 개발 지침
- AEM as a Cloud Service Developer Console (Beta)
- 로깅
- 로그 전달
- 구성 및 구성 브라우저
- AEM 기술 기초
- API 참조 자료
- OpenAPI 기반 API
- 서버측 API용 액세스 토큰 생성
- 빠른 사이트 생성 및 프론트엔드 맞춤화
- 프론트엔드 파이프라인으로 Sites 개발
- 사이트 템플릿 및 테마 맞춤화
- AEM Headful 및 Headless
- Sling 모델 내보내기 도구를 통한 ResourceResolver 직렬화 비활성화
- 전체 스택 AEM 개발
- 범용 편집기
- Headless 경험 관리
- 하이브리드 및 SPA 개발
- 개발자 도구
- 개인화
- AEM as a Cloud Service 구성 및 확장
- AEM as a Cloud Service에 배포
- 작성자 계층
- 콘텐츠 게재 개요
- 커넥터
- 운영
- 규정 준수