IBM® UrbanCode Release에서 신속한 프로덕션을 준비하려면 다음 주제를 순서대로 검토하십시오.
릴리스 계획은 해당 범위에 대한 몇 가지 기본 질문에 응답하는 것을 의미합니다. 전체적으로 새 릴리스입니까? 또는 릴리스가 이전에 정의된 계획을 사용합니까? 어쩌면 기존 릴리스를 거의 변경할 필요가 없는 부 릴리스(예: 패치)입니까? 이러한 질문에 대한 응답은 프로덕션에 대한 경로 및 기존 릴리스를 다시 사용할 수 있는지 여부, 다시 사용할 수 있다면 어느 정도까지 등을 판별합니다.
릴리스 열차에 대한 입력이 동기화되고 개방된 팀 기반 계획에서 오는지 확인하십시오. 목표는 분명하게 연결된 인도물 및 상호 종속성 세트를 정의하는 것입니다.
프로덕션에 대한 경로는 최종 단계(phase)인 프로덕션으로 종료되는 일련의 단계(phase)를 나타냅니다. 가장 단순한 형태로서 단계(phase)는 하나 이상의 환경 및 품질 요구사항을 나타냅니다. 단계는 품질 상태 및 게이트와 같은 추가 항목도 가질 수 있습니다.
단계의 진행은 라이프사이클 모델에 의해 정의됩니다. 릴리스를 작성하면 이에 사용 가능한 단계(phase)가 해당 릴리스에 대해 선택된 라이프사이클 모델에 정의됩니다. 필요한 단계(phase)가 라이프사이클에 정의되지 않은 경우 모델을 수정하거나 완전히 새 모델을 작성할 수 있습니다. IBM UrbanCode Release는 적절하게 수정할 수 있는 기본 라이프사이클을 제공합니다.
다음 그림은 동일한 라이프사이클 모델을 사용하는 두 개의 릴리스(10월과 11월)를 나타냅니다. 이 모델에 정의된 단계(phase)가 맨 위에 나열되어 있습니다. 릴리스에 환경이 할당되고 각 단계(phase)는 그림에 표시된 대로 환경이 지정됩니다. 예를 들어, 10월 릴리스는 DEV 단계 동안 DEV-1 환경을 사용하는 반면에, 11월 릴리스는 해당 단계 동안 DEV-2를 사용합니다. 단계 사이의 게이트가 모델에 정의되어 있습니다.
라이프사이클은 릴리스 수에 관계없이 사용될 수 있습니다. 환경 및 애플리케이션을 변경하여(릴리스 간에 애플리케이션의 정렬이 서로 다른 점을 참고) 동일한 라이프사이클에서 만일의 경우를 위해 릴리스를 작성할 수 있습니다. 라이프사이클이 특정 릴리스에 적합하지 않은 경우, 예를 들어, 너무 많은 단계가 있거나 충분하지 않은 경우, 언제든지 새 라이프사이클을 작성할 수 있습니다.
IBM UrbanCode Release를 사용하여 사전 프로덕션과 프로덕션 사이에 트랙을 놓고 트랙을 따라 확실하게 릴리스를 실행할 수 있습니다. 릴리스 열차는 모든 차량 유형(자동, 수동 및 임시 프로세스)별로 프로비저닝될 수 있으며 모든 화물 유형을 운반할 수 있습니다. 릴리스 열차의 예측 가능한 스케줄이 릴리스 프로세스를 수행합니다. IBM UrbanCode Release를 사용하여 팀 기반 계획을 통합 및 동기화하여 분명하고 개방적이며 투명한 계획에 도달하게 할 수 있습니다. 모든 이해당사자가 이 스케줄 및 주요 마일스톤을 인식하고 릴리스가 스케줄대로 출발하여 제시간에 도착하는지 확인할 수 있습니다.
엄밀히 말해서 릴리스 작성은 웹 사용자 인터페이스를 사용하여 이름을 부여하고 라이프사이클 및 팀을 선택하는 것을 의미합니다. 일반적으로 이는 주 릴리스인지 또는 부 릴리스인지 판별하는 것을 의미합니다. 경험적으로 부 릴리스는 기존 환경 및 애플리케이션 또는 해당 애플리케이션의 서브세트를 사용할 수 있는 릴리스이고, 주 릴리스의 경우 새 환경 및 애플리케이션이 필요합니다.
애플리케이션이 필요하지 않더라도(전체 마일스톤 및 인프라 관련 태스크로 구성된 릴리스를 작성할 수 있음) 대부분의 릴리스는 단연코 애플리케이션 배치를 포함합니다. 애플리케이션은 IBM UrbanCode Deploy와 같은 외부 도구와의 통합에서 제공되거나 IBM UrbanCode Release 자체 내에서 작성될 수 있습니다. 각 릴리스는 사용 가능한 IBM UrbanCode Release에 정의된 모든 애플리케이션을 가집니다. 많은 애플리케이션을 릴리스와 연관시킬 수 있습니다.
IBM UrbanCode Release와 외부 도구의 통합에 대한 정보는 통합 제공자 구성의 내용을 참조하십시오.
릴리스에 사용할 수 있는 단계(phase)는 선택된 라이프사이클에서 정의됩니다. 라이프사이클 모델을 릴리스를 작성하고 실행하는 데 사용되는 템플리트로 생각하면 도움이 될 수 있습니다. 라이프사이클은 프로덕션(프로덕션 단계 또는 유사하게 지정된 최종 단계로 표시됨)으로 이동할 때 소프트웨어가 통과하는 단계(phase)의 진행 순서를 정의합니다. 라이프사이클은 릴리스에 사용된 특정 환경을 지정하지 않지만 일반 패턴을 지정합니다. 예를 들어, 라이프사이클은 개발, 품질 보증 및 프로덕션의 단계(phase)를 가질 수 있습니다. 사용된 실제 환경이 릴리스마다 다를 수 있기는 하지만 이 라이프사이클에 기반하는 릴리스는 모두 세 개의 단계(phase)를 가집니다. 라이프사이클은 또한 게이트라는 품질 단계도 정의할 수 있으며, 이 단계가 완료되어야만 소프트웨어가 다음 단계(phase)로 진행될 수 있습니다.
각 단계(phase)에 적합한 전략을 개발합니다. 높은 의식(ceremony) 프로덕션 배치 전략은 낮은 의식(ceremony) 환경에 적합하지 않을 수 있습니다.
프로덕션에 대한 경로를 정의하는 첫 번째 단계는 기존 라이프사이클 모델이 사용될 수 있는지 여부 또는 완전히 새 라이프사이클 모델이 필요한지 여부를 판별하는 것입니다. IBM UrbanCode Release에서 새로 시작하려면 당연히 일반 프로세스 및 환경을 미러링하는 라이프사이클을 작성해야 합니다. 경험이 쌓이면 릴리스의 전부는 아니더라도 대부분을 처리할 수 있는 안정적인 라이프사이클을 개발합니다. 따라서 프로덕션에 대한 경로를 정의하는 데 필요한 활동은 주로 적합한 라이프사이클의 가용성에 의해 결정됩니다. 다음 표는 재사용 가능한 라이프사이클이 다양한 활동에 사용 가능한지 여부를 나타냅니다.
활동 | 설명 |
---|---|
1. 라이프사이클 단계(phase) 이름을 지정하십시오. | 환경이 단계(phase)에 맵핑됩니다. |
2. 상태를 정의하십시오. | 상태는 사용자 정의 값(예: "패스됨" 또는 "아카이브됨")입니다. |
3. 게이트를 추가하십시오. | 게이트는 항목이 게이트 지정 상태를 가진 경우를 제외하고는 단계(phase)/환경으로 배치될 수 없도록 하는 메커니즘입니다. 게이트는 단계(phase)에 대한 최소 입장 요구사항을 설정합니다. |
활동 | 설명 |
---|---|
1. 단계(phase)에 환경을 할당하십시오. | 각 라이프사이클 단계(phase) 중에 사용될 환경을 식별하십시오. 릴리스 환경은 배치 대상을 나타내는 사용자 정의 구조이며 배치 환경을 집계합니다. |
2. 승인을 정의하십시오. | 승인은 품질(상태) 고려사항에 관계없이 환경을 제어하는 데 사용되는 메커니즘입니다. 승인자는 역할에 의해 지정됩니다. 지정된 역할을 가진 모든 사용자가 승인을 제공할 수 있습니다. |
3. 배치 계획을 선택하십시오. | 배치 계획은 특정 단계(phase)의 성공적인 배치에 필요한 편성 및 협업을 정의합니다. |
릴리스 환경에 대한 배치를 스케줄링하여 알려진 프로덕션 및 사전 프로덕션 날짜를 기록하고 전달할 수 있습니다.
날짜는 새 배치가 스케줄될 때 정의됩니다(
).예측 가능한 간격으로 반복되는 배치에 대해 반복되는 창 또는 반복되는 배치가 작성됩니다. 반복되는 창은 매시간, 매일, 매주 또는 일부 cron 표현식에 의해 트리거될 수 있습니다.
마일스톤은 릴리스가 트랙에 남아 있으려면 완료되어야 하는 활동(일반적으로 프로세스 체크리스트 항목)입니다. 마일스톤은 시무식, 운영 체제 업그레이드 또는 하드웨어 및 네트워크 업그레이드와 같이 추적이 필요한 항목을 나타냅니다. 마일스톤은 날짜 및 상태로 추적됩니다.
마일스톤은 릴리스 자체에 첨부되며 특정 단계(phase) 또는 환경에 첨부되지 않습니다. 마일스톤은 릴리스 페이지( )에서 작성됩니다.
계획 중에 식별된 기능에 집중하는 경향이 있을 수 있지만, 범위를 다시 지정하거나 그렇지 않으면 릴리스 열차의 스케줄에 영향을 주는 잠재적 변경사항에 대한 경고를 남겨 둡니다.
릴리스 팀은 릴리스를 관리합니다. 팀은 IBM UrbanCode Release 보안 시스템에 구성된 역할 및 사용자로 구성됩니다. 릴리스에는 해당 릴리스에 대해 구성된 하나 이상의 역할이 있어야 합니다. 일반 역할은 관리자, 릴리스 관리자 및 사용자입니다. 모두 기본적으로 사용 가능합니다. 역할은 다시 사용될 수 있습니다.
역할은 역할 페이지( )에서 정의됩니다.
승인은 품질(상태) 고려사항에 관계없이 환경을 제어하는 데 사용되는 메커니즘입니다. 승인이 필요한 릴리스는 승인이 부여될 때까지 단계(phase)를 진행할 수 없습니다. 승인은 단계(phase)에 첨부됩니다. 승인자는 역할에 의해 지정됩니다. 지정된 역할을 가진 모든 사용자가 승인할 수 있습니다.