패키지 제출 및 수준 올리기
CCD 패키지가 준비되면 자동화된 빌드 배포를 사용하여 계속 진행합니다. 자동화된 빌드 배포 프로세스에는 사용자의 권한 및 환경과 일치하는 구성 및 사용자 정의 수준 올리기를 오케스트레이션하는 작업이 포함됩니다.
CCD 패키지와 매니페스트 파일을 저장소 계정의 해당 위치에 업로드하여 빌드를 제출할 수 있습니다. 먼저 /data/builds에 CCD 패키지를 업로드해야 합니다. 그런 다음 /data/builds/deploy에 매니페스트 파일을 업로드해야 합니다.
이 작업을 수행하면 자동화된 빌드 배포 워크플로가 트리거됩니다. 프로세스는 이메일로 수신된 알림 임무를 통해 진행됩니다. 이메일의 정보에 따라 다양한 단계를 수행할 수 있습니다. 임무 승인자는 매니페스트 파일에서 선언됩니다. 매니페스트 파일의 예는 자동화된 배포 트리거 항목에서 확인할 수 있습니다.
 |
다음 사항을 전제 조건으로 고려합니다.
• Azure BLOB Storage 위치를 설정해야 합니다. 인증 세부 정보는 PTC 클라우드에서 얻어야 합니다.
◦ PTC는 이 활동에 대한 SAS URL을 제공합니다.
◦ IP 주소를 허용 목록에 포함시키려면 PTC 지원 포털에 요청을 제출해야 합니다. 사례 세부 정보에서 안정적인 IP 주소를 제공합니다.
• 파이프라인이 매니페스트 파일에 언급된 값과 일치하게 구성되도록 요청을 제출해야 합니다. 예는 int1 또는 pipeline1입니다. deploy_pipe 속성에 대한 자세한 내용은 자동화된 배포 트리거 항목의 매니페스트 파일 만들기 섹션을 참조하십시오.
|
자동화된 빌드 배포 워크플로의 첫 번째 단계는 CCD 패키지를 검사하는 것입니다. 시스템은 CCD 패키지를 검사하여 Windchill+ 지침을 준수하는지 확인합니다. 검사 후 시스템은 보고서를 생성하고 저장소 계정에서 사용할 수 있도록 합니다.
/data/builds/logs/<RITM Number>/에서 보고서 및 로그를 찾을 수 있습니다. 생성된 보고서 및 로그 파일의 구문은 다음과 같습니다.
• 보고서 구문 - cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html. 여기서 <Control Label>은 IntakeProcessor, SpotBugs, Logs 등이 될 수 있습니다.
• 로그 구문 - ccd_<environment>_<Date-Time>_<ant target>_Logs.zip. 여기서 <ant target>은 deploy, load 등이 될 수 있습니다. 자세한 내용은 Targets를 참조하십시오.
|
보고서 이름
|
구현된 확인
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Windchill+ 확인(Windchill+에서 허용된 사용자 정의, 사용 중단, 지원되지 않는 API, 보안)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
정적 코드 확인(Java 모범 사례)
|
다음 사항을 고려하십시오.
• CCD 패키지가 확인에 실패하면 알림이 전송되고 제출 프로세스가 중단됩니다.
• CCD 패키지가 규제를 준수하면 프로세스가 계속되고 매니페스트 파일에 정의된 대상으로 빌드 수준이 올라갑니다.
• 빌드 배포가 성공하면 7일 내에 테스트를 완료해야 합니다.
|
|
고객인 사용자는 CCD 패키지 콘텐츠를 담당합니다. 빌드를 제출하면 사용자가 해당 개발이 PTC 보안 지침을 준수하여 수행되었음을 인증하는 것입니다. PTC 보안 지침에 대한 자세한 내용은 보안 사용자 정의 지침을 참조하십시오.
|
CCD 패키지 작성을 위한 Windchill+ 가드레일
CCD 패키지 및 해당 작성은 특정 디렉터리 구조를 준수해야 합니다. CCD 패키지의 디렉터리 구조 및 파일 내용에 대해 지정된 가드레일을 따릅니다.
• CCD 패키지의 크기는 100MB를 초과하지 않아야 합니다.
• CCD 패키지에는 다음 폴더가 포함될 수 있습니다.
|
폴더
|
설명
|
|---|---|
|
Configurations
|
없음 또는 Configurations 폴더 하나
|
|
Generated
|
없음 또는 Generated 폴더 하나
|
|
customlib
|
없음 또는 customlib 폴더 하나
|
|
<custom module(s)>
|
하나 이상의 사용자 정의 모듈 폴더
|
|
|
CCD 패키지에는 네 폴더 중 하나 이상의 폴더가 있어야 합니다.
|
• descriptor.xml 파일은 CCD 패키지의 모든 사용자 정의 모듈 폴더에 있어야 합니다.
• Generated 폴더는 비어 있거나 다음 폴더 중 하나 또는 둘 다를 포함할 수 있습니다.
◦ db 폴더 - db 폴더는 비어 있을 수 있습니다. 그렇지 않으면 db/conf/SchemaConfig.xml 파일이 포함되어야 합니다.
◦ BAC 폴더 - BAC 폴더에는 BAC.zip 파일 하나만 허용됩니다. BAC 매핑은 BAC 폴더에 있는 Mapping.xsl 파일에 제공될 수 있습니다.
◦ 파트너 IP jar 파일이 있다면 customlib에 저장해야 합니다.
• 허용되는 제공 값은 plusselect 및 meddev입니다.
• CCD 패키지에는 다음 규칙에 따라 차단된 파일이나 예기치 않은 파일이 없어야 합니다.
◦ 패키지에 사용할 수 없는 파일 목록 - .jar, .class, .exe, .ser, .sql, .ddl, .pks, .pkb, .ora, .jasper, .cs, .cpp, .so, .dll, .jnilib, .dylib, .h, .cgf, .out, .ldif, .sh,.pl, .groovy, .gwt.xml, .gwt.modules.xml
◦ xconf 폴더 내의 유효한 파일 - .xconf
◦ conf 폴더 내의 유효한 파일 - .xml, .ini
◦ resources 폴더 내의 유효한 파일 - .tpl, .bas, .ddx, .html, .yml, .xjb, .ftl, .xml, .dtd, .xsl, .properties, .txt, .ini, .json, .js
◦ src 폴더 내의 유효한 파일 - .java, .rbInfo
◦ jsp 폴더 내의 유효한 파일 - .jsp, .jspf
◦ tags 폴더 내의 유효한 파일 - .tag, .tagf
◦ tlds 폴더 내의 유효한 파일 - .tld
◦ src_web 폴더 내에서 사용할 수 없는 파일 - .java
◦ JasperReports 폴더의 유효한 경로 - module/main/resources 및 module/main/src_web(구성 수준에서는 유효하지 않음)
◦ 리소스 경로의 JasperReports 폴더 내에 있는 올바른 파일 - .jrxml, .jasperProperties 및 .properties
◦ src_web 경로의 JasperReports 폴더 내에서 유효한 파일 유형 - .gif
◦ customlib 폴더 내의 유효한 파일 - .jar
◦ 다음 폴더에는 이름이 apps인 폴더가 허용되지 않습니다.
▪ configurations/resources
▪ main/resources
▪ main/src_web
이러한 가드레일은 배포를 위해 패키지를 제출할 때 확인됩니다. 모든 비준수가 보고됩니다. 배포 로그에는 RITM 요약 보고서(예: RITM0910921.txt)가 포함됩니다. 이 보고서는 패키지가 Windchill+ 가드레일을 준수하는지 여부를 요약합니다. RITM 요약 보고서의 예는 다음과 같습니다.
이러한 가드레일 확인 세부내용이 포함된 자세한 보고서 zip 파일에서 RITM 세부 로그를 찾을 수 있습니다. 이 zip 파일에는 가드레일 확인 세부내용을 제공하는 로그 파일이 포함되어 있습니다.
zip 파일의 예는 RITM0910921_Reports.zip입니다.
로그 파일의 예는 preValidate_20240402-142645.log입니다.
| | 이러한 규칙은 강제되지는 않지만 편차를 기록하고 적극적으로 수정해야 합니다. PTC는 이러한 규칙 중 일부를 이후에 적용할 것이며 규칙을 준수하지 않을 경우 이후 패키지가 유효하지 않게 될 수 있습니다. 허용되지 않는 사용자 정의 및 경고에 대한 자세한 내용은 허용되지 않는 사용자 정의를 참조하십시오. |
생산 운영 이전
품질 보증(QA) 환경 없이 Windchill+를 사용할 수 있습니다. 고급 Windchill+를 QA 환경과 함께 사용할 수도 있습니다. 시나리오에 따라 다음 방법에서 설명한 단계를 수행할 수 있습니다.
QA 환경을 사용한 고급 Windchill+
품질 보증(QA) 환경을 사용하며 고급 Windchill+를 사용하는 경우 다음 단계를 수행합니다.
1. 통합 및 기능 인수 테스트 주기에 대한 통합 환경에 패키지를 제출합니다. 이 테스트 주기를 자주 트리거할 수 있습니다. 예를 들어, 1주일에 여러 번입니다.
◦ deploy_pipe : int을 사용하여 빌드 및 매니페스트 파일을 제출합니다.
자세한 내용은 코드 및 구성 패키지 배포를 참조하십시오.
◦ 테스트 주기를 완료합니다. 테스트 주기가 종료되면 임무가 완료된 것으로 간주되고 환경은 이전 상태로 되돌아갑니다.
| | 이 단계가 7일 이내에 완료되지 않으면 환경은 자동으로 이전 상태로 되돌아갑니다. |
2. 패키지를 UAT를 위한 QA 환경에 제출한 다음 패키지를 생산 환경으로 수준을 올립니다. 이 프로세스는 빌드를 생산 환경으로 수준을 올리므로 UAT 테스트 주기는 1개월에 한 두 번 트리거하는 것이 좋습니다.
◦ 테스트 주기를 완료합니다. 다음 사항을 고려하십시오.
▪ 테스트 주기가 성공적인 경우, 임무가 승인되고 빌드가 생산 환경으로 수준이 올라갑니다.
▪ 테스트 주기가 성공적이지 않은 경우, 임무가 거부되고 환경이 이전 상태로 되돌아갑니다.
▪ 테스트 주기가 7일 이내에 완료되지 않으면 환경은 이전 상태로 되돌아갑니다.
QA 환경이 없는 기본 Windchill+
품질 보증(QA) 환경 없이 기본 Windchill+ Select를 사용하는 경우 다음 단계를 수행하십시오.
2. 통합 및 기능 인수 테스트 주기를 완료합니다. 테스트 주기가 종료되면 임무가 완료되고 환경은 이전 상태로 되돌아갑니다.
| | 이 단계가 7일 이내에 완료되지 않으면 환경은 이전 상태로 되돌아갑니다. |
4. 통합 환경에서 사용자 인수 테스트 주기를 완료합니다. 다음 사항을 고려하십시오.
◦ 테스트 주기가 성공적인 경우, 임무가 승인되고 빌드가 생산 환경으로 수준이 올라갑니다.
◦ 테스트 주기가 성공적이지 않은 경우, 임무가 거부되고 환경이 이전 상태로 되돌아갑니다.
◦ 테스트 주기가 7일 이내에 완료되지 않으면 환경은 자동으로 이전 상태로 되돌아갑니다.
| | 모든 테스트 활동은 하나의 환경만 사용합니다. 한 번에 하나의 테스트 활동만 수행할 수 있습니다. 이 기간 동안 deploy_pipe : int를 사용하여 빌드를 제출하면 자동으로 거부됩니다. |
Go-Live 단계
Go-Live 단계를 확인한 후에는 생산 환경을 QA 및 통합 환경으로 재호스팅해야 합니다.
PTC 지원 포털에서 이 활동에 대한 서비스 요청을 열어야 합니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
실행 상태
• Go-Live가 성공적으로 완료된 후 모든 환경이 생산 환경에서 재호스팅됩니다. 따라서 변경을 개발 환경에 전파하는 것이 좋습니다. 권장되는 접근 방식은 BAC를 사용하고 통합 환경에서 전체 BAC 패키지를 내보내는 것입니다. 자세한 내용은 CCD 유틸리티를 사용하여 BAC 패키지 가져오기를 참조하십시오.
다음 사항을 고려하십시오.
◦ 데이터 모델은 시스템(유형 및 속성 매니저)을 다시 빌드하기 위해 반드시 내보내야 합니다.
◦ BAC에서 지원되지 않는 객체의 경우, UI를 통해 통합에서 내보내거나(가능한 경우) 개발 환경에서 로드파일을 다시 만들 수 있습니다.
• 그 후에는 제출 주기가 패키지 제출 및 수준 올리기 항목의 생산 운영 이전 섹션에 언급된 것과 유사하게 됩니다.
• 주 생산 운영 이후 생산 환경을 QA 및 통합 환경으로 재호스팅해야 합니다. 재호스팅 활동을 위해서는 서비스 요청을 열어야 합니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
| | • 최초 Go-Live가 성공적으로 완료된 후에는 생산 환경에서 모든 환경(개발 환경 제외)을 재호스팅해야 합니다. 재호스팅은 자동으로 수행되지 않으며 서비스 요청이 필요합니다. • 최초 Go-Live는 응용 프로그램을 생산 환경에 처음으로 배포하는 것을 의미합니다. 이 단계에서는 모든 하위 환경이 생산 환경과 동기화되어 배포 범위 전반에서 일관성과 안정성을 보장합니다. • 주 Go-Live는 최초 Go-Live 이후 생산 환경에 대한 모든 후속 릴리즈를 나타냅니다. 이러한 릴리즈는 진행 중인 개발 및 배달 주기의 일부로, 일반적으로 새로운 기능, 개선 사항 또는 수정 사항을 포함합니다. |