[프로젝트 설계] CI CD workflow

CI

CI환경 : ubuntu
실행시점 : dev 브랜치로 PR 요청 시

steps :

• JDK 11 version 으로 설정
• gradle 의존성 패키지 캐싱
• gradlew 파일에 대한 실행권한 추가
• 테스트를 제외한 프로젝트 빌드
• mysql, redis 설정
• secret 파일 (application-test.yml) 을 불러와서 세팅
• test 코드 빌드
• 테스트 결과 파일 생성

CD

CD환경 : ubuntu
실행시점 : main 브랜치로 merge 시

steps:

• JDK 11 version 세팅
• gradle 의존성 패키지 캐싱
• secret 파일 (application-secret.yml : Jasypt라이브러리를 사용한 설정파일 암호화 key가 담긴 파일) 을 불러와서 세팅
• 프로젝트 폴더 압축
• s3 업로드
• code-deploy에게 배포 명령 실행

Gradle caching 이유

gradle 은 최초로 빌드할때 의존성 패키지들을 모두 다운받고, 빌드시간과 네트워크 통신 시간을 절약하기 위해서 의존성 패키지를 캐싱하여 재사용합니다.
하지만, github actions의 경우 CI or CD가 실행될 때마다 매번 새로운 환경을 구축하고, 새로운 의존성 패키지들을 불러와야 합니다. 따라서, 빌드시간이 늘어나는 현상이 발생합니다.

github actions 는 actions/cache 를 제공하는데 이를 사용하여 의존성 캐싱 작업을 수행할 수 있습니다.

      - name: Gradle Caching
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

path : 캐시의 저장과 복원에 사용되는 runner 내 파일 경로
key : 캐시를 저장, 복원에 사용되는 키
restore-keys : cache-miss 가 발생하였을 때, 사용할 수 있는 후보 키

결과적으로 약 1분정도의 시간감축이 있었습니다.