이 페이지에서는 다음 내용에 포함된 문서 및 원칙을 자세히 설명하고 보강할 수 있는 자세한 내용을 제공합니다. 프로젝트 관리 - 우수 사례 검사 목록.
이 하위 섹션의 목록은 전체 목록이 아니라 소개하기 위한 것입니다.
AEM을 구현할 때(특히 처음으로) AEM의 기능 및 워크플로 원하는 영역과 필요한 영역을 확인해야 합니다.
사용 중인 AEM의 기능과 디자인에 미치는 영향을 고려하십시오. 예를 들면 다음과 같습니다.
또한 다음을 확인하십시오. 릴리스 정보를 사용하여 다양한 AEM 버전에서 새 기능이 추가된 시기를 확인할 수 있습니다.
AEM은 다른 Adobe 제품이나 서드파티 서비스 또는 둘 다와 통합할 수 있습니다. 이러한 워크플로우는 원하는 대로 성능과 기능을 향상시킬 수 있습니다.
다음을 참조하십시오 솔루션 통합 전체 정보.
주요 고려 사항은 다음 중 하나를 원하는지 여부입니다.
이전 버전에서 현재 버전으로 이동할 때 두 가지 옵션이 있습니다.
다른 프로젝트와 마찬가지로, 가능한 한 빨리 기본 규칙을 설정하는 것이 중요합니다. 이러한 규칙에는 다음이 포함됩니다.
이러한 지점은 일반적이고 우수 사례 검사 목록 은 AEM과 관련된 세부 사항을 다룹니다.
역할
역할을 명확히 정의하고 프로젝트에 관련된 모든 사람에게 알려야 합니다. 또한 다음을 강조 표시하는 것이 좋습니다.
책임
관여
이해 관계자들을 가능한 한 빨리 참여시킴으로써, 당신은 그들이 될 수 있도록 격려할 수 있습니다 이해 당사자 을 클릭합니다. 그렇게 하면 성공에 대한 그들의 헌신이 높아집니다.
통신 경로
프로세스
정의된 프로세스는 개별 프로젝트에 따라 다릅니다. 다시 한 번, 다음 사항을 고려하여 이러한 프로세스를 단순하게 유지하십시오.
추적 도구
버그, 작업 및 프로젝트의 다른 측면에 대한 정보를 추적하는 데 사용할 수 있는 다양한 도구가 있습니다. 다음을 참조하십시오. 잠재적 도구 개요 을 참조하십시오.
범위
다양한 수준에서 프로젝트에서 다루는 사항을 명확히 정의합니다.
보고
보고하려는 정보, 보고 형식, 빈도 및 대상을 명확히 정의합니다.
용어
가정
이 정보는 프로젝트 핸드북 내에서 정의할 수 있습니다. Wiki를 사용하면 진행 중인 변경 사항을 효율적으로 처리할 수 있습니다. 이러한 가정이 정의되는 곳마다, 주요 요인은 다음과 같습니다.
조직은 주요 성과 지표(KPI)를 사용하여 목표 달성 성공을 평가합니다. 이러한 지표는 구체적 목표가 얼마나 효과적으로 충족되고 있는지를 입증하는 데 사용될 수 있는 측정 가능한 값이다.
이러한 지표는 다음과 같을 수 있습니다.
상업:
공연:
전부는 아니지만 일부 지표는 식별 및 정의하는 타겟 지표를 기반으로 할 수 있습니다.
지표는 웹 사이트의 품질에 대한 정량적 측정을 정의하는 데 사용됩니다. 기본적으로 달성하고자 하는 성능 목표에 대한 정의이며, 다음을 정의하는 데 사용할 수 있습니다. KPI(주요 성과 지표).
많은 지표를 정의할 수 있지만, 정의하는 지표가 성과 및 동시성 목표를 다루는 경우가 많습니다. 특히, 정량화가 어려울 수 있고 종종 다음과 같은 요인들이 있습니다. 감정 평가:
"웹 사이트는 너무 느림 today" - 언제 느림 선별?
"모두" 서서히 멈추다 내 동료가 로그인할 때" - 시스템이 지원할 수 있는 동시 사용자 수
"검색하면 시스템이 서서히 멈추다 " - 어떤 검색 요청이 시스템에 영향을 줍니까?
"시간이 걸린다 세 파일을 다운로드하려면" - 정상적인 네트워크 조건에서 허용되는 다운로드 시간은 얼마입니까?
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 서버의 서버 메모리(주 메모리 및 하드 드라이브). | 출력 캐시의 페이지 수 및 크기, 페이지당 종속성 수. Dispatcher 캐시는 이 볼륨을 낮춥니다. |
웹 서버 | 웹 서버의 계산 능력. | 요청 수. 캐싱은 이 볼륨을 낮춥니다. |
템플릿 | 웹 서버의 계산 능력. | 템플릿의 복잡성입니다. |
저장소 | 저장소의 성능. | 저장소에서 로드한 페이지 수입니다. |
앞의 섹션에서는 정의할 기본 지표에 대해 자세히 설명합니다.
특정 요구 사항에 따라 위의 분류를 계산하거나 별도로 추가 지표를 정의하는 것이 유용할 수 있습니다.
그러나 웹 사이트의 모든 측면을 측정하고 정의하는 것보다 간단하고 안정적으로 작동하는 작은 정확하고 핵심 지표 세트를 사용하는 것이 좋습니다. 순전히 고유한 특성으로 인해 웹 사이트가 사용자에게 전달되면 변경되고 발전하기 시작합니다.
보안은 중요하고 계속 증가하는 도전입니다. It 필수 프로젝트의 초기 단계부터 고려 및 계획됩니다.
다음 보안 검사 목록 배포 시 AEM 설치가 안전한지 확인하기 위해 수행해야 하는 세부 단계입니다. 다른 보안 측면은에서 다룹니다. 보안(개발 시) 및 사용자 관리 및 보안.
다음을 수행합니다.
표준 AEM 프로젝트의 새 구현의 경우 다음과 같은 작업을 고려하십시오.
모든 측면에서 반복적인 접근 방식을 사용하는 것이 좋습니다.
프로덕션 환경에서 실제 조건에서 조정, 최적화 및 사용자 교육을 허용하려면 프로젝트 출시를 로 분할합니다. 소프트 실행 (가용성 감소, 여러 번 반복) 및 하드 론치 (전체 가용성 - 라이브).
다음을 참조하십시오. 프로젝트 체크리스트 프로젝트의 수명 주기 동안 수행(또는 평가)해야 하는 작업의 예입니다.
각 범주에 대해 몇 가지 주의할 사항은 다음과 같습니다.
개발
먼저 기본 아키텍처를 정의합니다.
개발에 여러 번 반복(sprints)을 사용합니다.
프로젝트 진행 중 사용 가능한 AEM 버전 업데이트의 최종 결과를 계획합니다.
단거리 훈련 중 테스트 및 최적화를 계획합니다.
안정화 및 최적화 단계에 대한 계획.
추가 릴리스를 위해 계획될 항목의 로그를 만듭니다.
파트너 참여 및 인계 계획.
인프라
먼저 기본 아키텍처를 정의합니다.
첫 번째 스프린트 및 초기 구성 준비에 대해 여러 번 반복을 사용합니다.
여러 부하 테스트를 계획합니다.
단거리 훈련 중 테스트 및 최적화를 계획합니다.
안정화 및 최적화 단계를 계획합니다.
가능한 한 빨리 프로덕션 환경에 배포합니다(운영 팀이 환경을 구축하도록 시스템 설정).
명명된 사용자 및 정의된 역할을 가능한 한 빨리 사용하십시오.
교육 계획(예: 관리자 교육).
작전으로의 이관 계획.
콘텐츠
그런 다음 결과 작업 목록에 따라 (높은 수준의) 작업 정의에 대한 초기 시간 및 노력을 예상할 수 있습니다. 이러한 예상 값에는 누가 (고객 또는 파트너)가 무엇을 언제 수행하는지 나타내는 정보가 포함되어야 합니다.
다음 목록은 표준 근사 및 관련된 노력의 상호 관계를 보여 주며, 따라서 원가를 보여 줍니다.
이 수치는 초기 추정치에만 사용할 수 있습니다. 숙련된 AEM 개발자는 세부 분석을 수행해야 합니다.
단계 | 작업량 |
---|---|
개발 | 모든 개발 요구 사항을 포함하는 각 구성 요소 노드에 대해 2~4시간의 대략적인 예상. |
개발자 테스트 | 개발의 15% |
추가 작업 | 개발의 10% |
설명서 | 개발의 15% |
JavaDoc 설명서 | 개발의 10% |
버그 수정 | 개발의 15% |
프로젝트 관리 | 지속적인 프로젝트 관리 및 거버넌스를 위한 프로젝트 비용의 20% |
그런 다음 세부 계획을 통해 가용 자원 또는 필수 자원을 기한 및 비용과 연결할 수 있습니다.
참조 아키텍처는 AEM 아키텍처에 대한 템플릿 솔루션을 제공하기 위해 제공됩니다. 참조 아키텍처는 확장, 안정성, 보안 등 엔터프라이즈 시스템에서 일반적으로 발생하는 문제를 해결합니다.
다음 사이트 지표를 정의해야 합니다.
분류 | 정의 |
---|---|
인터넷 사이트 수 | |
인트라넷 사이트 수 | |
코드 베이스 수(예: 인터넷과 인트라넷이 다른 경우) | |
개별 페이지 수 | |
사이트 방문 횟수 / 일 | |
페이지 조회수 / 일 | |
데이터 전송 볼륨(GB)/일 | |
동시 사용자 수(폐쇄된 사용자 그룹) | |
동시 방문자 수(게시) | |
동시 작성자 수 | |
등록된 작성자 수 | |
페이지 활성화/작업일 수 | |
배포 중 페이지 활성화 수 |
다음 목록은 사용할 수 있는 도구를 알려줍니다. 이는 광범위한 권장 사항 목록이 아니라 소개를 위한 것이며 다른 도구를 사용하지 못하도록 해서는 안 됩니다.
제품 | 설명 |
AEM | AEM은 응용 프로그램을 모니터링, 테스트, 조사 및 디버깅하는 데 도움이 되는 다양한 메커니즘을 제공합니다. |
Selenium | Selenium 는 오픈 소스 테스트 도구입니다. 테스트는 브라우저에서 직접 실행되어 사용자의 작업 방식을 에뮬레이션합니다. |
Microsoft® 프로젝트 | 일반적으로 사용되는 프로젝트 관리 도구입니다. |
지라 | 지라 는 소프트웨어 버그의 세부 정보를 추적 및 관리하기 위한 오픈 소스 도구입니다. 워크플로우는 필요에 따라 버그 세부 사항에 적용할 수 있습니다. |
Git | Git 는 개정 제어 소프트웨어입니다. |
Eclipse | Eclipse는 다양한 프로젝트로 구성된 오픈 소스 IDE입니다. 전체 수명주기에 걸쳐 소프트웨어를 구축, 배포 및 관리하기 위한 확장 가능한 프레임워크, 도구 및 런타임으로 구성된 개방형 개발 플랫폼을 구축하는 데 중점을 두고 있습니다. 다음을 참조하십시오 Eclipse를 사용하여 AEM 프로젝트를 개발하는 방법 추가 정보. |
IntelliJ | 광범위한 기능을 제공하는 전문 IDE(라이센스 비용 부담). 다음을 참조하십시오 IntelliJ IDEA를 사용하여 AEM 프로젝트를 개발하는 방법 추가 정보. |
Maven | Maven 는 프로젝트의 빌드 프로세스(소프트웨어 및 설명서)를 관리할 수 있는 소프트웨어 프로젝트 관리 및 이해 도구입니다. |
또한 다음 섹션이 특히 중요합니다.
Adobe은 모든 단계 및 대상에 대해 추가 모범 사례를 제공합니다.