변경 요청에 포함된 DevOps 커밋
DevOps 아티팩트 패키지 및 관련 아티팩트 버전은 변경에 DevOps 포함되는 커밋을 결정하는 데 사용됩니다.
변경 유형에 따라 커밋이 변경에 포함됩니다.
| 변경 유형 | 커밋 포함됨 |
|---|---|
| 수동 | 변경 시 패키지의 아티팩트 버전에서 커밋합니다. 또한 data_type 열이 계획 또는 파이프라인 실행일 때 변경 참조 기록에 있는 모든 파이프라인 실행의 작업 실행에서의 커밋이 포함됩니다. |
| 자동 |
|
마지막 배포 날짜 이후에 생성된 패키지의 아티팩트 버전에 대한 모든 커밋(현재 배포 중인 버전까지)이 변경 요청에 포함됩니다. 이전 주 버전은 포함되지 않습니다.
주:
패치 및 핫픽스 버전은 제외됩니다.
제공된 경우 의미 체계 버전은 변경에 대한 커밋을 결정하는 데 사용됩니다. 형식은 (MAJOR. 사소한. PATCH)를 사용합니다. 예를 들어 의미 체계 버전 2.0.1은 다음과 같이 읽습니다.
- 주 버전 2
- 부 버전 0
- 패치/핫픽스 버전 1
아티팩트를 빌드하지 않았지만 연결된 커밋이 있는 이전 아티팩트 버전과 현재 아티팩트 버전 간의 실패한 작업 실행도 생성된 아티팩트 버전과 연결됩니다.
커밋 유형
- 일반 커밋: 추적된 리포지토리의 커밋이 변경 요청과 연결됩니다.
- 커밋 되돌리기: 되돌리기 필드 값이 예인 커밋입니다. revert 커밋은 소스 트리에서 reverted 커밋 및 revert 커밋을 생성합니다. 두 커밋 모두 변경 요청에 연결되지 않습니다.
- 병합 커밋: 병합 필드 값이 true인 커밋입니다.
- 병합 커밋: 원본 트리는 시간 경과에 따라 분기에 대한 커밋을 추적하고 특별한 병합 커밋을 수행할 수 있도록 합니다. 이 병합 커밋은 현재 분기와 병합할 분기 모두에서 가장 최근의 공통 커밋 바로 뒤에 있는 부모 커밋을 결합합니다. 병합 커밋은 메인 분기에 새 커밋을 추가합니다.
- 스쿼시 및 병합: 병합 중 스쿼시는 병합 커밋을 만들지 않고 병합과 일치하도록 작업 트리 및 인덱스 상태를 생성합니다. Squash 및 merge는 변경 내용을 유지하지만 기록에서 개별 커밋을 제거합니다. 병합 값이 true인 단일 커밋이 있습니다.
예: 커밋 및 패키지
이 예제는 다음으로 구성됩니다.
- 빌드 파이프라인 3개(A, B, C)
- 변경 통제 하에 있는 릴리스 파이프라인(ABC)으로 4개의 패키지가 있습니다.
- 파이프라인 A 빌드(주 버전 1)
- 파이프라인 A 및 B 빌드(주 버전 1)
- 파이프라인 B 및 C 빌드(주 버전 1)
- 파이프라인 A, B 및 C 빌드(주 버전 1)
| 커밋 | 파이프라인 빌드 | 시맨틱 버전 | 패키지에 포함 |
|---|---|---|---|
| 1 | A | 1.0.0 | X |
| 2 | A | 1.0.1 | -- |
| 3 | A | 1.1.0 | X |
주: 커밋 2(빌드 A, 의미 체계 버전 1.0.1)는 의미 체계 버전 구문이 패치 또는 핫픽스를 나타내기 때문에 패키지에 포함되지 않습니다. |
|||
| 커밋 | 파이프라인 빌드 | 시맨틱 버전 | 패키지에 포함 |
|---|---|---|---|
| 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)는 의미 체계 버전 구문이 패치 또는 핫픽스를 나타내기 때문에 포함되지 않습니다. |
|||
| 커밋 | 파이프라인 빌드 | 시맨틱 버전 | 패키지에 포함 |
|---|---|---|---|
| 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)은 포함되지 않습니다. |
|||
| 커밋 | 파이프라인 빌드 | 시맨틱 버전 | 패키지에 포함 |
|---|---|---|---|
| 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 변경 내용의 일부이므로 이 패키지에도 포함됩니다. |
|||
예: 계산 논리 커밋
아티팩트 버전에 연결된 커밋을 계산하기 위한 논리가 포함된 사용 사례입니다. 분기 정보는 커밋이 정의될 때마다 포함됩니다.
예를 들어 두 개의 파이프라인(하나는 main 분기에 있고 다른 하나는 test 분기에 있음)을 고려합니다. 시나리오 실행:
- 메인에서 커밋 C0을 생성하고 CI 빌드를 실행하되 아티팩트 버전은 생성하지 않습니다.
- 테스트에서 커밋 C1을 생성하고 CI 빌드를 실행하되 아티팩트 버전은 생성하지 않습니다.
- main에서 커밋 C2를 만들고 CI 빌드를 실행하면 빌드가 실패합니다.
- 메인에서 C3,C4 커밋 2개를 만들고, CI 빌드를 실행하고, 아티팩트 버전(v1.0)을 만듭니다.
사용 사례 계속 진행:
- 메인에서 C5 커밋 1개를 생성하고 CI 빌드를 실행하되 아티팩트 버전은 생성하지 않습니다.
- 메인에서 C6 커밋 1개를 만들고, CI 빌드를 실행하고, 아티팩트 버전(v2.0)을 만듭니다.
요약:
- 지정된 아티팩트의 마지막 아티팩트 버전과 현재 아티팩트 버전 사이의 동일한 분기에서 파이프라인 실행의 모든 커밋(성공 및 실패)이 연결됩니다.
- 지정된 아티팩트에 대한 이전 아티팩트 버전을 찾을 수 없는 경우 동일한 분기의 파이프라인 실행의 모든 커밋이 연결됩니다.
사용 사례 계속 진행:
이전 단계의 아티팩트 버전을 사용하여 릴리스를 만들고 단계 유형 = 프로덕션 배포가 있는 CD 파이프라인이 있습니다.
예상 결과:
- 릴리스는 동일한 아티팩트 버전(v2.0)과 연결되어 있습니다.
- 변경 요청 생성됨은 아티팩트 버전(v2.0)을 표시하고 C0, C2, C3, C4, C5, C6 커밋을 커밋합니다.
요약:
- 메인 브랜치에 빌드된 두 아티팩트 버전(v1.0, v2.0)의 커밋(이전 패키지가 Prod에 배포되지 않음)은 변경 요청에 표시되지만 테스트 브랜치의 실행에서 커밋은 표시되지 않습니다.
- 변경 요청에 표시되는 커밋 수는 도구의 커밋 수와 동일합니다.
사용 사례 계속 진행:
- 테스트 분기에서 C7, C8 커밋 2개를 만들고, 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 분기에 빌드된 최신 아티팩트 버전의 커밋만 표시합니다.
- 테스트에서 빌드된 아티팩트 버전의 커밋이 표시되지 않습니다.
- 변경 요청에 표시되는 커밋 수는 도구의 커밋 수와 동일합니다.