Spring Batch 에서 TeamCity 간단 사용후기

TeamCity 는 JetBrains 사가 개발한 CI/CD tool 로 2006 년부터 서비스되고 있다. Jenkins 와 같은 포지션에 있지만 새로운 CI/CD tool 이 필요하다면 TeamCity 를 쓰는걸 추천하고 있다.

어떤 문제점을 해결할 수 있을까?

기존의 문제점

• 배치 모니터링에 대한 부재로 운영 및 관리가 어렵다.
  • Elastic 을 활용하면 어느 정도 모니터링은 가능하나, 문제가 생겼을 경우 빠른 재실행이나 재배포는 할 수 없다.
• Quartz 스케쥴링으로 인하여 시간간격 임의 조정이 어렵다.
  • 시간을 수정하고 실행하기 위해선 기존 어플리케이션을 종료(!) 해야한다.
• 문제가 생겼을 경우의 재실행이 어렵다.

해결할 수 있는 점

• 모니터링 및 특정 배치 재실행이 용이하다.
• Spring Batch 의 설계를 훨씬 자유롭게 한다. Job, Step 실행순서의 제약에서 완전히 해방되어 외부에서 원하는 부분만 실행시킬 수 있다.
• 외부에서 환경 변수를 주입할 수 있기 때문에, 코드 내부의 설정을 건드리지 않고 외부에서 컨트롤할 수 있게 한다.
• 운영환경에서도 잘 동작할지 확인하는 테스트를 로컬에서 원격으로 실행시킬 수 있기 때문에, 동작 확인을 위한 배포가 필요하지 않다.
• 무중단 배포가 가능해진다.

현재 배치의 실행 상태를 아주 편리하게 모니터링할 수 있다.

TeamCity 만의 장점

IntelliJ 및 타 IDE와의 통합

commit 하기 전 build 가 통과할지 원격으로 실행시켜볼 수 있다.

remote 로 동작하면서 관련 로그를 IntelliJ 로 알려주기까지 한다. 이렇게 개인이 커밋 전 실행한 빌드 결과는 다른 사람이 볼 수 없게 되어 있어서 테스트로 활용한 에러로 얼룩진 로그도 타인에게 불편함을 주지 않는다.

이것저것 테스트하느라 에러가 엄청나지만, 아무 눈치 볼 필요가 없다!

이전 빌드 재활용으로 빠른 파이프라인 실행

파이프라인을 구성하면 이전 빌드의 아티팩트에 의존하게 설정할 수 있다. 따라서 트리거 등으로 배치가 실행될 때, 종속된 빌드의 아티팩트가 이미 존재한다면 빌드를 재실행하지 않고 이미 완성된 아티팩트를 사용하여 파이프라인이 동작한다.

 

결론

만약 현재 배치의 모니터링 및 운영 관리 툴이 필요하다면 TeamCity 를 적극 추천한다. Jenkins 에 비해 눈이 즐거운 UI 와 편리한 UX 를 제공해준다. 전체적으로 직관적인 UI 라서 러닝 커브도 높지 않은 편이니 부담갖지 말고 활용해보시길 바란다.

 

 

TeamCity Documentation Home | TeamCity On-Premises