CS Student’s SAP&Tech Journey✨

[SAP] 프로젝트(Project) 구성하기 / 이관 프로세스란? 본문

SAP/ABAP 개발 환경

[SAP] 프로젝트(Project) 구성하기 / 이관 프로세스란?

인포마틱 2025. 1. 22. 19:06

SAP ABAP 프로젝트는 개발 단계에서부터 테스트 및 운영 단계까지의 체계적인 이관 과정을 포함합니다. 이를 통해 SAP 시스템 내에서 객체 관리와 효율적인 이관이 가능하며, 프로젝트 팀원 간의 역할 분담도 명확히 이루어집니다. 

 


 

1. ABAP 프로젝트 구성 및 이관 프로세스

 

🟦 프로젝트 단계

  1. DEV (Development) - 개발
    • 개발이 이루어지는 단계.
    • 개발된 프로그램은 로컬 또는 지정된 패키지에 저장.
    • Task Number를 생성하고 작업 기록.
  2. QAS (Quality Assurance System) - 테스트
    • 개발된 프로그램을 테스트 환경으로 이관.
    • 이관 단위는 Change Request (CR)로, 하나 이상의 프로그램을 포함할 수 있음.
    • 테스트 완료 후 다음 단계로 이관.
  3. PRD (Production) - 운영 환경 
    • 운영 환경으로 이관된 단계.
    • 최종 검증 후 실제 운영에 사용.

 

🟦 이관 단위 Change Request (CR) 란?

  • CR 정의: 프로그램, 클래스 등 객체를 이관하기 위한 단위.
  • CR 관리:
    • 팀원은 SE09 T코드를 사용하여 CR을 확인하고 관리.
    • 프로젝트 리더가 최종적으로 CR을 검토하고 BC에게 이관 요청.

 

🟦 프로젝트 구성원 역할

  • Project Leader: Change Request 담당. 최종 검토 및 이관 요청.
  • Project Member 1, 2, 3: Task Number를 생성하고 객체를 개발.
  • BC (Basis Consultant): CR 단위로 이관을 수행.

 


 

2. 패키지와 프로그램의 관계

  1. 패키지의 역할
    • 패키지는 여러 프로그램과 개발 객체를 논리적으로 그룹화하는 컨테이너 역할을 합니다.
    • 특정 비즈니스 프로세스나 기능에 따라 프로그램을 관리하기 위해 사용됩니다.
    • 예:
      • ZPACKAGE_HR라는 패키지는 인사 관리와 관련된 프로그램과 객체를 포함.
      • ZPACKAGE_MM은 자재 관리 관련 객체를 포함.
  2. 프로그램의 위치
    • 프로그램은 반드시 하나의 패키지에 속해야 합니다.
    • 프로그램은 패키지 없이 생성할 수도 있지만, 이 경우 로컬 패키지($TMP)로 저장됩니다.
      • 로컬 패키지에 저장된 프로그램은 이관 대상이 아니며, 개발 환경(DEV)에만 남습니다.

 


 

3. 패키지와 프로그램의 구성 예시

  • 패키지 이름: ZPACKAGE_SALES
    • 프로그램 1: ZSALES_REPORT (영업 보고서 생성)
    • 프로그램 2: ZSALES_SUMMARY (영업 요약 데이터 표시)
    • 프로그램 3: ZSALES_ANALYSIS (영업 데이터 분석)
    • 테이블 1: ZSALES_DATA (영업 데이터 저장)
    • 클래스 1: ZCL_SALES_UTIL (영업 관련 유틸리티 클래스)

위 구성에서, 모든 객체는 ZPACKAGE_SALES라는 패키지에 속하며, 이 패키지를 기준으로 이관(Transport Request)이 이루어집니다.

 

SE09

🟦 프로젝트 리더의 주요 역할

  1. Change Request (CR) 관리
    • 개발 팀원들이 생성한 Task Number를 검토하고, 이를 CR로 통합.
    • CR은 이관할 객체들의 집합으로, 여러 프로그램, 테이블, 클래스 등을 포함할 수 있음.
    • CR 단위로 Basis Consultant(BC)에게 이관 요청.
  2. 이관 프로세스 승인
    • CR의 적합성을 확인하고, QAS 및 PRD 환경으로의 이관을 최종 승인.
    • 이관 중 발생할 수 있는 충돌이나 문제를 사전에 조율.
  3. 개발 객체 검토
    • 팀원이 생성한 프로그램이나 객체가 프로젝트 요구사항에 부합하는지 확인.
    • 패키지와 네임스페이스 규칙(Z, Y 시작 여부 등) 준수 여부 점검.
  4. 커뮤니케이션
    • 개발 팀과 BC 간의 중간 다리 역할을 수행.
    • 개발자들이 Task Number를 기반으로 작업한 내용을 BC에게 CR 형태로 전달.

🟦 Change Request와 Task Number의 관계

  • Task Number:
    • 프로젝트 팀원이 작업할 때 생성되는 단위.
    • 개발 중인 특정 프로그램, 테이블 등 개별 객체가 포함됨.
    • 예: DEVK900123 (Task Number)
  • Change Request:
    • 여러 Task Number를 통합하여 생성되는 단위.
    • QAS, PRD로 이관할 때 사용.
    • 예: CR123456 (Change Request Number)

🟦 예시 시나리오

  1. 팀원 역할:
    • 팀원 1이 프로그램 ZSALES_REPORT을 개발하고 Task Number를 생성.
    • 팀원 2가 테이블 ZSALES_DATA를 생성하고 Task Number를 기록.
  2. 프로젝트 리더 역할:
    • 팀원들의 Task Number를 확인하고 Change Request로 통합.
    • CR에 포함된 객체를 검토 후 BC에게 이관 요청.
  3. BC 역할:
    • CR을 QAS로 이관하고 테스트가 완료되면 PRD로 최종 이관.