실제 사례
기업마다 팀 설정, 프로세스 및 개발 워크플로 등의 요구 사항이 다릅니다. 아래에 설명된 설정은 Adobe에서 AEM as a Cloud Service를 기반으로 경험을 제공하는 여러 프로젝트에 사용됩니다.
예를 들어 Adobe Photoshop 또는 Adobe Illustrator와 같은 Adobe Creative Cloud 애플리케이션에는 최종 사용자가 사용할 수 있는 튜토리얼, 샘플 및 안내서와 같은 콘텐츠 리소스가 포함되어 있습니다. 클라이언트 애플리케이션은 헤드리스 방식으로 AEM as a Cloud Service의 콘텐츠를 소비합니다. 구조화된 컨텐츠를 JSON 스트림으로 검색하기 위해 AEM Cloud 게시 계층에 API를 호출합니다. 또한 AEM as a Cloud Service🔗의 CDN(Content Delivery Network)은 정형 및 비정형 컨텐츠를 최적의 성능으로 제공하는 데 사용됩니다.
이 프로젝트에 기여하는 팀은 다음 프로세스를 따릅니다.
각 팀은 자체 개발 워크플로를 사용하며 별도의 Git 저장소가 있습니다. 추가 공유 Git 저장소는 프로젝트 온보딩에 사용됩니다. 이 Git 저장소에는 공유 Dispatcher 구성을 포함한 Cloud Manager Git 저장소의 루트 구조가 포함되어 있습니다.
새 프로젝트를 온보딩하려면 공유 Git 저장소의 루트에 있는 Reactor Maven 프로젝트 파일에 나열되어야 합니다. Dispatcher 구성의 경우 Dispatcher 프로젝트 내에 새 구성 파일이 만들어집니다. 그러면 기본 Dispatcher 구성에 이 파일이 포함됩니다. 각 팀은 자체 Dispatcher 구성 파일을 담당합니다. 공유 Git 저장소에 대한 변경은 드물며 일반적으로 새 프로젝트가 온보딩될 때만 필요합니다. 주요 작업은 각 프로젝트 팀이 자체 Git 저장소 내에서 수행합니다.
각각에 대한 Git 저장소는 AEM Project Archetype을(를) 사용하여 설정되므로 AEM 프로젝트 설정을 위한 모범 사례를 따릅니다. 유일한 예외는 위에 설명된 대로 공유 Git 저장소에서 수행되는 Dispatcher 구성입니다.
각 팀은 Git 흐름 모델에 따라 2개의 +N 분기가 있는 단순화된 Git 워크플로를 사용합니다.
-
안정적인 릴리스 분기에는 프로덕션 코드가 포함됩니다.
-
개발 분기에는 최신 개발이 포함됩니다.
-
각 피쳐에 대해 새 분기가 생성됩니다.
개발은 기능 분기에서 수행됩니다. 기능이 완성되면 개발 분기에 병합됩니다. 완성되고 검증된 기능은 개발 분기에서 선택되어 안정적인 분기에 병합됩니다.
모든 변경은 PR(끌어오기 요청)을 통해 수행됩니다. 품질 게이트는 각 PR의 유효성을 자동으로 확인합니다. 코드의 품질을 확인하는 데는 Sonar가 사용되며 새 코드에 회귀가 발생하지 않는지 확인하기 위해 일련의 테스트 모음이 실행됩니다.
Cloud Manager의 Git 저장소 설정에는 두 개의 분기가 있습니다.
- 안정적인 릴리스 분기에는 모든 팀의 프로덕션 코드가 포함됩니다.
- 개발 분기에는 모든 팀의 개발 코드가 포함됩니다.
개발 또는 안정적인 분기에서 팀의 Git 저장소로 푸시할 때마다 GitHub 작업이 트리거됩니다.
모든 프로젝트는 안정적인 분기에 대해 동일한 설정을 따릅니다. 프로젝트의 안정적인 분기로 푸시하면 Cloud Manager의 Git 저장소에 있는 안정적인 분기로 자동 푸시됩니다. 안정적인 분기로 푸시하면 Cloud Manager에서 프로덕션 파이프라인이 트리거됩니다. 팀이 안정적인 분기로 푸시할 때마다 프로덕션 파이프라인이 트리거됩니다. 모든 품질 게이트가 통과하면 프로덕션 배포가 업데이트됩니다.
개발 분기에 대한 푸시는 처리 방법이 다릅니다. 팀의 Git 저장소에서 개발자 분기로 푸시하면 GitHub 작업도 트리거됩니다. 이 작업을 수행하면 코드가 Cloud Manager의 Git 저장소에 있는 개발 분기에 자동으로 푸시됩니다. 그러나 이 코드 푸시는 비프로덕션 파이프라인을 자동으로 트리거하지 않습니다. Cloud Manager의 API 호출이 트리거됩니다.
프로덕션 파이프라인 실행에는 제공된 품질 게이트를 통해 모든 팀의 코드를 확인하는 작업이 포함됩니다. 코드가 스테이징에 배포되면 테스트 및 감사가 실행되므로 모든 것이 예상대로 작동합니다. 모든 게이트가 통과되면 중단 없이 변경 사항이 프로덕션으로 롤아웃됩니다.
로컬 개발의 경우 AEM as a Cloud Service용 SDK가 사용됩니다. SDK를 사용하면 로컬 작성자, 게시 및 Dispatcher을 설정할 수 있습니다. 이 워크플로우를 통해 오프라인 개발 및 빠른 처리 시간이 가능합니다. 때로는 작성 환경만 개발에 사용되지만, Dispatcher 및 게시 환경을 빠르게 설정하면 Git 저장소로 푸시하기 전에 모든 것을 로컬에서 테스트할 수 있습니다.
각 팀의 멤버는 일반적으로 공유 Git의 코드를 자체 프로젝트 코드로 체크아웃합니다. 프로젝트가 독립적이므로 다른 프로젝트를 체크아웃할 필요가 없습니다.
이 실제 설정을 청사진으로 사용한 다음 기업의 요구 사항에 맞게 사용자 정의할 수 있습니다. Git의 유연한 분기 및 병합 개념은 모든 팀의 요구 사항에 맞게 위의 워크플로를 사용자 정의할 수 있습니다. AEM as a Cloud Service는 독창적인 Cloud Manager 파이프라인의 핵심 가치를 그대로 유지하면서 이러한 모든 변형을 지원합니다.
TIP다중 팀 설정에 대한 고려 사항
Cloud Manager의 Git 저장소와 프로덕션 파이프라인을 사용하면 전체 프로덕션 코드는 항상 모든 품질 게이트를 통과하여 하나의 배포 단위로 처리됩니다. 이러한 방식으로 프로덕션 시스템은 중단 없이 항상 가동됩니다.
반면 이러한 시스템이 없으면 각 팀이 개별적으로 배포할 수 있으므로 단일 팀의 업데이트로 인해 프로덕션 안정성 문제가 발생할 위험이 있습니다. 또한 업데이트를 롤아웃하려면 조정과 계획된 가동 중지 시간이 필요합니다. 팀의 수가 증가함에 따라 조정 작업은 훨씬 더 복잡해지고 관리하는 데 시간이 오래 걸립니다.
품질 게이트에서 문제가 감지되면 생산에 영향을 미치지 않으며 Adobe 직원이 개입할 필요 없이 문제를 감지하고 해결할 수 있습니다. Cloud Service를 사용하지 않고 전체 배포를 항상 테스트하지 않으면 부분 배포로 인해 롤백 요청이 필요하거나 백업에서 전체 복원을 수행해야 하는 운영 중단이 발생할 수 있습니다. 부분 테스트로 인해 나중에 해결해야 하는 추가 문제가 발생할 수도 있으므로 Adobe 담당자의 조정과 지원이 다시 필요합니다.
TIP
