현재 백엔드에서 코드를 업데이트하고, 기능을 추가하면 해당 build 파일을 직접 팀원들과 공유를 하여 통합테스트를 진행해야한다는 번거로움이 존재한다. 이때 이러한 번거로움을 줄이고자 자동화를 구축하고자한다.

1. 과정

   과정은 다음과 같다.

   1. dev 브런치로 pr, commit 이벤트가 발생한다. 해당 경우에 작성해놓은 git action이 동작하여 build 테스트를 진행한다.
   2. build가 성공적으로 진행이 되면 해당 build 파일을 기준으로 도커 이미지를 만든다.
   3. 만들어진 도커 이미지는 지정이 된 docker register에 올라가게 된다.
   4. 프론트에서 개발자 통합 환경을 구현 시 사용하는 docker compose 파일에는 해당 과정을 위해 이미지를 docker file을 통한 이미지 생성이 아닌 도커 레지스트리에서 이미지를 다운받아서 사용한다.

2. 발생한 문제점

   1. 깃허브 액션을 진행 시 현재 프로젝트 레포지토리의 구조

      프로젝트를 진행할 당시에는 몰랐던 레포지토리의 구조가 문제였다. 해당 구조의 경우 하나의 레포지토리에 fe, be라는 폴더를 만들어서 해당 부분에서 각각의 프론트엔드와 백엔드 부분의 코드를 관리하였다. 다만 이때 gitaction에서 세팅하는 기본 프로젝트 루트는 src 등의 기존 프로젝트 내부 코드가 존재해야하는데 해당 과정에서 프로젝트 코드가 바로 존재하는 것이 아닌 be로 한번 더 패키징이 되어있기에 지속적으로 build가 안되는 오류가 발생하였다.

      

      이때 실제로 안에 내용을 살펴보면 ci - build 및 ci의 실패로 인한 도커 배포도 불가능한 상황이었다.

      

      하나씩 해결해보고자 하였고 먼저 build 항목부터 살피기로 하였다.

      • 오류- build

      위와 같은 항목으로 지속적으로 실패하였고, 문제점은 build 시 필요한 gradlew 파일등의 여러 요소의 경로가 잘못되었다고 판단하였다. 생각한 해결 방안은 두 가지였다. 기존의 작성된 레포지토리를 두개로 나누는 것, 혹은 깃액션을 실행할 때 해당 working directory를 재설정하는 것이었다.

      기존의 작성된 레포지토리를 나누는 것은 현재 프로젝트가 많이 진행된 상태에서 진행을 하기에는 많은 코드의 경로 및 설정이 달라지는 부분이라 생각하여 working directory를 재설정하는 것을 목표로 삼고 작업에 들어갔다.

      

      경로를 재설정한 경우이다. 경로 재설정을 위해 repository의 settings, 그리고 secret에서 설정을 해주었다.

      

      

      이러한 식으로 작업을 원하는 경로를 지정하였고 이를 바탕으로 해당 내용을 gitaction 파일에 넣어주었다.

   2. 깃 액션 yml 코드 파일 분할

      기존의 깃 액션 코드의 경우 CICD가 하나의 파일로 진행하도록 작성이 되어있었다. 그렇기에 pr/push를 진행할 때 한번에 진행이 되는데 이때, CI와 CD 하나라도 실패하면 처음부터 다시 시도를 했어야했다. CI를 통과하고 CD를 통과 못하면 CI부터 다시 진행하는 상황이 빈번하게 발생하였고, 그렇기에 CICD의 코드를 나눴다.

      • 기존 CICD
      • 변경 후 CI/CD

      CI의 경우 PR을 진행하면 발생한다. 그렇기에 해당 코드가 올바른지 체크를 하기위해 빌드의 과정과 해당 코드들의 테스트 코드를 확인하는 작업을 진행한다. 해당 부분이 통과가 안되면 merge(push)를 할 수 없도록 add rule을 통해 변경할 예정이다. 이러한 빌드 및 테스트가 통과가 되면 push를 할 조건을 충족하여 이해 merge를 할 수 있도록 설계하였다.

      merge-push가 dev 브런치에서 발생하면 이제 해당 코드를 도커 레포지토리로 CD를 진행한다. 그렇기에 CD의 코드를 보면 빌드, 그리고 docker 연결이 중점으로 작성되어있다.

   3. CD YAML에서의 경로 문제

      • 코드
      • 오류

      기존에 작성된 docker file에서의 경로가 실제 깃 워크스페이스에서의 경로가 틀려서 이미지 생성이 안되는 상황이 발생하였다. 그렇기에 프로젝트 내의 경로를 파악할 수 있도록 dockerfile 내부에서의 경로를 재설정하였다.

   4. git action 진행 시 도커 로그인 및 push에서의 문제점

      1. 비밀번호, Password, accessToken

         기존에 도커 로그인 액션을 진행할 때 비밀번호 항목을 토큰이 아닌 일반 비밀번호를 넣었다. 해당 상황에서는 도커 로그인 액션이 실제로 수행은 되지만 도커 허브에서 발급한 token이 아니기에 해당 레포지토리로 접근할 수가 없었다. 그렇기에 도커 허브에서 access Token을 발급받고 해당 사항을 다시 git secrets 항목으로 지정해줘서 해당 오류는 해결할 수 있었다.

      2. Image name

      • 오류

      이러한 과정을 통해 기본적인 CICD 구조를 완성하였다. 뒤에는 Docker compose 수정 및 각 세팅 별의 application.yml의 환경변수 세팅을 진행하여 해당 Git Action을 고도화 시킬 예정이다.

   5. git action cd 구조

   해당 구조를 통해 진행한 CICD 테스트 과정에서 발견한 문제이다.

   

   깃 액션의 경우 해당 과정을 통해 진행이 된다.

   • Runner
     • Github Actions에서 Job을 실행하는 환경이다. Job이 끝나면 Runner는 초기 상태로 돌아간다.
   • Job
     • 하나 이상의 단계를 포함하는 실행 단위이다. 각 Job은 독립적으로 실행되며 다른 Job과 상태를 공유하지않는다.
   • Step
     • Job 내에서 순차적으로 실행되는 개별 작업이다. 같은 Job 내에서는 상태가 공유되지만, Job간에서는 공유되지 않는다.

   이때 여기서 발생한 문제는 위에서 build와 push를 나눠서 발생한 문제였다. 주어진 코드를 빌드하여 서버를 실행할 수 있는 jar 파일을 생성하였지만 runner를 구분하였기에 Step에서 작업한 내용이 공유되지 않아서 발생한 문제였다.

   

   그렇기에 해당 과정에서 jar 파일이 없는 상태로 이미지가 생성이 되고 배포가 되어서 다음과 같은 상황이 만들어졌다.

   공식 문서를 읽고 해당 작업이 정확히 어떤 역할을 하는지 파악하고 기존에 분리했던 작업의 과정을 하나로 합쳤다. 해당 과정을 진행하고 docker compose 파일로 이미지를 가져올 수 있도록 지정하여 만들어진 백엔드 기준의 기본 개발환경이다.