이 페이지에서는 프로젝트 관리 - 우수 사례 검사 목록에 의해 적용되는 문서 및 원칙을 상세히 설명하고 보완하기 위한 세부 정보를 제공합니다.
이 하위 섹션의 목록은 완벽하지는 않지만, 소개로 작성되었습니다.
AEM을 구현할 때(특히 처음) AEM🔗의 기능 및 워크플로우를 검토하여 필요한 영역을 확인해야 합니다.
사용할 AEM의 기능과 디자인에 미치는 영향을 고려해 보십시오.예:
또한 AEM의 다양한 버전에서 릴리스 노트를 확인하여 새로운 기능이 언제 추가되었는지 확인하십시오.
AEM은 다른 Adobe 제품 및/또는 타사 서비스와 통합할 수 있습니다. 따라서 원하는 대로 성능과 기능을 향상시킬 수 있습니다.
자세한 내용은 솔루션 통합을 참조하십시오.
다음 중 하나를 선택해야 하는 경우가 가장 중요합니다.
이전 버전에서 현재 버전으로 이동할 때에는 다음 두 가지 옵션이 있습니다.
어떤 프로젝트에서도 마찬가지로, 가능한 한 빨리 기본 원칙을 세우는 것이 중요하다. 이러한 쿠키에는 다음이 포함됩니다.
이러한 포인트는 일반적이며, 우수 사례 검사 목록은 AEM과 관련된 세부 사항을 처리합니다.
역할
이러한 정보는 명확히 정의되어야 하며 프로젝트에 관련된 모든 사람에게 알려져야 합니다. 또한 다음을 강조 표시하는 것이 좋습니다.
책임
참여
가능한 한 빨리 이해관계자를 참여시켜 프로젝트 이해관계자가 되도록 유도하여 프로젝트 성공에 대한 헌신을 높일 수 있습니다.
통신 경로
프로세스
정의할 프로세스는 개별 프로젝트에 따라 다릅니다. 다음 사항을 고려하여 이러한 간단한 작업을 다시 시도하십시오.
추적 도구
버그, 작업 및 프로젝트의 다른 측면에 대한 정보를 추적하는 데 사용할 수 있는 많은 도구가 있습니다. 자세한 내용은 잠재적 도구 개요를 참조하십시오.
범위
다양한 수준에서 프로젝트에 의해 다루어야 하는 사항을 명확히 정의합니다.
보고
보고할 정보, 어떤 형태, 얼마나 자주, 누구에게 대해 명확히 정의하십시오.
용어
가정
이 정보는 프로젝트 안내서 내에 정의할 수 있습니다.Wiki를 사용하면 진행 중인 변경 사항이 효율적으로 처리되도록 할 수도 있습니다. 이러한 속성이 정의될 때마다, 주요 요소는 다음과 같습니다.
조직에서는 주요 성과 지표(KPI)를 사용하여 목표에 도달하는 동안 성과를 평가합니다. 이러한 지표는 구체적인 목표가 얼마나 효과적으로 충족되는지를 보여주는 데 사용할 수 있는 측정 가능한 가치입니다.
이러한 지표는 다음과 같습니다.
비즈니스:
공연:
일부 지표(전부는 아님)는 사용자가 식별하고 정의하는 대상 지표를 기반으로 할 수 있습니다.
지표는 웹 사이트의 품질에 대한 수량 측정을 정의하는 데 사용됩니다. 기본적으로 달성하려는 성능 목표에 대한 정의이며 KPI(주요 성과 지표)를 정의하는 데 사용할 수 있습니다.
많은 지표를 정의할 수 있지만, 자주 정의하는 지표는 성능 및 동시성에 대한 목표를 다룹니다. 특히, 정량화가 어려울 수 있고 종종 감성 평가를 받기 쉽습니다.
"우리 웹 사이트는 너무 느리게오늘" - 언제 느리게가 적합합니까?
"내 동료가 로그인하면 모두 모두 정지로 분쇄됩니다." - 시스템에서 지원할 수 있는 동시 사용자 수는 몇 명입니까?
"검색할 때 시스템 이 halt "(으)로 분쇄됩니다. 어떤 종류의 검색 요청이 시스템에 영향을 줍니까?
"파일을 다운로드하는 데 페이지가 소요됨" - 허용되는 다운로드 시간(일반적인 네트워크 조건에서)은 얼마입니까?
Target 지표는 프로젝트를 시작할 때 다음과 같이 정의됩니다.
타겟 지표를 정의할 때 항상 주의해야 하는 것처럼
프로젝트를 개발할 때 적절히 업데이트 및 조정할 수 있습니다. 프로젝트가 성공적으로 구현되면 설치 및 지속적인 작업을 위한 필수 서비스 수준을 모니터링/관리하는 데 도움이 되는 데 사용할 수 있습니다.
이러한 지표를 적절하게 사용하는 경우 유용한 도구를 제공할 수 있습니다.무책임하게 사용될 때 그들은 시간을 낭비할 수 있다. 늘 그렇듯이, 여러분은 여러분이 무엇을 측정하고 있는지, 어떻게 측정하고 있는지 그리고 그 이유를 이해할 필요가 있습니다.
이 섹션은 고려될 기본 원칙과 문제들을 다룰 것입니다. 각 설치마다 다르므로 측정할 실제 값은 달라집니다.
측정할 모든 지표는 어떤 식으로 프로젝트의 디자인에 영향을 받습니다. 반대로, 많은 문제들은 디자인 변화에 의해 가장 잘 해결될 것이다.
따라서 디자인을 결정하기 전에 대상 지표를 정의해야 합니다. 이를 통해 이러한 요소를 기반으로 디자인을 최적화할 수 있습니다. 프로젝트가 개발되면 기본 디자인 원칙을 변경하기가 어려울 것입니다.
웹 사이트의 구조를 만들 때 AEM 웹 사이트에 대해 권장되는 구조를 따르십시오. 다음 문제 및/또는 원칙을 이해하는지 확인하십시오.
디자인이 지침을 따르지 않는다고 생각되거나, 일부 의미를 잘 모르는 경우 프로그래밍 단계를 시작하거나 콘텐츠를 채우기 전에 이러한 문제를 명확히 하십시오.
인프라를 정의하거나 평가하려면 다음과 같은 대상 값을 정의하는 데 도움이 됩니다.
사용자의 상황 및 웹 사이트의 전략적 중요도에 따라 인프라 평가 및 선택에 도움이 됩니다.
평가할 수 있는 몇 가지 성능 요소가 있습니다.
개별 페이지에 대한 응답 시간 을 고려하여 다음을 고려합니다.
검색 요청에 대한 응답 시간
이 섹션은 성능 최적화와 함께 읽을 수 있으며, 실제로 성능을 측정하는 기술 세부 사항을 확장합니다.
주요 문제는 웹 사이트가 방문자 요청에 응답하는 시간입니다.
이 값은 각 요청에 대해 다르지만 평균 타겟 값을 정의할 수 있습니다. 이 값이 달성 가능하고 유지 관리할 수 있는 것으로 확인되면 웹 사이트의 성능을 모니터링하고 잠재적 문제의 개발을 나타내는 데 사용할 수 있습니다
작성 및 게시 환경의 다른 대상
타깃팅할 응답 시간은 대상 대상을 반영하는 작성자 및 게시 환경에서 다릅니다.
작성 환경
이 환경은 컨텐츠 입력 및 업데이트 작성자가 사용하므로 다음을 수행해야 합니다.
게시 환경
이 환경에는 사용자가 사용할 수 있는 컨텐츠가 포함되어 있습니다.
속도는 여전히 중요하지만, 작성 환경보다 속도가 느리는 경우도 종종 있습니다
추가 성능 향상 메커니즘이 적용되는 경우가 많습니다.
그렇다면 달성 가능한(평균) 응답 시간을 어떻게 결정할 수 있습니까? 이것은 종종 경험의 문제입니다.
그러나(제어된 상황에서는) 다음 지침을 적용할 수 있습니다.
위의 숫자는 다음 조건을 가정합니다.
응답 시간을 모니터링하는 데 사용할 수 있는 몇 가지 메커니즘이 있습니다.
AEM request.log를 사용하여 응답 시간 모니터링
성능 분석을 위한 좋은 시작점은 요청 로그입니다. 다른 정보 중에서 이 정보를 사용하여 개별 요청의 응답 시간을 볼 수 있습니다. 자세한 내용은 성능 최적화 를 참조하십시오.
HTML 주석을 사용하여 응답 시간 모니터링
HTML 주석을 사용하여 각 페이지의 소스 내에 응답 시간 정보를 포함할 수 있습니다.
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
검색 요청은 두 측면에서 웹 사이트에 상당한 영향을 줄 수 있습니다.
실제 검색의 응답 시간
일반 성능에 미치는 영향
검색 요청에 대한 타겟을 설정하는 것은 다음과 같은 경우에 따라 경험의 문제입니다.
프로젝트 처음부터 이러한 계획을 계획하고 통합해야 합니다. 모니터링할 수 있는 메커니즘은 다음과 같습니다.
AEM request.log를 사용하여 검색 응답 시간 모니터링
request.log를 사용하여 검색 요청에 대한 응답 시간을 모니터링할 수 있습니다.자세한 내용은 성능 최적화 를 참조하십시오.
검색 응답 시간을 측정하기 위한 프로그램 메커니즘
검색 요청 및 해당 성능에 대해 수집하는 정보를 사용자 지정하려면 프로젝트 소스 코드에 정보 수집을 포함하는 것이 좋습니다.자세한 내용은 성능 최적화 를 참조하십시오.
웹 사이트는 작성자와 게시 환경 모두에서 많은 사용자/방문자가 사용할 수 있게 됩니다. 테스트 시 사용한 것보다 숫자가 많기도 하지만 변화무쌍하고 예측하기도 어렵습니다. 성능에 부정적인 영향을 주지 않고 평균 동시 사용자/방문자 수를 위해 웹 사이트를 설계해야 합니다. 다시 request.log
을 사용하여 동시성 테스트를 수행할 수 있습니다.자세한 내용은 성능 최적화 를 참조하십시오.
동시 사용자 수에 대한 Target은 환경 유형에 따라 달라집니다.
작성 환경
게시 환경
관련 지표를 논의하기 전에 용어의 빠른 정의를 참조하십시오.
볼륨
용량
용량 및 볼륨
대상 / 위치 | 용량 | 볼륨 |
---|---|---|
클라이언트 | 사용자 컴퓨터의 계산 능력. | 페이지 레이아웃의 복잡성입니다. |
네트워크 | 네트워크 대역폭. | 페이지 크기(코드, 이미지 등)입니다. |
Dispatcher 캐시 | 웹 서버의 서버 메모리(주 메모리 및 하드 드라이브). | 웹 서버(주 메모리 및 하드 드라이브). 캐시된 페이지의 수 및 크기입니다. |
출력 캐시 | AEM 서버의 서버 메모리(주 메모리 및 하드 드라이브). | 출력 캐시의 페이지 수 및 크기, 페이지당 종속성 수입니다. 디스패처 캐시가 이 볼륨을 낮춥니다. |
웹 서버 | 웹 서버의 계산 능력. | 요청 금액입니다. 캐싱은 이 볼륨을 낮춥니다. |
템플릿 | 웹 서버의 계산 능력. | 템플릿의 복잡성. |
저장소 | 저장소의 성능입니다. | 저장소에서 로드된 페이지 수입니다. |
앞의 섹션에서는 정의할 기본 지표에 대해 자세히 설명합니다.
특정 요구 사항에 따라 격리하거나 위의 분류를 고려하여 추가 지표를 정의하는 것이 유용할 수 있습니다.
그러나 웹 사이트의 모든 측면을 측정하고 정의하려고 하지 않고, 쉽고 안정적으로 작동하는 작은 정확한 코어 지표 세트를 사용하는 것이 좋습니다. 그 자체로 웹 사이트가 사용자에게 전달되는 즉시 변화하고 발전하기 시작합니다.
보안은 중요하고 점점 더 많은 도전이다. 이 은(는) 프로젝트의 가장 이른 단계에서 고려 및 계획되어야 합니다.
보안 검사 목록에서는 배포 시 AEM 설치가 안전한지 확인하는 데 수행해야 하는 단계에 대해 자세히 설명합니다. 다른 보안 측면은 보안(개발 시) 및 사용자 관리 및 보안에서 다룹니다.
다음을 수행합니다.
표준 AEM 프로젝트를 새로 구현하려면 다음과 같은 작업을 고려해야 합니다.
모든 측면에서 반복적인 접근 방식을 사용하는 것이 좋습니다.
프로젝트 시작을 Soft Launch(가용성 감소, 여러 반복) 및 Hard Launch(전체 가용성 - 라이브)로 분할하여 프로덕션 환경의 현실적인 조건에서 조정, 최적화 및 사용자 교육을 수행할 수 있습니다.
프로젝트의 수명 주기 동안 수행(또는 평가)해야 하는 작업의 예는 프로젝트 검사 목록을 참조하십시오.
각 카테고리에 대한 일부 포인트는 다음과 같습니다.
개발
먼저 기본 아키텍처를 정의합니다.
개발에 여러 반복(단거리) 사용:
프로젝트 중에 사용 가능한 AEM 버전 업데이트에 대한 이벤트를 계획합니다.
인쇄 기간 동안 테스트 및 최적화를 계획합니다.
안정화 및 최적화 단계 계획
추가 릴리스에 대해 계획할 항목 로그를 만듭니다.
파트너 참여 및 핸드오버 계획
인프라
먼저 기본 아키텍처를 정의합니다.
여러 반복 사용첫 번째 스프린트 및 초기 구성의 경우:
여러 로드 테스트를 계획합니다.
인쇄 기간 동안 테스트 및 최적화를 계획합니다.
안정화 및 최적화 단계를 계획합니다.
가능한 한 빨리 프로덕션 환경에 배포합니다(작업 팀이 경험을 얻기 위해 시스템을 설정하도록 함).
가능한 한 빨리 명명된 사용자를 사용하고 정의된 역할을 사용하십시오.
교육 계획(예: 관리자 교육).
작업에 대한 핸드오버 계획.
컨텐트
그런 다음 결과 작업 목록에 따라 (높은 수준) 작업 정의에 대한 초기 예상 시간과 노력을 수행할 수 있습니다. 여기에는 누가 (고객 또는 파트너)이 무엇을 하고 언제 무엇을 할 것인지에 대한 표시가 포함되어야 합니다.
다음 목록에는 표준 근사 및 관련 작업의 상호 관계, 따라서 비용이 표시됩니다.
이 수치는 초기 추정치에만 사용할 수 있다. 숙련된 AEM 개발자는 세부 분석을 수행해야 합니다.
단계 | 작업 |
---|---|
개발 | 각 구성 요소 노드에 대한 대략적인 추정 2~4시간은 모든 개발 요구 사항을 다룹니다. |
개발자 테스트 | 개발 15% |
후속 작업 | 개발 10% |
설명서 | 개발 15% |
JavaDoc 설명서 | 개발 10% |
버그 수정 | 개발 15% |
프로젝트 관리 | 지속적인 프로젝트 관리 및 거버넌스에 대한 프로젝트 비용의 20% |
그런 다음 사용 가능한 자원 또는 필요한 자원을 최종 기한 및 비용에 연결할 수 있습니다.
AEM 아키텍처에 대한 템플릿 솔루션을 제공하기 위해 참조 아키텍처가 제공됩니다. 참조 아키텍처는 확장, 안정성 및 보안 등 엔터프라이즈 시스템에 공통적으로 발생하는 문제를 해결합니다.
다음 사이트 지표를 정의해야 합니다.
분류 | 정의 |
---|---|
인터넷 사이트 수 | |
인트라넷 사이트 수 | |
코드 베이스의 수(예: 인터넷과 인트라넷이 다른 경우) | |
개별 페이지 수 | |
사이트 방문 횟수/일 | |
페이지 보기 수/일 | |
데이터 전송 / 요일의 볼륨(GB) | |
동시 사용자 수(폐쇄된 사용자 그룹) | |
동시 방문자 수(게시) | |
동시 작성자 수 | |
등록된 작성자 수 | |
페이지 활성화/작업일 수 | |
배포 중 페이지 활성화 수 |
다음 목록은 사용할 수 있는 도구를 알려줍니다. 이것은 광범위한 추천 목록이 아니라 소개로 작성되었으며, 사용자가 선호하는 다른 도구의 사용을 막지 말아야 합니다.
제품 | 설명 |
AEM | AEM 자체는 애플리케이션을 모니터링, 테스트, 조사 및 디버깅하는 데 도움이 되는 다양한 메커니즘을 제공합니다.다음을 포함합니다. |
셀레늄 | Seleniumis 오픈 소스 테스트 도구입니다. 테스트는 브라우저에서 직접 실행됩니다. 사용자가 작동하는 방식을 에뮬레이션합니다. |
Microsoft Project | 일반적으로 사용되는 프로젝트 관리 도구입니다. |
지라 | Jiraris 는 소프트웨어 버그의 세부 사항을 추적하고 관리하기 위한 오픈 소스 도구입니다. 워크플로우는 필요에 따라 버그 세부 사항에 적용할 수 있습니다. |
Git | 수정 제어 소프트웨어를 지정합니다. |
Eclipse | Eclipse는 다양한 프로젝트로 구성된 오픈 소스 IDE입니다. 이들은 라이프사이클에서 소프트웨어를 구축, 배포 및 관리할 수 있는 확장 가능한 프레임워크, 도구 및 런타임으로 구성된 개방형 개발 플랫폼을 구축하는 데 중점을 두고 있습니다. 자세한 내용은 Eclipse를 사용하여 AEM 프로젝트를 개발하는 방법 을 참조하십시오. |
IntelliJ | 포괄적인 기능을 제공하는 전문(따라서 라이센스 비용에 대한 부담) IDE입니다. 자세한 내용은 IntelliJ IDEA를 사용하여 AEM 프로젝트를 개발하는 방법 을 참조하십시오. |
Maven | Maven은 프로젝트의 빌드 프로세스(소프트웨어 및 설명서)를 관리할 수 있는 소프트웨어 프로젝트 관리 및 이해 도구입니다. |
또한 다음 섹션은 특별히 관심이 있습니다.
Adobe은 모든 단계 및 대상에 대한 추가 우수 사례를 제공합니다.