GitHub Actions - CI/CD 환경 설정 : Pull Request 승인절차, 코드 리뷰 환경 구축

CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있습니다.

출처 : https://www.redhat.com/ko/topics/devops/what-is-ci-cd

 

 

 

협업 문화가 활발해지면서 유지보수성(maintainable)의 중요성 또한 높아졌다.

 

이번 미니프로젝트 백엔드 팀장이 되면서, 이 부분에 대해서 더욱 느끼는 바이다. 깔끔한 코드란 어떠한 방법론으로 적은 코드라기 보다 여러 사람이 작성 했어도 한사람이 작성한 것처럼 보이는 게 깔끔한 코드 같다.

 

이에 따라서 코드 스타일을 통일하고, 리뷰 문화를 통해서 개발에 대한 생각과 철학을 일치시켜, 마치 '팀'이 하나의 지성체가 되어 개발하는 듯한 환경을 만들기 위해 개발자들은 여러가지 협업 프로세스를 만들어나가고 있다.

 

push를 제한하여 pull request를 통한 review 문화를 장려할 수 있도록 세팅해보겠다.

 

깃허브에는 참여 인원이 승인(Approve)을 해야 Pull Request 머지를 할 수 있도록 설정할 수 있는 기능이 존재한다.

이 방법을 통해 "몇 명 이상의 코드 리뷰를 통과해야 한다"라는 내부적으로 룰을 만들어도 좋을 듯하다.

 

아직 본격적으로 코드 리뷰 문화가 잡히지 않은 곳에서 처음 시도하기에도 괜찮다고 생각이 든다.

우선 Approve설정을 하는 방법에 대해 알아보자.

 

먼저 레포지토리 셋팅에 들어가면 다음과 같은 화면을 볼 수 있다.

어떤 파랑 버튼과 함께 업그레이드를 해야한다는 페이지가 나오시는 분들은 레포지토리를 private 에서 public 으로 바꾸면 이 화면과 같이 바뀔 것이다.

 

여기서 Add branch protection rule 를 클릭해준다.

 

그럼 다음과 같은 화면이 나온다.

 

1 : 보호할 브랜치 명을 적으면 된다.

 

2 : merging 하기 전에 최소 필요 Approve 수를 설정할 수 있다. 만약 5명이서 하는 소규모 프로젝트라면 전체 인원 (즉 자기 자신을 제외한 4명) 에게 Approve 를 받아야지만 merging 할 수 있다.

 

3 : 상태를 체크할 수 있다. 팀이 정한 코딩컨벤션이나 빌드 과정이 정확히 통과하는지 체크할 수 있다.

 

4 : 모든 Conversation을 Resolve 해야지만 merging 할 수 있다. 자신이 pr을 올렸을 때 팀원이 OO 부분 수정이 필요할 거 같다는 리뷰 코멘트를 날리면 해결후 Resolve conversation 을 눌러 모두 해결 해야지 merging 할 수 있다.

 

 

 

 

 

이렇게 설정한다면 팀원들의 리뷰 반영과 승인을 받아야지만 merging을 할 수 있는 좋은 CI가 구축되는 것 같다.

Checkstyle_job으로는 커스텀 구글 자바 컨벤션을 사용하였고, build_job은 gradle 최신 버전을 사용하였다. 이런 설정은 프로젝트의 루트 폴더 아래에 .github 디렉토리 아래에 workflows 디렉토리에 아래에 ci.yml 파일로 설정하면 된다.

 

이런 설정을 마치면 PR 화면에서 아래와 같은 화면을 볼 수 있게 된다.