운영 환경 : GitHub Actions, Ubuntu, Java 17, Spring Boot, Gradle, JUnit5
현재 공부할 겸 연습으로 Spring Boot 프로젝트를 CI/CD로 테스트하고 배포하는 것을 연습 중이다.
CD는 AWS EC2에서 Jenkins와 Docker를 이용하여 배포하고 있고, CI는 GitHub Actions로 하고 있다.
그런데 GitHub Actions로 테스트를 진행할 때 시간이 은근 오래 걸려서 캐시를 이용해서 조금이라도 빠르게 만들어 보려고 한다!
GitHub Actions에서 cache를 하기 위해서는 actions/cache
라는 액션을 사용해야 된다!
해당 액션은 path
에 설정한 작업물을 특정한 key 값을 통해 캐싱하고, 같은 key가 사용되면 저장된 해당 캐시를 불러와 사용할 수 있게 한다.
Gradle 말고 다른 예제도 많아서 더 알아보고 싶으면 아래 링크를 참고하세요!
actions/cache | GitHub
- name: JDK 17 설치
uses: actions/setup-java@v4
with:
distribution: 'oracle'
java-version: '17'
cache: 'gradle'
- name: Gradle 종속성 캐시
uses: actions/cache@v4
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
restore-keys: |
${{ runner.os }}-gradle-
path
: 캐시할 파일과 디렉토리를 지정 key
: 캐시 파일의 고유 식별자 역할 hashFiles
: 주어진 파일들의 내용에 기반하여 고유한 해시 생성restore-keys
: key로 캐시가 일치하지 않을 때 사용할 기본 키를 지정 나는 위 코드를 체크아웃하는 부분의 다음 순서에 추가했다.
Actions
-> Management
항목에서 Caches
를 클릭하여 저장된 캐시를 아래와 같이 확인할 수 있다.
setup-java
와 gradle
에 대한 캐시가 저장된 것을 확인할 수 있다.
GitHub는 7일 동안 액세스되지 않은 캐시 항목을 제거합니다. 저장할 수 있는 캐시 수에는 제한이 없지만 리포지토리에 있는 모든 캐시의 총 크기는 제한됩니다 10GB까지. 리포지토리가 최대 캐시 스토리지에 도달하면 캐시 제거 정책에 따라 리포지토리에서 가장 오래된 캐시가 삭제되고 공간이 만들어집니다. 여기를 참고함
캐시도 잘 복원하여 사용한 것을 알 수 있다!
CI 진행 시간이 3분이나 줄어들었다!!!
JDK 설치 속도는 무려 8초뿐이고, Build도 절반 이상 줄어들어 굉장히 효과적이었다!
GitHub Actions 자체의 성능이 일관적이진 않지만, 그런 것을 감안하더라도 엄청 효과적이다!!
작업 항목 | 캐싱 전 시간 | 캐싱 후 시간 | 감소 비율 |
---|---|---|---|
전체 시간 | 3분 45초 | 45초 | 55.17% 감소 |
JDK 설치 시간 | 3분 | 8초 | 72.41% 감소 |
빌드 시간 | 29초 | 12초 | 58.62% 감소 |
현재까지 진행 중인 CI/CD 구축은 실제 프로젝트로 하지 않고 연습용으로 간단한 프로젝트를 만들어 진행하고 있다.
캐싱을 하기 전까지 드라마틱한 변화를 기대했었고, 결과도 기대보다 엄청 잘 나온 것 같다!
프로젝트 크기가 작은 편이라 캐싱 전과 후의 차이가 더 커보일 수 있지만, 이정도의 차이라면 무조건 캐시를 사용하는게 좋은 것 같다!
실무 경험은 아직 없지만, 학생들이 만들 수 있는 프로젝트 수준이라면 무료로 캐시를 이용해 CI 시간을 줄이는 게 좋다고 생각된다!
[GitHub Actions] cache Action 사용해 반복되는 작업 캐싱하기 | [조세영의 Kotlin World:티스토리]
actions/cache | GitHub
[Github Action] 데이터 좀 맡길게! 나중에 그대로 다시줄래? - action cache | KoB