T-Tiger

(1) CTS (Change and Transport System)

SAP 시스템은 보통 개발-검증-운영 3 Landscsape로 구성됩니다. (경우에 따라 검증 시스템이 빠져서 2 Landscape로 구성할 수 있습니다. 물론 권장사항은 아닙니다.)

이때 개발 시스템에서 개발한 ABAP 프로그램 같은 것들을 운영 시스템에 반영해야 할 때가 찾아옵니다. 이럴 때에 쓰이는 것이 CTS 입니다. Change and Transport System의 말 그대로 변경사항을 관리해주는 시스템인 것이지요. 여기서 Target을 말하자면, 개발 시스템의 Target 시스템은 검증 시스템이고, 검증 시스템의 Target 시스템은 운영 시스템인 셈입니다.

(2) TMS (Transport Management System)

CTS 안에는 TMS라고 하는 관리 시스템이 있습니다. 이 TMS를 사용해서 Transport Domain을 생성/관리하고, System Landscape를 구성/관리할 수 있습니다.

Transport Domain이란 쉽게 말해, 변경사항을 적용할 수 있는 그룹을 말합니다. 이 Transport Domain 내에 있는 시스템끼리만 변경사항 적용이 가능한 것이지요.

TMS를 더 자세히 알아보기 위해 T-Code STMS를 실행해주세요.

STMS 메뉴 중에 Transport Routes 버튼을 클릭합니다.

아래 그림과 같이 저의 시스템은 3 Landscape 이며, TEP가 진짜 저의 시스템이고, VIR과 PRD는 Virtual System으로 실체 없는 허상입니다.

자 위의 캡쳐를 보면 Transport Layer, Delivery라고 되어 있는 것이 있지요?

개발 시스템인 TEP에서 검증 시스템인 VIR로 가는 것에는 Transport Layer로 연결되어 있고, 검증 시스템에서 운영 시스템인 PRD로 가는 것에는 Delivery로 연결되어 있습니다.

이건 무엇을 의미할까요?

우선 개발 시스템에서 오브젝트를 변경하면 Change Request를 통해 검증 시스템으로 넘어갑니다. 이때 변경한 오브젝트가 SAP Standard Object라면 SAP 라고 이름 붙여진 Transport Layer를 통해 검증 시스템으로 가고, CBO Object라면 ZTEP라고 붙여진 Transport Layer를 통해 갑니다. 이렇게 그룹핑 해주는 것이지요.

그렇다면 Delivery는 무엇일까요?

이 글의 위에서 Change Request를 릴리즈해야 다음 시스템에 넘어간다고 말씀드렸는데, Delivery로 연결된 시스템 간에는 릴리즈가 따로 필요 없습니다. 단, 승인 절차는 따로 필요하죠. 테스트도 끝나지 않았는데 멋대로 반영되면 안되니까요.

이렇게 Transport Layer와 Delivery를 나눈 이유에 대해 생각해봤는데, QA(검증)에서는 별도 변경을 하지 말라는 의미이지 않을까요? ㅎㅎ QA에서는 테스트만 하고 테스트 후에 문제가 발생했다면 개발 시스템에서 다시 수정하고 절차에 따르라는 의미인 것 같습니다.

다음 포스팅에서는 실제로 어떻게 Change Request가 개발 > 검증 > 운영 순으로 반영할 수 있는지 테스트 해보겠습니다.