배포 빈도

배포 빈도는 얼마나 자주 배포하는지를 나타내는 값입니다. 주어진 기간에 배포가 몇 번 있었는지를 셉니다. 배포와 배포 사이의 시간으로 같은 것을 보기도 합니다.

상세

지난달 카드 내역을 넘기며 장을 몇 번 봤는지 세어 봅니다. 열두 번입니다. 이틀에 한 번꼴로 다녔다는 것은 그 열두 번에서 나옵니다.

배포 빈도는 주어진 기간의 배포 횟수, 또는 배포와 배포 사이의 시간입니다. 미리 잡아 둔 간격에서 나오는 값이 아닙니다. 이미 일어난 배포를 세고 나서야 간격이 보입니다. DORA(DevOps Research and Assessment)가 소프트웨어 전달 성과를 재는 지표 중 하나로 이 값을 정의합니다. DORA 는 자기 지표들이 팀이 소프트웨어를 안전하고 빠르고 효율적으로 전달하는 능력에 초점을 맞춘다고 적습니다.

DORA 는 그 지표들을 두 묶음으로 가릅니다. 하나는 변경이 시스템을 얼마나 통과하는지를 보는 처리량(throughput)이고, 다른 하나는 배포가 얼마나 잘 되는지를 보는 불안정성(instability)입니다. 배포 빈도는 처리량 쪽에 있습니다.

묶음	재는 것	요소
처리량	변경이 시스템을 얼마나 통과하나	변경 리드 타임 · 배포 빈도 · 배포 실패 복구 시간
불안정성	배포가 얼마나 잘 되나	변경 실패율 · 배포 재작업률

세는 자리는 프로덕션입니다. DORA 는 처리량이 높다는 것을 시스템이 더 많은 변경을 프로덕션 환경까지 옮길 수 있다는 뜻이라고 적습니다. 같은 묶음의 변경 리드 타임도 끝점을 프로덕션에 배포된 시점으로 잡습니다. 그래서 이 값이 세는 것은 프로덕션에 도달한 배포라는 사건입니다.

배경

기술로 일하는 팀에는 자기 성과를 잴 방법이 필요합니다. DORA 는 잴 방법이 있어야 한다고 적습니다. 팀이 오늘 어떻게 하고 있는지 가늠하는 데 필요합니다. 무엇을 먼저 개선할지 정하는 데도 필요합니다. 나아진 것을 확인하는 데도 그렇습니다. 그래서 다섯 개의 소프트웨어 전달 성과 지표를 골라냈고, 자기 연구가 이 지표들이 더 나은 조직 성과와 구성원의 웰빙을 예측한다는 것을 보여 준다고 적습니다. 이 지표들은 선행 지표이자 후행 지표로 볼 수 있다고도 적습니다. 조직 성과와 구성원의 웰빙에 대해서는 선행 지표이고, 소프트웨어 개발·전달 실천에 대해서는 후행 지표입니다.

배포 횟수 하나만 세는 것으로는 부족합니다. DORA 는 이 두 묶음을 함께 놓고 봐야 팀이 자기 소프트웨어 전달 성과를 큰 틀에서 이해하게 된다고 적습니다. 시간에 걸쳐 재면 성과가 어떻게 달라지고 있는지가 보인다고 덧붙입니다. 이 요소들은 기술 스택이나 배포 절차의 복잡도, 최종 사용자와 상관없이 어떤 애플리케이션이나 서비스에도 쓸 수 있다고 적습니다. 그리고 자기 연구가 속도와 안정성이 맞바꾸는 관계가 아니라는 것을 거듭 보여 줬다고 적습니다. 대부분의 팀에서 지표들이 서로 상관을 보인다고 덧붙입니다. 상위 성과자는 다섯 지표 전반에서 잘합니다. 하위 성과자는 전반에서 못합니다.

배포를 세는 일은 이 값 하나로 끝나지 않습니다. DORA 가 불안정성 쪽에 둔 두 지표는 모두 배포에 대한 비율입니다. 분모가 배포 건수라는 뜻입니다. 그래서 무엇을 배포 1건으로 세느냐는 이 값의 크기만 정하지 않습니다. 옆 지표의 값도 함께 정합니다.

예시

Four Keys

Four Keys 는 GitHub 나 GitLab 같은 개발 환경에서 데이터를 모아 이 지표들을 대시보드로 내주는 참조 구현입니다. 문서는 DevOps Research and Assessment 팀이 6년의 연구를 거쳐 소프트웨어 전달의 성과를 가리키는 네 개의 핵심 지표를 찾아냈다고 적습니다. 그중 배포 빈도는 팀이 프로덕션에 얼마나 자주 성공적으로 릴리스하는가로 정의됩니다. 예로 드는 단위는 일·주·월·연입니다.

대시보드는 지표마다 색으로 성과를 표시합니다. 문서는 이 색 구간이 2019 State of DevOps Report 가 적은 elite·high·medium·low 성과자 구간을 대략(roughly) 따른다고 적습니다. 배포 빈도의 구간은 이렇습니다.

색	구간
Purple	On-Demand (multiple deploys per day)
Green	Daily, Weekly
Yellow	Monthly
Red	Between once per month and once every 6 months

문서는 마지막 칸을 "Yearly" 로 표현한다고 적습니다.

값이 어디서 나오는지도 문서에 적혀 있습니다. 이벤트는 Cloud Run 에 올린 webhook 대상으로 보내집니다. 이벤트는 개발 환경에서 일어나는, 잴 수 있는 모든 일입니다. 풀 리퀘스트나 새 이슈 같은 것입니다. Four Keys 는 잴 이벤트를 스스로 정의합니다. 프로젝트에 맞는 다른 이벤트를 더할 수 있습니다. 배포는 four_keys.deployments 테이블에 쌓입니다. 이 테이블은 성공한 배포만 담습니다. 칸은 셋입니다. deploy_id 는 배포의 식별자이고 events_raw 의 id 를 가리키는 외래 키입니다. changes 는 그 배포에 딸린 식별자들의 배열입니다. 커밋 식별자나 버그 식별자 같은 것입니다. time_created 는 배포가 끝난 시각입니다. 배포와 변경은 다대일 관계입니다.

GitLab

GitLab 문서는 배포 빈도를 주어진 날짜 범위 동안 프로덕션에 성공한 배포의 빈도라고 적습니다. 범위는 시간·일·주·월·연 단위로 잡습니다.

계산은 이렇게 합니다. GitLab 에서 배포 빈도는 주어진 환경에 대한 하루 평균 배포 수로 측정됩니다. 기준이 되는 시각은 배포의 종료 시각, 곧 finished_at 속성입니다. 그날 끝난 배포의 수에서 값을 냅니다. 성공한 배포(Deployment.statuses = success)만 셉니다. 대상은 프로덕션 environment tier 이거나 production·prod 라는 이름을 가진 환경입니다.

flowchart TD
    A[배포 이벤트] --> B{성공한 배포인가}
    B -->|아니오| X[안 센다]
    B -->|예| C{프로덕션 티어인가}
    C -->|아니오| X
    C -->|예| D[종료 시각의 날짜에 더한다]
    D --> E[하루 평균]

배포 이벤트가 들어오면 성공 여부를 먼저 봅니다. 성공한 것만 남기고, 그중 프로덕션 티어에 속한 환경으로 간 것만 다시 남깁니다. 남은 배포를 종료 시각의 날짜별로 모으고, 하루 평균을 냅니다.

같은 문서가 계산 방식 하나를 따로 짚습니다. 배포 빈도는 평균(mean)으로 계산되고, 이는 중앙값을 쓰는 다른 DORA 지표들과 다릅니다. 문서는 중앙값이 성과를 더 정확하고 믿을 만하게 보여 주기 때문에 선호된다고 적습니다. 그런데도 배포 빈도만 평균인 이유도 적혀 있습니다. 이 지표는 GitLab 이 DORA 프레임워크를 채택하기 전부터 있었습니다. 다른 리포트에 편입될 때 계산이 그대로 남았습니다.

경계

스테이징 환경에 배포한 것도 배포 빈도에 세나. 아닙니다.

DORA 쪽 근거는 프로덕션이라는 끝점입니다. 처리량이 높다는 것은 시스템이 더 많은 변경을 프로덕션 환경까지 옮길 수 있다는 뜻이고, 같은 묶음의 변경 리드 타임도 끝점을 프로덕션에 배포된 시점으로 잡습니다.

GitLab 문서는 이것을 설정으로 못 박습니다. 배포 빈도의 계산은 프로덕션 environment tier 나 production·prod 라는 이름의 환경을 대상으로 삼습니다. 환경이 프로덕션 배포 티어에 속해야 그 배포 정보가 그래프에 나타난다고 적습니다. 스테이징 환경은 이 조건을 만족하지 않으므로 값에 들어가지 않습니다.

배포 빈도

상세

배경

예시

Four Keys

GitLab

경계

관련 항목

같은 묶음의 지표

이 값을 높이는 실천

안전하게 자주 배포하려고 쓰는 방식

이 값이 세는 배포가 지나는 단계

이것을 정의하고 다루는 분야

이것을 실제로 계산하는 도구