[백엔드 개발환경 세팅하기] - D-n룰 세팅
D-n 룰
❓ D-n룰이란?
💡D-n룰: PR에서 코드리뷰에 대한 데드라인을 명시하는 룰을 의미한다.
이 룰을 적용시키면 PR을 올리는 입장에서도 리뷰가 달리는 시간을 보장받을 수 있고 리뷰를 하는 입장에서도 언제까지 리뷰를 하면 될지가 정해져 일정을 정하기가 쉬워진다.
이번 프로젝트에서 좋은 개발 환경 구축을 위해서 여러 기업의 개발 프로세스를 찾아보던 중
코드 리뷰 in 뱅크샐러드 개발 문화
이 뱅크 샐러드의 글을 보며 D-n룰에 대해서 접하게 됐다.
글을 보고 상당히 좋은 룰이라고 생각했고 실제로 데드라인 명시가 필요함을 저번 프로젝트 때 느꼈었다.
이전에 진행했던 프로젝트에서도, PR 머지 이전에 코드 리뷰 및 승인을 받는 것으로 규칙을 정했었는데 시간이 너무 촉박했기 때문에 오히려 독이 됐던 룰이라고 생각한다..
이전 프로젝트는 거진 2주만에 완성해야하는 프로젝트였기 때문에 PR 머지를 하루 이상 기다릴 수 없었다..
따라서 저번 프로젝트처럼 일정이 아주 타이트 한 것은 아니지만
‘최소 n일 전 까지는 리뷰가 완료된다’가 보장이 된다면 훨씬 마음 편하게 다른 작업을 할 수도 있기 때문에
이번 프로젝트에서는 D-n룰을 제시했고 팀원들도 모두 비슷한 경험이 있었다고 공감하며 채택됐다.
🛠️ D-n룰을 깃허브 시스템에 적용시켜보자
먼저 PR에 붙일 lable을 등록시키자. 아무래도 D-0에 가까워질수록 급박함을 나타내는 컬러가 좋을듯한데.. 똑똑한 GPT에게 색상코드작업을 부탁하자
이 색상 그대로 D-5부터 D-0까지 만들었다.
하지만 이렇게 만들어두고 쓰기만 한다면 하루가 지날 때 마다 직접 라벨을 갈아 끼워줘야한다.
그렇게 할 수도 있지만.. 아주 귀찮은 작업이 될 것이다.
우리에겐 Github Actions라는 좋은 툴이 있다. Actions를 이용해서 이 라벨들을 갱신하여 하루가 지날 때 마다 day-1 씩 되도록 하자 서칭을 좀 해보니 네이버에서 만들어서 마켓에 올려둔 Github Actions가 있다. 잘 만들어둔 도구가 있으니 이를 활용하자🙃
그리고 이 액션을 만들게된 과정이 담겨있는 네이버 블로그의 글도 볼 수 있었다.
리뷰 응답시간을 개선하기 위한 방법 이외에 참여율을 개선하기 위한 방법도 아주 타당하고 흥미로우니 읽어보기를 추천한다.
GitHub Actions를 이용한 코드 리뷰 문화 개선기
⚙️ D-day 갱신 자동화
다시 돌아와서
가이드대로 .github/workflows/d-day-labeler.yml 파일을 작성하자
1
2
3
4
5
6
7
8
9
10
11
12
name: Update D-n Labels
on:
schedule:
- cron: '0 15 * * *' # 매일 밤 12시에 실행 (KST 기준)
jobs:
d-day-labeler:
runs-on: [ubuntu-latest]
steps:
- name: Update D-n Labels
uses: naver/d-day-labeler@latest
with:
token: ${{ secrets.GITHUB_TOKEN }}
여기서 이 액션은 리파지토리의 PR에 직접적인 수정을 하기 때문에 이에 대한 충분한 권한을 가진 토큰을 넣어주어야 한다.
처음엔 조직 리파지토리의 PR을 수정하는 작업이기 때문에 ‘조직에서 발급한 새로운 토큰이 필요한가’? 싶었는데
디폴트 옵션을 그대로 조직에서 PAT를 허용하고 있다면 이를 사용할 수 있다고 한다.
이전에 생성했던 PAT가 있긴 했지만 만료기간이 얼마 남지 않기도 해서 새로운 토큰을 생성하고 등록했다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
name: Update D-n Labels
on:
schedule:
- cron: '0 15 * * *' # 매일 밤 12시에 실행 (KST 기준)
workflow_dispatch:
permissions:
issues: write
contents: write
# pull-requests: read // 이전에 추가하지 않았던 권한
jobs:
d-day-labeler:
runs-on: [ubuntu-latest]
steps:
- name: Update D-n Labels
uses: naver/d-day-labeler@latest
with:
token: ${{ secrets.DDAY_TOKEN }}
workflow_dispatch는 수동으로 테스트 하기 위해서 추가한 것이고 충분한 권한이 있는 PAT를 새로 발급받아서 하기 이전에 permissions을 통해 기본 GITHUB_TOKEN에 권한을 추가하여 해결하려고 시도 흔적이다.
💩 permission 권한 제어 실수
이 글을 보면 permissions를 통해 어떤 GITHUB_TOKEN에 어떤 권한을 부여할 수 있는지 나와있다.
그런데 이 때 d-day labeler에 필요한 권한 설정을 잘못해줘서 Actions이 제대로 동작하지 않았다. d-day-labeler api.ts
여기 31번째 줄을 보면
1
2
3
4
5
return fetchAllPages(global.octokit.rest.pulls.list, {
owner: global.owner,
repo: global.repo,
state: "open",
});
PR 목록을 조회 하는 API까지 호출하는 것으로 보인다.
따라서 permission에 pull-requests의 read권한까지 필요한데 이게 추가되지 않아서 제대로 동작하지 않았던 것 같다.😕
✅ 동작 테스트
여하튼.. 아까만든 새로운 토큰을 등록해서 잘 동작하는지 테스트까지 완료했다.
먼저 다른 브랜치에 대충 주석을 달아놓아서 커밋해서 PR을 생성하고
마침 정각이 얼마 안 남아서 기다렸다.. 근데 아무리 자정이 지나도 실행이 안되길래 Github 스케줄링은 지연될 수 있다고 하더라 특히, 매 시간 정각에 스케줄링 작업이 몰려서 정각에 스케줄링한 작업은 잘 지연된다고 한다.
어쨌든 약 20분이 지난 시점에 결국 작동했다.
결과적으로는 잘 동작했다.
여담
아 그리고 D-0 다음날에는 어떻게 동작하는지 궁금해서 찾아보니
1
2
3
4
5
6
7
const getNextLabel = (name: string): `D-${number | string}` => {
const [, day] = name.match(D_N_PATTERN);
const currentDDay = parseInt(day);
const nextDDay = currentDDay <= 0 ? 0 : currentDDay - 1;
return `D-${nextDDay}`;
};
그냥 0을 그대로 유지 하도록 되어있다.
어쨌든, D-n룰 갱신 자동화까지 시켰으니 이 룰이 좋은 효과를 가져오기를 기대해본다