Travis로 CI를 해보기에 앞서 간단한 용어들을 정리하고자 합니다.
간단 용어 정리
CI/CD란 무엇이며 왜? 하는가?
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.
-- Red Hat Article [what is CI/CD?]
CI
CI란 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이란 말을 풀어 설명하자면 `빌드/테스트 자동화 과정`을 말합니다. 즉, 새로운 코드가 변경하게 되면 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합을 하게 되고 변경으로 인한 문제가 생기는 것을 방지해주는 역할을 해줍니다. 또한, 여러 명의 개발자가 동시에 애플리케이션 개발을 하더라도 서로 충돌할 수 있는 문제를 해결해줄 수 있습니다.
CD
CD는 지속적인 배포(Continuous Deployment) 혹은 지속 적인 서비스 제공(Continuous Delivery 라고도 합니다. 배포를 자동화 하는 것이죠.
지속적인 배포(Continuous Deployment)는 공유 레포지토리의 변경이 생기고 테스트 라인을 성공적으로 통과하면 수동이 아니라 자동으로 해당 변경 사항을 실제 프로덕션 환경에 배포(Release)하는 것을 말합니다.
CI/CD는 어느 정도의 자동화를 하는지에 따라 다르기 때문에 회사에 따라 다를 수 있습니다.
CI / CD 종류
- Jenkins
- CirdleCI
- TravisCI
- Gihub Actions
- etc
CI / CD의 흐름
현재 프로젝트에서는 따로 테스트 코드를 작성하지 않지만 만약 테스트 코드가 작성되어 우리의 프로젝트에 오류를 찾을 수 있다고 생각합시다. (제가 생각한 흐름이라 정확하지 않을지도..)
- feature 브랜치에서 개발자가 작업을 하고 작업 브랜치로 Push를 합니다.
- 기존에 설정된 CI서버에서 push를 인지하고 Build, Test, Lint 등을 실행합니다.
- 개발자가 작성된 코드에 문제가 있다면 에러를 수정하고 1~3 과정을 반복합니다.
- 문제가 없다면 main에 PR하고 Merge하여 모든 테스트가 정상적으로 수행 되었을 때 CI 서버가 Deploy 과정을 진행하여 자동 배포를 해줍니다.
그래서 왜 CI / CD를 하는가?
앞어 용어정리를 하면서도 이해되셨겠지만 배포 자동화를 하면서 개발자의 일이 많이 줄어듭니다. 향로님의 책에 따르면 기존에는 개발자들이 하루를 merge하는 날(병합일)로 정해 합쳐서 배포를 했었는데 이는 개발자들의 리소스를 많이 소비하고 많은 시간을 낭비하게 했습니다.
CI/CD가 가능해지면서 빌드, 테스트, 배포 과정이 자동화되고 개발자들은 자연스럽게 개발에 집중할 수 있다는 장점이 있다고 합니다.
실제 프로젝트를 하면서 배포에 소요되는 시간이 많았고, 필요성을 느끼게 되어 글과 함께 배포 자동화를 구성해보려고 합니다.
하지만, CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아니라고 합니다.
책에서는 마틴 파울러의 블로그의 글에 있는 CI에 대한 4가지 규칙을 참고하여 설명했습니다.
- 모든 소스 코드가 살아 있고 (현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
- 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
위에서 가장 중요한 것은 테스팅 자동화 라고 합니다. 지속적으로 통합하기 위해서는 어플리케이션의 상태가 완전한 상태임을 보장하기 위해서 테스트가 준비되어 있어야 한다는 말입니다.
저는 자동화를 통해 시간을 벌어 공부를 하는데 쓰도록 하겠습니다.
Travis CI 자동화 배포 세팅 시작
Travis CI는 깃허브에서 제공하는 무료 CI 서비스이며 Jenkins도 있지만 젠킨스는 설치형으로 CI를 위한 EC2를 준비해야하므로 요금 부담이 적은 오픈 웹서비스를 사용하려고 합니다.
트래비스를 사용하기 위해 https://www.travis-ci.com/로 진입합니다. 저는 깃허브로 회원가입을 했습니다.
오른쪽 위의 Settings로 진입.
세팅을 하기 위해서는 먼저 두가지를 해주어야 합니다.
- Plan 선택 - Free를 선택!
- 이메일 인증
- 세팅하기 위한 레포지토리 설정
1. Plan 선택 - Free를 선택!
본인은 plan탭을 눌러 Free를 먼저 선택해주었습니다.
아래 세부 디테일 넣어 Billing Address 와 결제 정보(카드 번호)를 저장하면 됩니다.
결제정보를 설정하게 되면 다음과 같이 10000 크레딧을 주는 것 같습니다.
2. 이메일 인증
그 다음 본인은 메일로 온 인증절차를 밟고, 만약 메일이 오지 않았다면 스팸처리가 되었을 수 있으니 스팸함을 찾아보시기 바랍니다. 그래도 오지 않았다면 다시 Settings 탭에서 토큰 다시 받기를 하시면 메일이 오는 것을 확인 할 수 있습니다.
3. 세팅하기 위한 레포지토리 설정
보통은 Setting 메인에 Activate를 눌러 Repo를 연동하면 되는 것 같지만, 본인은 Organization에 Repo가 있어
아래 사진 처럼 Review and add 를 눌러 Organiztions 를 추가해주었습니다.
추가해주면 Setting main화면에 다음과 같이 레포지토리가 뜹니다.
본격 프로젝트 Travis 세팅
Ttavis CI 는 .travis.yml 파일로 설정할 수 있습니다. YAML에 대해 궁금하시다면 다음을 클릭해주세요.
CI를 원하는 레포지토리 main에 .travis.yml 파일을 다음과 같이 작성하여 넣으면 됩니다.
# 언어와 jdk의 버전을 지정한다.
language: java
jdk:
- openjdk11
# 어느 브랜치가 push 될 때 수행할지 지정한다.
# 오직 main 브랜치가 push될 때 수행하도록 지정하였다.
branches:
only:
- main
# 빌드 전에 gradlew의 권한을 추가한다.
before_install:
- chmod +x gradlew
# Travis CI 서버의 Home
# gradle을 통하여 의존성을 받게 되면 이를 캐시하여 배포할 때 마다 다시 받지 않도록 설정한다.
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
# main 브랜치에 push 되면 수행되는 명령어이다.
# 프로젝트 내에 권한이 추가된 gradlew를 활용하여 clean, build를 진행한다.
script: "./gradlew clean build"
# CI 실행 완료 시 작성한 이메일로 알람
notifications:
email:
recipients:
- v_donguk@naver.com
이제 다시 travis로 돌아가봅시다!
위에 설정(Plan, 이메일 인증, 결제 정보)을 다 완료하시고 설정 파일을 push하셔야 위 그림처럼 자동 빌드가 되는 것을 확인할 수 있습니다.
2분정도 기다리니 다음처럼 빌드가 됩니다. 생각보다 오래걸려서 오류가 있나 생각했네요. 그래도 무료로 편하게 빌드 배포를 경험할 수 있으니 아주 좋습니다.
메일로도 정상적으로 빌드가 되었다고 왔습니다.
배포 자동화하기 위한 첫 걸음으로 Travis를 설정했습니다. 이제 겨우 `빌드`가 끝난 것이고 우리는 Travis를 통해 빌드된 파일을 어떻게든 EC2로 보내 배포를 해야할 것입니다.
다음 글에서는 빌드된 jar 파일을 저장해 두었다가 옴겨 우리의 EC2 서버에 배포할 수 있도록 S3 Bucket을 활용해보겠습니다.
CI/CD 에 관심이 생기셨다면, DevOps에 관심이 생기셨다면 공부삼아 이런 것도 있구나 하며 다음 글도 읽어보시면 좋을 것 같습니다.
'Infra > CI&CD' 카테고리의 다른 글
Docker를 통한 CI/CD (1) - Docker 이해와 설치 및 사용법 (0) | 2024.01.30 |
---|---|
Travis CI 배포 자동화 (3) - Travis CI, AWS S3, CodeDeploy 연동 (0) | 2022.08.21 |
Travis CI 배포 자동화 (2) - S3 버킷 (0) | 2022.08.21 |