변경 요청에 DevOps 포함된 커밋

  • 릴리스 버전: Australia
  • 업데이트 날짜 2026년 03월 12일
  • 소요 시간: 6분

    • DevOps 아티팩트 패키지 및 연관된 아티팩트 버전은 변경에 DevOps 포함되는 커밋을 결정하는 데 사용됩니다.

    커밋은 변경 유형에 따라 변경에 포함됩니다.
    유형 변경 커밋 포함됨
    수동 변경 시 패키지의 아티팩트 버전에서 커밋합니다. 또한 data_type 열이 계획 또는 파이프라인 실행인 경우 변경 참조 기록의 모든 파이프라인 실행의 작업 실행에서 생성된 커밋이 포함됩니다.
    자동
    • 패키지 제외: 아티팩트 버전의 모든 커밋이 포함됩니다. 아티팩트 버전은 파이프라인 실행 및 해당 파이프라인 실행을 위한 작업 실행에 연결된 버전입니다.
    • 패키지 포함: 변경의 업스트림 작업 실행에 프로덕션 배포 단계가 있는 경우 마지막으로 성공한 프로덕션 배포 파이프라인 실행의 커밋이 포함됩니다. 여러 파이프라인 실행에 나타나는 커밋은 한 번만 나열됩니다. 업스트림 작업 실행에 프로덕션 배포 단계가 없는 경우 패키지의 모든 아티팩트 버전의 커밋이 포함됩니다.
    • 커밋 실행: 이전에 지정한 대로 패키지 포함 또는 포함 없는 패키지 플로우에서 커밋이 없으면 변경 요청의 업스트림 작업 실행에서 커밋 실행이 연결됩니다.
    마지막 배포 날짜 이후에 생성된 패키지의 아티팩트 버전에 대한 모든 커밋(현재 배포 중인 버전까지)이 변경 요청에 포함됩니다. 이전 주 버전은 포함되지 않습니다.
    주:
    패치 및 핫픽스 버전은 제외됩니다.
    제공된 시맨틱 버전은 변경에 대한 커밋을 결정하는 데 사용됩니다. 형식은 (MAJOR. 경미한. 패치). 예를 들어, 시맨틱 버전 2.0.1은 다음과 같이 읽습니다.
    • 주 버전 2
    • 부 버전 0
    • 패치/핫픽스 버전 1

    아티팩트를 빌드하지 않았지만 연결된 커밋이 있는 이전 아티팩트 버전과 현재 아티팩트 버전 간에 실패한 작업 실행도 생성된 아티팩트 버전에 연결됩니다.

    커밋 유형

    • 일반 커밋: 추적된 리포지토리의 커밋이 변경 요청에 연결됩니다.
    • 커밋 되돌리기: 되돌리기 필드 값이 예인 커밋입니다. 되돌리기 커밋은 소스 트리에서 커밋을 되돌리고 커밋을 되돌립니다. 두 커밋 모두 변경 요청에 연결되지 않습니다.
    • 병합 커밋: 병합 필드 값이 예인 커밋입니다.
      • 병합 커밋: 소스 트리는 시간이 지남에 따라 분기에 대한 커밋을 추적하고 특별한 병합 커밋이 이루어질 수 있도록 합니다. 이 병합 커밋은 현재 분기와 병합할 분기 모두에서 가장 최근의 공통 커밋 바로 뒤에 있는 상위 커밋을 결합합니다. 커밋 병합은 메인 분기에 새 커밋을 추가합니다.
      • 스쿼시 및 병합: 병합 중 스쿼시는 병합 커밋을 생성하지 않고 병합과 일치하는 작업 트리 및 인덱스 상태를 생성합니다. 스쿼시 및 병합은 변경 내용을 유지하지만 기록에서 개별 커밋을 제거합니다. 병합 값이 예인 단일 커밋이 있습니다.

    예: 커밋 및 패키지

    이 예는 다음으로 구성됩니다.
    • 3개의 빌드 파이프라인(A, B, C)
    • 변경 통제 하에 있는 릴리스 파이프라인(ABC)으로, 다음 4개의 패키지가 있습니다.
      1. 파이프라인 A 빌드(주 버전 1)
      2. 파이프라인 A 및 B 빌드(주 버전 1)
      3. 파이프라인 B 및 C 빌드(주 버전 1)
      4. 파이프라인 A, B 및 C 빌드(주 버전 1)
    표 1. 패키지 1(A 1.1.0)
    커밋 파이프라인 빌드 시맨틱 버전 패키지에 포함
    1 A 1.0.0 X
    2 A 1.0.1 --
    3 A 1.1.0 X
    주:
    커밋 2(빌드 A, 시맨틱 버전 1.0.1)는 시맨틱 버전 구문이 패치 또는 핫픽스를 나타내기 때문에 패키지에 포함되지 않습니다.
    표 2. 패키지 2(A 1.2.0, B 1.1.0)
    커밋 파이프라인 빌드 시맨틱 버전 패키지에 포함
    4 A 1.1.1 --
    5 A 1.2.0 X
    6 A 1.2.0 X
    7 B 1.0.0 X
    8 B 1.0.0 X
    9 B 1.1.0 X
    10 B 1.1.0 X
    주:
    커밋 4(빌드 A, 시맨틱 버전 1.1.1)는 시맨틱 버전 구문이 패치 또는 핫픽스를 나타내므로 포함되지 않습니다.
    표 3. 패키지 3(B 1.2.0, C 1.0.0)
    커밋 파이프라인 빌드 시맨틱 버전 패키지에 포함
    11 A 1.3.0 --
    12 B 1.2.0 X
    13 B 1.2.0 X
    14 C 1.0.0 X
    15 C 1.0.0 X
    16 C 1.0.0 X
    주:
    패키지가 빌드 A를 지정하지 않으므로 커밋 11(빌드 A, 시맨틱 버전 1.3.0)이 포함되지 않습니다.
    표 4. 패키지 4(A 1.4.0, B 1.3.0, C 1.2.0)
    커밋 파이프라인 빌드 시맨틱 버전 패키지에 포함
    17 A 1.4.0 X
    18 A 1.4.0 X
    19 B 1.3.0 X
    20 B 1.3.0 X
    21 C 1.1.0 X
    22 C 1.1.0 X
    23 C 1.2.0 X
    24 C 1.2.0 X
    주:
    커밋 11은 마지막 패키지(빌드 A의 주 버전 1 포함)인 패키지 #2가 프로덕션에 배포된 이후 빌드 A의 주 버전 1에서 변경된 내용의 일부이므로 이 패키지에도 포함되어 있습니다.

    예: 커밋 계산 논리

    아티팩트 버전과 연결되는 커밋을 계산하는 논리가 포함된 사용 케이스입니다. 분기 정보는 커밋이 정의될 때마다 포함됩니다.

    예를 들어 두 개의 파이프라인, 즉 메인 분기에 하나, 테스트 분기에 하나씩 있다고 가정해 보겠습니다. 시나리오 실행:

    • 메인에서 커밋 C0을 작성하고 CI 빌드를 실행하되 아티팩트 버전은 작성하지 않습니다.
    • 테스트에서 커밋 C1을 생성하고 CI 빌드를 실행하되 아티팩트 버전은 생성하지 않습니다.
    • 메인에서 커밋 C2를 생성하고 CI 빌드를 실행하면 빌드가 실패합니다.
    • 메인에서 2개의 커밋 C3, C4를 생성하고, CI 빌드를 실행하고, 아티팩트 버전(v1.0)을 생성합니다.
    예상 결과: 아티팩트 버전(v1.0)이 C0, C2, C3, C4에 연결되어 있습니다. 커밋 C1은 다른 분기에 있으므로 제외됩니다.
    사용 케이스 진행:
    • 메인에서 1개의 커밋 C5를 생성하고 CI 빌드를 실행하지만 아티팩트 버전은 생성하지 않습니다.
    • 메인에서 1개의 커밋 C6을 생성하고, CI 빌드를 실행하고, 아티팩트 버전(v2.0)을 생성합니다.
    예상 결과: 생성된 새 아티팩트 버전(v2.0)은 C5, C6과 연결되어 있습니다.
    요약:
    • 지정된 아티팩트의 마지막 아티팩트 버전과 현재 아티팩트 버전 사이의 동일한 분기에서 파이프라인 실행(성공 및 실패)의 모든 커밋이 연결됩니다.
    • 지정된 아티팩트에 대한 이전 아티팩트 버전을 찾을 수 없는 경우 동일한 분기에 있는 파이프라인 실행의 모든 커밋이 연결됩니다.

    사용 케이스 진행:

    이전 단계의 아티팩트 버전으로 릴리스를 생성하고 단계 유형 = 프로덕션 배포인 CD 파이프라인이 있어야 합니다.

    예상 결과:
    • 릴리스가 동일한 아티팩트 버전(v2.0)과 연결되어 있습니다.
    • 생성된 변경 요청은 아티팩트 버전(v2.0)을 표시하고 C0, C2, C3, C4, C5, C6을 커밋합니다.
    요약:
    • 기본 분기에 빌드된 두 아티팩트 버전(v1.0, v2.0)의 커밋(이전 패키지가 프로덕션에 배포되지 않음)이 변경 요청에 표시되지만 테스트 분기에서 실행된 커밋은 표시되지 않습니다.
    • 변경 요청에 표시되는 커밋 수는 도구의 수와 같습니다.
    사용 케이스 진행:
    • 테스트 분기에 2개의 커밋 C7, C8을 생성하고 CI 빌드를 실행하여 아티팩트 버전을 생성합니다.

      예상 결과: 아티팩트 버전(v3.0)이 C1, C7, C8에 연결되어 있습니다.

    • 메인 분기에 2개의 커밋 C9, C10을 생성하고 CI 빌드를 실행하고 아티팩트 버전을 생성합니다.

      예상 결과: 아티팩트 버전(v4.0)이 C9, C10에 연결되어 있습니다.

    • 이전 단계(v4.0)의 아티팩트 버전으로 릴리스를 생성하고, 단계 유형 = 프로덕션 배포인 CD 파이프라인이 있어야 합니다.
      예상 결과:
      • 릴리스는 아티팩트 버전(v4.0)과 연결되어 있습니다.
      • 생성된 변경 요청은 아티팩트 버전(v4.0)을 표시하고 C9, C10을 커밋합니다.
    요약:
    • 변경 요청은 main에 빌드된 이전 아티팩트 버전의 커밋이 이전 패키지의 Prod에 배포되었기 때문에 main 브랜치에 빌드된 최신 아티팩트 버전의 커밋만 보여줍니다.
    • 변경 요청에 표시되는 커밋 수는 도구의 수와 같습니다.
    • 테스트 또는 배포와 같은 다른 단계 유형이 프로덕션 배포와 동일한 커밋 논리를 사용하도록 하려면 다른 단계 유형이 변경 [] 속성에 대한 커밋을 결정하기 위해 다른 단계 유형이 프로덕션 배포와 동일한 논리를 따라야 하는지 여부를 제어합니다.sn_devops.commit_rel_change_step_type 속성 값으로 Prod Deploy와 동일한 커밋 논리를 사용해야 하는 단계 유형(예: 배포 및 테스트)을 지정합니다. 이러한 설정이 완료되면 Prod Deploy 커밋 프로세스가 관계 스크립트에도 적용됩니다.