[CI] Github Actions CI 적용하기 #3 - Actions Pipeline 설계하기

이전 포스트에서는 간단하게 Unit Test와 E2E Test를 순차적으로 진행하도록 Actions를 작성하였다.

https://hoplin-dev.tistory.com/4

[CI] Github Actions CI 적용하기 2편 - Github Action Script 작성하기

다만 앞에서 작성한 Actions 스크립트는 단순히 테스트만 동작하는 Actions스크립트였다. 하지만 앞에서 작성한 Actions 스크립트에는 여러가지 문제점들과 CI에 부적합한 측면이 있다.

• 흔히 CI는 빌드와 테스트 단계이다. 하지만 이 스크립트에서 빌드단계가 누락되었다.
• 앞에서 작성한 스크립트는 Job간의 중복되는 Step이 많다.
  1. 각 Job에서 모두 빌드를 진행한다.(선택적)
  2. 각 Job에서 모두 의존성 설치를 진행한다.
  3. 각 Job에서 .ci.env를 생성한다.

Action 스크립트 설계하기

이 포스트에서는 위 문제점을 해결할 수 있는 Actions를 설계해보자. 

빌드단계 적용하기

가장 먼저 빌드 단계를 추가해야한다. 빌드 단계는 애플리케이션이 실행 가능한 상태로 컴파일(Nest.js기준)이 되는가에 대한 검사를 진행하는 단계이다. 테스트는 빌드 이후의 단계이다. 빌드가 안된다면 테스트는 더더욱 안될것이며 된다면 그것 나름 문제이다... 그렇기 때문에 우리가 고려해야하는것은 테스트 단계는 빌드에 의존이 되어야한다는 점이다.

 

실행 순서에 대한 고찰

앞에서 우선 빌드 단계를 적용하였다. 하지만 실행 순서를 살펴보면 Unit Test와 E2E Test가 실행순서에 의존성을 지녀야 하는가?에 대해 의문점이 생긴다. Unit Test의 코드와 E2E Test 코드는 서로 영향을 주지 않기 때문에 서로 동시에 실행되어도 문제가 발생하지 않는다.

 

효율성에 대한 고찰

효율성에 대해 고민해보자. 빌드 단계에서 프로젝트 의존성을 설치(node_modules)하고, secrets context를 활용하여 .ci.env를 만들었다고 가정하자. 이 과정을 Unit Test, E2E Test 각각에서도 실행한다면 중복된 작업이 많아지게 되고, 그에 따른 시간도 많이 걸리게 된다. 만약 빌드 단계에서 만들어진 node_modules와 .ci.env를 다른 Job들에게 공유해주면 시간이 많이 줄어들 것이다. 

실제로 의존성 설치 과정은 대략 30~40초정도 걸린다. 꽤 많은 비중을 차지하는 Step에 해당된다.

이와 관련되어 찾아보니 Github Actions에서 제공하는 관련 Action이 존재하였다. actions/upload-artifact@v4 와 actions/download-artifact@v4 이 두가지를 활용할 것이다.

 

이 두가지를 활용하여 빌드와 의존성 과정을 한번으로 줄여볼 것이다.

 

Test환경 Teardown

테스트 코드에는 setUp과 tearDown이라는 용어가 존재한다. setUp은 테스트를 실행하기 위해 준비를 하는 과정이고, tearDown은 테스트가 모두 실행된 이후 테스트 환경(Database포함)을 초기화 하는등의 정리과정을 의미한다. 현재 작성한 코드는 외부에 테스트용 실제 DB를 따로 두고 있다(만약 Memory활용 테스트를 사용한다면 이 과정은 따로 필요하지 않다) 그렇기에 따로 테스트 후에 테스트 DB에 대해 tearDown하는 과정을 진행할 것이다.

현재 사용하고 있는 ORM은 Prisma ORM이다. Prisma에서는 아래 명령어를 통해서 타겟 데이터베이스를 Reset 할 수 있다.

npx prisma db push --force-reset

 

Discord Alert

기본적으로 Action의 Step의 상태(성공여부)는 Actions Dashboard에 들어가서 직접 보고있어야 한다. 하지만 이를 보고있는것이 아닌 알림이 오도록 하면 편하지 않을까? 라는 생각을 하게되었다. 현재 프로젝트를 하고 있는 팀의 소통은 Discord로 하고 있으며, Commit Log의 추적도 Github Webhook을 통해 관리하고 있었기에 Discord로 알림 플랫폼을 선택하였다.  이 CI에서도 Job이 성공했는지 실패했는지에 대한 Status를 추적하도록 알림을 보내주면 계속 보고있을 필요가 없다.

 

이를 위해 직접 Job에 JavaScript코드를 넣거나, cURL을 통해 Webhook방식의 알림을 주어도 되지만, Third Party Action인 

rjstone/discord-webhook-notify@v1 를 적용할 것이다.(물론 이외 다른 Action을 만들어도 된다)

 

다음 포스트는 위 설계를 기반으로 한단계씩 구현해볼것이다.