인프라 슛슈슛슛

[Infra] Github Actions 간단 실습(1) ~ 빌드및 테스트 ~

bimppap 2022. 9. 28. 18:13

최근 대학교 동아리 사람들과 간단한 스프링 프로젝트를 만들고 있다. 백엔드 일부와 인프라 전반을 맡게 되었는데, 인프라를 전부 맡은 적은 처음이라 조금 부담이 있었다. 그래도 하다 보니 생각보다 할만해서 재미있게 하고 있다.

 

최대한 간단하게 CI/CD 환경을 구축하기 위해 헤로쿠와 깃허브 액션을 쓰기로 했다. 순서는 다음과 같다.

 

1. develop 브랜치를 베이스로 한 PR 브랜치가 올라온다.
2. 깃허브 액션에서 PR을 감지하고 빌드 및 테스트를 돌린다.
3. 빌드와 테스트가 성공적으로 끝나면 코드 리뷰를 진행하고, develop 브랜치에 머지한다.
4. 깃허브 액션에서 머지를 감지하고 헤로쿠 서버에 배포한다.

 

0. 깃허브 액션이란?

 

깃허브에서 제공하는 CI/CD 서비스.

레포지토리에서 어떤 이벤트가 발생했을 때, 또는 주기적으로 어떤 작업들을 실행하도록 만든다.

소프트웨어 workflow를 자동화할 수 있도록 도와주는 도구라고 생각하면 된다.

+ workflow란? 여러 job으로 구성되고, 이벤트에 의해 트리거될 수 있는 자동화된 프로세스

 

1-1. 빌드 및 테스트 워크플로우 만들기

 

루트에 .github 디렉토리를 만들고 하위에 workflows 디렉토리를 만든다.

.github/worflows 에서 빌드와 테스트를 하는데 사용할 yml 파일을 만든다. 이름은 자유롭게 지으면 된다.

(여기선 gradle.yml이라 썼다. deploy는 배포용 워크플로우로 차후에 설명 예정)

1-2. 필요한 워크 플로우 선택하기

 

프로젝트 상단 탭의 Actions로 가 New workflow 버튼을 클릭한다.

Choose a worflow 화면이 나오면 필요한 워크플로우를 검색하거나 추천 워크플로우에서 검색해서 사용한다.

여기선 빌드와 테스트 워크플로우를 만들 예정이기에 Java with Gradle을 사용한다.

 

Configure 버튼을 클릭하면 아래와 같이 워크플로우를 작성할 수 있는 창이 뜬다. 여기서 바로 yml 파일을 쓰고 커밋을 할 수 있지만 내용을 복사하여 작업 중인 IDE로 가져와 넣을 수도 있다.

 

 

오른쪽 Marketplace 에서 커스텀된 Action들을 가져올 수 있다. 클릭하면 복사할 수 있는 Action이 뜬다.

 

1-3. 빌드 및 테스트 워크 플로우 작성하기

 

워크 플로우를 작성하는 방법은 마켓플레이스 탭 옆에 있는 Documentation을 참고하면 된다.

여기서 더 자세한 내용을 살필 수 있지만 한국어는 지원하지 않는다... 🥺

Documentation을 참고하여 아래와 같이 워크 플로우를 작성한다. 필요에 따라 task가 달라질 수도 있다.

> on

워크플로우가 실행되는 트리거를 설정하는 구간이다.

pull request, push, fork 등의 레포지토리에서 일어나는 이벤트에 트리거를 걸 수 있고,

시간을 지정하거나, 특정 tag, label, branch, 파일을 무시하거나 인지하는 식으로 트리거를 걸 수 있다.

 

> permissions

워크플로우가 가질 수 있는 권한을 설정하는 구간이다.

특정 엔터프라이즈, 그룹, 레포만 워크플로우를 돌릴 수 있도록 할 수 있다.

docs에 따르면 contents: read 로 하는게 제일 무난하다고.

 

> jobs

독립된 가상 머신 혹은 컨테이너에서 돌아가는 하나의 처리 단위.

여러 개의 step으로 구성되어 있으며 다른 job에 의존 관계를 가지거나 병렬 실행이 가능하다.

 

> runs on

어떤 OS에서 실행할지 지정한다.

보통 ubuntu-latest로 지정한다.

 

> steps

task의 집합으로 커맨드를 날리거나 action을 실행할 수 있다.

uses를 사용해 양식이 지정된 action들을 가져올 수도 있다.

 

> action

워크플로우의 가장 작은 블럭으로 어떤 일이 실행되는 컴포넌트다.

개인적으로 만들어도 되고 마켓플레이스에서 가져올 수도 있다.

 

위에서 만든 gradle.yml의 흐름을 설명하자면 아래와 같다.

Java CI with Gradle 이라는 이름의 워크플로우.

해당 레포의 develop 브랜치에 pull reqeust를 보내는 사람이
해당 레포의 컨텐츠를 읽을 수 있는 권한이 있으면
최신 우분투 환경에서
checkout@v3 양식을 사용한다.
- Set up JDK 11 Task 수행 : setup-java@v3 양식을 이용해 temurin의 java 11로 JDK를 설정
- Grant execute permission for gradlew Task 수행 : escahp 파일로 이동한 후 gradlew 파일의 접근 권한 변경
- Build with Gradle Task 수행 : escahp 파일로 이동한 후 테스트 없이 gradlew clean build 진행
- Test with Gradle Task 수행 : escahp 파일로 이동한 후 application-test.yml 를 이용해 테스트 진행

 

1-4. PR을 올려 워크 플로우가 제대로 돌아가는지 확인하기

워크플로우를 github를 통해 커밋하여 올리거나 PR로 올리면

PR 페이지 아래에서 CI 중 gradle이라는 이름의 worflow가 돌고 있다는 표시가 뜬다.

Details를 클릭해 더 자세한 프로세스를 확인할 수 있다.

 

 

중간에 에러 없이 모든 Job이 끝나면 아래와 같이 성공 표시가 뜬다.

 

 

PR 리스트 창에서도 성공 여부를 알 수 있다. 실패했을 경우 붉은 색 X 표시가 뜬다.

 

 

1-5. (옵션) 워크 플로우 이행 여부 디테일하게 확인하기

레포지토리의 Actions 탭에서 특정 워크플로우를 클릭하면 해당 워크플로우가 몇 번이나 어디서 돌았는지 확인할 수 있다.

워크플로우가 돌아간 케이스를 클릭하면 실행된 job 목록을 볼 수 있다.

특정 job을 클릭하면 더 디테일한 실행 과정을 볼 수 있다. 클릭하면 각 Task의 터미널 이력도 확인할 수 있다.

 

 

2. 참고 자료

Github Actions로 CI workflow 생성해보기(w/ Spring Boot)

GitHub Actions의 소개와 핵심 개념

Github Action 사용법 정리

 

3. 후기

Github Actions를 처음 써봐 처음엔 감이 잘 안 잡혔으나 잘 정리된 글들이 많아 생각보다 수월하게 진행할 수 있었다.

public 레포의 경우에는 무료로 사용할 수 있으나 private 레포는 횟수가 제한되어 있고 그 이상은 유료로만 사용할 수 있다고 한다.

jenkins라는 대체제도 있으니 서로의 장단점을 비교해보면서 사용하면 되겠다. 👀

 

다음엔 헤로쿠 공용 워크플로우 양식을 이용한 배포 워크 플로우를 작성해 보겠다.