협업 시 코드의 안정성
은 가장 중요한 요소 중 하나이다. 여러 사람이 코드를 수정하기 때문에 다른 사람이 수정한 코드로 인해 테스트에 실패할 수 있다. 또한 내가 작성한 코드가 테스트를 통과하는지 다른 사람은 알 수 없다
. 신뢰도, 안정성이 보장되지 않은 상태로 merge가 일어나는 일은 피해야 한다.
흔히
CI(Continuous Integration)
라고 부르는, 지속적 통합을 통해 이러한 코드의 안정성을 보장할 수 있다.
사실 나는 이미 Jenkins Pipeline을 통해 build를 실행하고 있었지만, Github Actions를 통해 build에 실패할 경우 merge를 금지하는 등 다양한 기능을 사용할 수 있었고, Github Actions 복습 겸 구축하게 되었다.
나는 다음의 상황에서 CI trigger가 발생하도록 했다.
- main/dev branch로의 push 또는 merge가 일어날 경우
- Pull Request가 발생할 경우
name: Java CI with Gradle
# CI trigger 설정
on:
push:
branches:
- main
- dev
pull_request:
branches:
- main
- dev
# 아래의 jobs가 실행될 경로를 명시해준다.
defaults:
run:
working-directory: server/fly-away
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
with:
token: ${{ secrets.SECURITY_TOKEN }}
submodules: recursive
- name: Set up JDK 11
uses: actions/setup-java@v3
with:
java-version: '11'
distribution: 'temurin'
cache: gradle
- name: init with Gradle
uses: gradle/gradle-build-action@v2
- run: gradle init
- name: Build
run: ./gradlew build
기본적으로 jobs - steps의 구조로 되어있으며, steps 하위에 실행할 동작들을 명시해주면 된다.
name
: 각 step의 이름을 지정한다.
uses
: 외부 라이브러리를 활용할 때 해당 라이브러리를 선언해준다.
with
: 라이브러리에 대한 추가적인 옵션 또는 설정을 선언해준다.
steps:
- name: Checkout
uses: actions/checkout@v3
with:
token: ${{ secrets.SECURITY_TOKEN }}
submodules: recursive
checkout 시 submodule에 대한 권한을 부여해야 한다.
Repository의 Settings -> Secrets -> Actions
에서 시크릿 값을 설정해주고, submodule에 접근하기 위한 token으로 사용한다.
submodules: recursive
옵션을 사용하면 submodule update까지 자동으로 실행해준다.
현재는 Pull Request 시 빌드/테스트를 진행하지만, 개발자가 임의로 PR을 Merge 할 수 있는 상황이다. 물론 테스트 성공 여부를 확인하고 merge 할 수도 있지만, 개발자의 실수로 인해서라도 Merge가 발생할 수 있으므로 테스트 실패 시 Merge가 불가능하도록 해보자.
Settings - Branches
로 이동한다.
Branch protection rules - Add Rule
을 선택한다.
적용할 branch 명을 작성하고, Require status checkes to pass before merging
을 선택해준다.
그리고 테스트 성공/실패 상태를 체크할 job 이름을 지정
한다. 나는 build의 성공 여부를 체크할 것이기 때문에 build를 작성한다.
이렇게 하면 Pull Request 시 테스트의 성공 여부에 따라 Merge 가능 여부가 표시된다. 즉, 테스트 실패 시 merge가 불가능하다.