데일리의 Java 백엔드 개발자는 Docker 기반의 CodeShip Pro를 애용하는데 최근에 빌드가 급격히 느려지는 문제를 겪었다. 빌드가 느려진 원인은 다양하지만 그 중 일부는 CodeShip Pro의 캐싱 방식, 더 정확히는 도커의 캐싱 방식과 관련이 있다.
CodeShip Pro는 pom.xml
또는 build.gradle
을 보고 빌드에 필요한 라이브러리를 미리 가져와서 캐싱하기를 권장한다.
# We're using the official Maven 3 image from the Docker Hub (https://hub.docker.com/_/maven/).
# Take a look at the available versions so you can specify the Java version you want to use.
FROM maven:3
# INSTALL any further tools you need here so they are cached in the docker build
WORKDIR /app
# Copy the pom.xml into the image to install all dependencies
COPY pom.xml ./
# Run install task so all necessary dependencies are downloaded and cached in
# the Docker image. We're running through the whole process but disable
# testing and make sure the command doesn't fail.
RUN mvn install clean --fail-never -B -DfailIfNoTests=false
# Copy the whole repository into the image
COPY . ./
예전에는 이 방식이 문제가 안 됐는데 최근 들어 캐시 적중률이 급격히 낮아졌다. 여러 애플리케이션이 공유하는 라이브러리를 몇 개 추가했는데 그 중 하나가 빈번히 업데이트되는 게 문제다. pom.xml
파일을 자주 수정하는데 그 말인즉 COPY pom.xml ./
줄부터 다시 빌드해야 한다는 뜻이다. 그러므로 RUN mvn install clean --fail-never -B -DfailIfNoTests=false
을 실행하는 횟수가 많고 평균 빌드시간이 장난 아니게 늘어난다.
CodeShip Pro에서 이 문제를 해결하는 방법은 비교적 간단하다. pom.xml
파일을 둘로 쪼개면 된다. 자주 수정하는 `pom.xml` 파일부터 빌드하면 빌드 시간을 종전처럼 끌어내릴 수 있다.
COPY
pom-not-frequently-changed.xml./
RUN mvn -f=pom-not-frequently-changed.xml install clean --fail-never -B -DfailIfNoTests=false
COPY pom.xml ./
RUN mvn install clean --fail-never -B -DfailIfNoTests=false
하지만 CodeShip Pro가 이와 유사한 문제로 여러 번 문제가 된 터라 Travis-CI로 옮기면 어떤 장단점이 있는지 확인해보았다.
.travis.yml
파일을 수정하고 테스트하려면 git push
를 반복해야 한다.빌드 환경을 이전하기는 그리 어렵지 않다. 하지만 장단점이 명확하다 보니 어느 게 꼭 좋다 말하기 힘들다. 상황에 따라 결정하는 수밖에.
#데일리 #데일리호텔 #개발 #개발자 #개발도구 #도입후기 #일지 #인사이트 #조언
관련 스택