Jira to GitLab DORA 통합
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
GitLab을 사용하면 DORA 메트릭에 대한 가시성을 확보하여 DevOps 성능을 측정할 수 있습니다. 처음 두 메트릭은 GitLab CI/CD 및 MR에서 생성되지만, 후자 두 메트릭은 GitLab 인시던트가 생성되는 것에 의존합니다.
GitLab을 사용하면 DORA 메트릭에 대한 가시성을 확보하여 DevOps 성능을 측정할 수 있습니다. 4가지 메트릭은 다음과 같습니다:
- 배포 빈도: 프로덕션에 대한 하루 평균 배포 횟수
- 변경에 대한 리드 타임: 커밋을 프로덕션에 성공적으로 제공하는 데 걸리는 시간(초)(코드 커밋부터 프로덕션에서 성공적으로 실행될 때까지)
- 변경 실패율: 주어진 기간에 프로덕션에서 인시던트를 유발하는 배포의 비율
- 서비스 복원 시간: 프로덕션 환경에서 인시던트가 열려 있던 중앙값 시간
처음 두 메트릭은 GitLab CI/CD 및 MR에서 생성되지만, 후자 두 메트릭은 GitLab 인시던트가 생성되는 것에 의존합니다.
Jira를 인시던트 추적에 사용하는 팀의 경우, 인시던트가 실시간으로 Jira에서 GitLab으로 복제되어야 합니다. 이 프로젝트는 해당 복제 설정 방법을 안내합니다.
참고: 이슈 복제를 위한 유사한 통합이 존재하여 Value Stream Analytics 메트릭(리드 타임, 생성된 이슈, 종료된 이슈)을 생성합니다. VSA 메트릭을 위한 이슈 복제에 관심이 있다면 Jira to GitLab VSA 통합을 참조하십시오.
아키텍처#
2가지 자동화 워크플로우를 생성해야 합니다:
- Jira에서 생성될 때 GitLab 인시던트를 생성합니다.
- Jira에서 해결될 때 GitLab 인시던트를 해결합니다.
인시던트 생성#

인시던트 해결#

설정#
사전 요구사항#
이 안내는 다음을 갖추고 있다고 가정합니다:
- GitLab Ultimate 라이선스
- 인시던트를 복제할 Jira 프로젝트
Jira는 Jira 라이선스에 따라 자동화 실행 빈도에 제한을 둡니다. 현재 제한은 다음과 같습니다:
| 티어 | 제한 |
|---|---|
| Free | 월 100회 실행 |
| Standard | 월 1700회 실행 |
| Premium | 사용자당 월 1000회 실행 |
| Enterprise | 무제한 실행 |
각 인시던트 생성은 1회 실행으로 계산되고, 각 인시던트 해결도 1회 실행으로 계산됩니다.
GitLab 알림 엔드포인트#
먼저 GitLab에서 알림을 생성/해결하기 위해 트리거할 수 있는 HTTP 엔드포인트를 생성해야 합니다. 이는 차례로 인시던트를 생성/해결합니다.
- Jira 인시던트를 생성할 GitLab 프로젝트로 이동합니다. 사이드바에서 설정 > 모니터로 이동합니다. 알림 섹션을 확장합니다.
- 알림에서 알림 설정 탭으로 전환합니다. 다음 확인란을 선택하고 변경 사항 저장을 클릭합니다:
- 인시던트 생성. 트리거된 각 알림에 대해 인시던트가 생성됩니다.
- 복구 알림 알림이 알림을 해결할 때 연관된 인시던트를 자동으로 닫습니다
- 알림에서 현재 통합 탭으로 전환합니다. 새 통합 추가를 클릭합니다. 통합 유형을
HTTP 엔드포인트로 설정하고, 이름(예:Jira incident sync)을 지정하고, 통합 활성화를 활성으로 설정합니다. Jira 자동화 워크플로우를 설정한 후에 알림 페이로드 매핑을 사용자 정의할 예정이므로 잠시 후 돌아올 것입니다. - 통합 저장을 클릭합니다. "통합이 성공적으로 저장되었습니다"라는 메시지가 나타납니다. URL 및 인증 키 보기를 클릭합니다.
- Jira 자동화 워크플로우 및 Lambda 함수를 설정할 때 엔드포인트 URL과 인증 키가 필요하므로 나중을 위해 저장해 두십시오.
Jira 인시던트 생성 워크플로우#
Jira 인시던트가 생성될 때 GitLab 알림 엔드포인트를 자동으로 트리거하기 위해 Jira 자동화를 사용할 것입니다.
-
인시던트를 관리하는 Jira 프로젝트로 이동합니다. 사이드바에서 프로젝트 설정 > 자동화로 이동합니다(찾으려면 조금 아래로 스크롤해야 할 수도 있습니다).
-
여기서 Jira 자동화 워크플로우를 관리할 수 있습니다. 오른쪽 상단에서 규칙 만들기를 클릭합니다.
-
트리거로 이슈 생성을 검색하고 선택합니다. 저장을 클릭합니다.
-
IF: 조건 추가를 선택합니다. 여기서 생성된 이슈가 인시던트와 관련이 있는지 확인하기 위한 조건을 지정할 수 있습니다. 이 가이드에서는 이슈 필드 조건을 선택합니다. 필드에서 요약을 선택하고, 조건은 포함으로 설정하고, 값은
incident로 설정합니다. 저장을 클릭합니다. -
트리거와 조건이 설정되면 THEN: 작업 추가를 선택합니다. 웹 요청 보내기를 검색하고 선택합니다.
-
웹 요청 URL을 이전 섹션의 GitLab 웹훅 URL로 설정합니다.
-
엔드포인트 인증 옵션에 대한 GitLab 문서를 확인하십시오. 이 가이드에서는 Bearer 인증 헤더 방법을 사용할 것입니다. Jira 자동화 구성에서 다음 헤더를 추가합니다:
이름 값 Authorization Bearer <이전 섹션의 GitLab 엔드포인트 인증 키> Content-Type application/jsonAuthorization헤더를 "숨김"으로 설정할 수 있습니다.
-
HTTP 방법이 POST로 설정되어 있는지 확인하고, 웹 요청 본문을 **이슈 데이터(Jira 형식)**으로 설정합니다.
-
마지막으로 저장을 클릭하고, 자동화 이름(예:
Jira incident creation)을 지정하고, 켜기를 클릭합니다. 오른쪽 상단에서 목록으로 돌아가기를 클릭합니다. -
마지막으로 해야 할 작업은 Jira 페이로드 값을 GitLab 알림 매개변수에 매핑하는 것입니다. 서비스 복원 시간 메트릭을 위한 인시던트 해결도 설정할 계획이라면 이 단계를 지금 건너뜁니다. 그렇지 않으면 Jira 페이로드 값을 GitLab 알림 매개변수에 매핑으로 이동하여 거기에 있는 단계를 따릅니다.
페이로드 값을 매핑하면 Jira에서 생성하는 인시던트가 GitLab에서도 생성됩니다. 이를 통해 변경 실패율 DORA 메트릭을 볼 수 있습니다.
Jira 인시던트 해결 워크플로우#
다음 변경 사항을 적용하여 위에서 설명한 대로 또 다른 Jira 자동화 워크플로우를 만듭니다:
- 트리거를 이슈 전환됨으로 설정합니다. "이전 상태" 필드는 비워 둘 수 있습니다. "다음 상태" 필드는 워크플로우에 따라 해결된 인시던트를 나타내는 상태(예:
Closed,Done,Resolved,Completed)로 설정할 수 있습니다. - 자동화의 이름을 적절히 지정하십시오(예:
Jira incident close).
Jira 페이로드 값을 GitLab 알림 매개변수에 매핑#
-
Jira 자동화 워크플로우를 만든 후 방금 만든 워크플로우를 클릭하고 Then: 웹 요청 보내기를 선택합니다.
-
웹 요청 구성 검증 섹션을 확장하고 테스트할 해결된 이슈 키를 입력합니다(사용할 수 있는 기존 이슈 키가 있어야 합니다). 검증을 클릭합니다.
-
요청 POST 섹션을 확장하고 페이로드 섹션을 확장합니다. 전체 페이로드를 복사합니다.
-
GitLab 프로젝트로 돌아가서 설정 > 모니터 > 알림 > 현재 통합으로 이동합니다. 이전에 만든 통합 옆에 있는 '설정' 아이콘을 클릭하고 세부 정보 구성 탭으로 전환합니다.
-
알림 페이로드 매핑 사용자 정의에서 3단계에서 Jira에서 복사한 페이로드를 붙여넣습니다. 그런 다음 페이로드 필드 파싱을 클릭합니다.
-
아래와 같이 필드를 매핑합니다:
GitLab 알림 키 페이로드 알림 키 제목 issue.fields.summary 설명 issue.fields.status.description 종료 시간 issue.fields.resolutiondate1 모니터링 도구 issue.fields.reporter.accountType 심각도 issue.fields.priority.name 지문 issue.key 환경 issue.fields.project.name
1 이것은 인시던트 해결 자동화를 설정한 경우에만 필요합니다. 이 필드가 옵션으로 표시되지 않으면 2단계에서 해결된 이슈 키를 입력했는지 확인하십시오.
- 마지막으로 통합 저장을 클릭합니다.
이 시점에서 Jira에서 해결하는 인시던트는 GitLab에서도 해결됩니다. 이를 통해 서비스 복원 시간 DORA 메트릭을 볼 수 있습니다.
