Windchill Navigate 빌드를 위한 배포 프로세스
배포 프로세스에는 다양한 환경에서 패키지를 제출하고 수준을 올리는 작업이 포함됩니다. 배포 프로세스의 목표는 패키지가 최종 배포 환경에 배포되기 전에 각 단계에서 철저한 테스트 및 유효성 검사를 거치도록 하는 것입니다.
Navigate 배포 프로세스에는 다음 단계가 포함됩니다.
1. 하위 환경에서의 초기 배포
2. 완성도 곡선 단계
3. 생산 환경에서 최종 배포
팀에서 현재 요구 사항에 따라 사용 사례를 선택한 다음 해당 사용 사례를 스프린트 주기에 통합하는 시나리오를 살펴보겠습니다. 이 프로세스에는 다양한 단계를 거치며 패키지를 제출하고 수준을 올리는 과정이 포함됩니다. 처음에는 패키지를 제출하여 하위 환경에 패키지를 배포합니다. 패키지는 완성도 곡선 단계에서 수준이 올라갑니다. 수준은 최종 배포 단계에서 최종적으로 올라갑니다.
자세한 프로세스 설명
1. 첫 번째/초기 빌드 배포 - PTC가 고객으로부터 받은 초기 빌드 배포는 PTC 팀의 철저한 검토를 거칩니다. 이 검토에 필요한 아티팩트는 다음과 같습니다.
◦ 완성된 설문지: 고객이 작성한 상세한 설문지입니다.
◦ 빌드 패키지: 고객/시스템 통합자가 제출한 압축 패키지입니다.
 | 초기 빌드는 PTC 팀에서 승인하고 필수 지침을 준수하는지 확인된 경우에만 다음 단계로 진행됩니다. |
2. 완성도 곡선 단계 - 이 단계에서는 PTC 팀의 승인이 필요하지 않습니다. 이 단계에서 빌드는 완성도 곡선에 따라 진행되며 여기에는 다음 임무가 포함됩니다.
◦ 버그 수정: 문제를 식별하여 해결합니다.
◦ 로직 변경: 빌드의 기능을 구체화합니다.
◦ UAT(사용자 인수 테스트): 빌드가 사용자 요구 사항을 충족하는지 확인합니다.
◦ 코스메틱 변경: 사용자 인터페이스 및 경험을 조정합니다.
초기 배포는 비생산 환경에서 수행됩니다. 고객 또는 시스템 통합자는 빌드의 모든 변경 내용을 문서화하여 철저하게 관리할 책임이 있습니다.
| | 이 프로세스를 진행하는 동안 빌드 패키지와 (타사 라이브러리에 대한) 빌드 종속성에서 다루는 요구 사항이 변경되지 않는 것이 중요합니다. 어떠한 변경이 발생하면 배포 프로세스를 다시 시작해야 합니다. |
3. 생산 환경에서 최종 빌드 배포 - 제품 서버에서의 최종 배포는 PTC 팀에서 종합적으로 철저하게 검토합니다. 검토 과정을 거치면서 빌드가 생산 환경으로 릴리즈되기 전에 빌드의 모든 측면이 최고 수준의 품질, 기능 및 규정 준수 표준을 충족하는지 확인합니다. 검토에 필요한 아티팩트는 다음과 같습니다.
◦ 완성된 설문지: 고객이 작성한 상세한 설문지입니다.
◦ 빌드 패키지: 고객/시스템 통합자가 제출한 압축 패키지입니다.
◦ 세부 설명서: 완성도 단계를 거치며 빌드에 적용된 모든 변경 내용에 대한 포괄적인 설명서입니다. 자세한 내용은 전체 설명서 작성: 주요 지침 섹션을 참조하십시오.
| | 이 단계에는 PTC 팀의 승인이 필요합니다. |
고객을 위한 지침
• 요구 사항의 일관성 - 업로드하는 초기 빌드에 중요한 콘텐츠가 모두 들어 있어야 합니다. 시스템 통합자는 두 배포 단계(1단계 및 3단계)에서 요구 사항 또는 (특히, 타사 라이브러리에 대한) 종속성에 중대한 변경이 발생하지 않도록 해야 합니다.
• 철저한 문서화 - 빌드의 모든 수정 사항을 종합적으로 문서화해야 합니다.
• PTC 팀 검토 - PTC 팀은 생산 환경에 최종적으로 배포할 수 있도록 빌드의 수준을 올리기 전에 모든 변경 사항을 검토합니다.
이러한 지침을 준수하면 Windchill Navigate 빌드를 위한 배포 프로세스를 안전하고 안정적으로 유지할 수 있습니다.
배포 프로세스는 얼마나 자주 반복해야 합니까?
사용자 정의를 진행할 때 여러분은 구체적인 사용 사례를 염두에 두고 있으며 개발 팀에서는 스프린트 주기로 작업합니다. 여러분 팀에서는 사용 사례를 선택하고 스프린트 주기로 개발을 시작하는데, 이때 사용 사례는 한 가지 요구 사항일 수도 있고 일련의 요구 사항이 될 수도 있습니다. 빌드를 준비하는 데 여러 번의 스프린트 주기를 진행해야 할 수도 있습니다.
예를 들어, 스프린트 5개로 구성된 6개월 릴리즈 주기에서 요구 사항은 스프린트 내에서 선택되고 개발됩니다. 개발, QA 및 배포 단계로 구성되는 20일 스프린트와 같이 여러 일정이 있을 수 있습니다. 주기를 진행하는 과정에서 요구 사항이 크게 변경되면 프로세스를 다시 시작해야 하며 승인이 필요합니다.
배포 프로세스의 빈도는 사용 사례 수 및 스프린트 주기에 따라 달라집니다. 예를 들어, 10가지 사용 사례를 스프린트 주기 10회를 거치며 개발하는 경우 배포 프로세스는 10회 진행됩니다. 5가지 사용 사례를 스프린트 주기 1회로 개발하는 경우 배포 프로세스는 2회 진행됩니다.
추가 예제:
1. 예제 1: 더 짧은 스프린트 주기
◦ 2주 스프린트 주기가 있습니다. 요구 사항을 선택하여 10일 동안 개발하고 2일 동안 QA를 진행한 다음 배포합니다. 6가지 요구 사항이 있으면 12주 동안 배포 프로세스를 6회 진행합니다.
2. 예 2: 중첩 요구 사항
◦ 여러 스프린트에 걸쳐 있는 중첩되는 요구 사항이 있습니다. 예를 들어, 완료하는 데 스프린트 3개를 거치는 요구 사항은 각 스프린트마다 배포 프로세스를 한 번씩 진행하면서 지속적으로 통합하고 테스트합니다.
3. 예 3: 주기 중반의 중요한 변경
◦ 주기가 진행되는 중간에 데이터 모델 변경과 같이 요구 사항이 크게 변경되는 경우에는 프로세스를 다시 시작해야 합니다. 이렇게 하면서 모든 종속성이 재평가되고 승인을 받습니다.
4. 예 4: 빈번한 배포
◦ 빈번한 배포를 선호하며 스프린트 주기가 1주일입니다. 4일 동안 개발하고 1일 동안 QA를 수행하고 마지막 날에 배포합니다. 8가지 요구 사항이 있으므로 8주 동안 배포 프로세스를 8회 진행합니다.
5. 예 5: 사용자 지정 일정
◦ 프로젝트 요구 사항에 맞춰 사용자 지정 일정을 설정합니다. 예를 들어, 개발에 20일, QA에 5일, 배포에 5일이 걸리는 30일 간의 스프린트 주기가 있을 수 있습니다. 프로세스 빈도는 요구 사항의 수와 복잡성에 따라 조정합니다.
설문지에는 어떤 정보가 포함되어 있습니까?
배포 프로세스 중에 설문지 두 개를 작성해야 합니다.
1. 초기 배포 설문지 - 이 설문지는 하위 환경에서 처음 배포에 필요합니다. 이 설문지를 작성하면서 계속 진행하기 전에 모든 예비 확인 및 구성이 완료되었는지 확인합니다.
2. 최종 배포 설문지 - 이 설문지는 생산 환경에서 최종 배포에 필요합니다. 이 설문지를 작성하면서 모든 중요한 측면이 검토 및 승인되었는지 확인하여 원활하고 성공적으로 배포할 수 있도록 합니다.
다음은 설문지의 예입니다.
질문 | 답변 | |
|---|---|---|
일반적인 세부 내용 | 고객 계정 이름 | |
사용 중인 Windchill 버전 | ||
사용 중인 Windchill Navigate 버전 | ||
계획된 배포 날짜 | ||
계획된 배포 환경 | ||
패키지 세부 정보 | 이 패키지를 하위 환경에서 테스트해 보셨습니까? (테스트한 경우 환경 이름을 적어주십시오.) | |
어떤 유형의 사용자 정의를 구현했습니까? | ||
이 패키지에 사용되는 타사 라이브러리가 있습니까? | ||
기본 인증 방법을 사용하고 있습니까? 아니면 이 패키지에서는 앱 키를 사용합니까? | ||
이러한 사용자 정의를 통해 처리하려는 비즈니스 사례 또는 목표는 무엇입니까? | ||
사용자 정의 부분 중에 가드레일을 위반하는 부분이 없는지 확인했습니까? | ||
이전 패키지와 새 패키지(있는 경우)의 차이점은 무엇입니까? |
| | 이 설문지에서는 이전 패키지와 새 패키지의 차이점을 기술해야 합니다. 예를 들어 추가된 새로운 기능, 수정된 버그 또는 버전 번호 변경 사항이 있는지 설명할 수 있습니다. 이러한 차이점을 파악하는 것은 배포 프로세스에 관련된 모든 사람이 변경된 내용을 이해하는 데 도움이 되기 때문에 중요합니다. 이를 통해 문제를 방지하고 호환성을 보장하며 새 패키지가 모든 요구 사항을 충족하는지 확인할 수 있습니다. |
전체 설명서 작성: 주요 지침
생산 환경에서 배포할 최종 빌드를 제출할 때 완성도 단계를 진행하면서 수행된 모든 변경 내용에 대한 포괄적인 설명서를 포함하는 것이 중요합니다. 이 설명서에는 개발 프로세스 전반에 걸쳐 발생한 모든 업데이트, 기능 추가, 버그 수정 및 개정 사항이 자세히 설명되어 있어야 합니다.
꼼꼼한 설명서를 제공하면 모든 이해 관계자가 변경 내용을 파악할 수 있으므로 문제를 해결하고 일관성을 유지하며 빌드가 모든 요구 사항을 충족하는지 확인하는 데 도움이 됩니다. 이 단계는 원활하고 성공적인 배포를 위해 필수적이며 오류가 발생할 가능성을 최소화하고 생산 환경이 새 빌드에 꼭 맞춰 준비되도록 할 수 있습니다.
다음 시나리오를 살펴보십시오.
일반적으로 빌드 주기는 버전 1.0부터 시작합니다. 이후 단계에서 빌드를 개정할 때 1.1, 1.2 등과 같은 버전으로 업데이트할 수 있습니다. 생산 서버에 빌드를 배포할 준비가 될 때쯤이면 빌드가 여러 번 개정되어 최종 버전은 1.7 등이 되어 있을 수 있습니다.
각 개정 중에 수행된 변경 사항에 대한 자세한 기록을 유지 관리해야 합니다. 예를 들어, 5개 항목을 변경하는 경우 해당 변경을 명확하게 문서화합니다. 이 설명서는 릴리즈 정보 형식일 수 있으며 제품에 따라 설명서의 양이 달라집니다.
예를 들어 설명서에는 다음과 같은 내용이 포함될 수 있습니다.
• 버전 1.4.6: 특정 문제를 처리하기 위한 수정 사항이 추가되었습니다.
• 버전 1.4.5: 새로운 기능을 구현했습니다.
• 버전 1.4.4: 특정 기능에 대한 성능이 향상되었습니다.
이 유형의 설명서는 버전 1.0에서 1.7까지의 빌드 과정을 추적하는 데 유용합니다. 스크린샷이나 관련 정보를 가장 잘 전달하는 형식이라면 어떤 것이든 사용할 수 있습니다. 핵심은 변경 내용을 포괄적으로 추적할 수 있도록 하는 것입니다. Word 문서, Excel 시트 또는 다른 방법을 사용하든 관계없이 필요에 맞는 형식을 고안해 사용할 수 있습니다.
변경 로그의 예는 다음과 같습니다.
예 1 - 간결한 변경 로그: 빠른 참조를 위한 한 줄 요약
예 2 - 상세 변경 로그: 전체 업데이트 목록
예 3 - 전체 변경 로그: 업데이트, 수정 사항 및 개선 사항을 모두 포함하여 컴파일
