CI/CD
애플리케이션 개발 단계를 자동화하여 좋은 품질의 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법.
- 지속적인 통합
Continuous Integration - 지속적인 전달
Continuous Delivery - 지속적인 배포
Continuous Depolyment
지속적인 통합 CI
- 지속적으로 코드들의 통합을 진행하면서 코드의 품질을 유지하기 위한 방법
- 빌드, 테스트, 병합
- 시스템 개발을 하는 동안 여러 개발자들이 특정 시점에 개발된 코드를 모두 병합하기는 힘들기 때문에, 빌드, 테스트, 머지를 자동화된 프로세스를 이용해 최대한 자주 코드를 통합하기 위함
- local에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인
CI Tool
- Hudson
- Bamboo
- Jenkins
Jenkins vs Travis CI
💡 서버
- Jenkins는 별도의 인스턴스가 필요하다. 서버 기반이다.
- Travis CI는 웹 서비스 형태여서 별도의 인스턴스가 필요 없다. 클라우드 기반이다.
💡 커스터마이징
- Jenkins는 정교한 설정이 필요하다. 제공되는 기본 설정이 없고, 시스템에서 모든 것을 구성해야 한다.
- Travis는 시작하는 데 시간이 훨씬 적게 걸린다. config파일(yml)을 만들고 통합을 시작한다.
💡 비용
- Jenkins는 무료다.
- Travis는 오픈 소스 프로젝트는 무료 10,000크레딧을 제공하고, 기업용은 유료다.
Travis CI
spring boot에서 Travis CI를 구동시키려면, build.gradle과 같은 위치에서 .travis.yml파일을 만들어서 아래와 같이 설정해준다
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
language: java
jdk: openjdk11
branches:
only: master
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
before_install:
- chmod +x gradlew
script: "./gradlew clean build"
notifications:
email:
recipients:
- 이메일주소
- branches
- Travis CI 를 어느 branch 가 push 될 때 수행할지 설정
- 예시는 master 브랜치에 push될 때만 수행한다고 설정한 것이다.
- cache
- gradle 통해 의존성을 받게 되면 해당 디렉토리에 cache 하여, 같은 의존성은 다음 배포 때부터 받지 않도록 설정
- script
- branch 에 push 되었을 때 수행하는 명령어
- notifications
- Travis CI 실행 완료 후 자동 알림 설정
CI 동작하는 과정
- 개발자가 코드를 작성하고 공유 저장소(Git)에 변경 사항을 커밋한다.
- 그 후 CI 서버는 리포지토리를 모니터링하고 모든 변경 사항을 평가한다.
- CI는 시스템을 구축하고 통합 및 단위 테스트를 수행한다.
- 서버가 배포 가능한 앱을 릴리스한다.
- CI 서버는 버전 및 빌드된 코드에 빌드 태그를 할당한다.
- 그런 다음 CI 서버는 성공적인 빌드에 대해 개발 팀에 보고한다. 만약 테스트가 실패하면 서버는 개발 팀에 이벤트에 대해 경고를 보낸다.
지속적인 전달 CD
- 자동화된 프로세스를 통해
빌드,테스트,병합과정을 거친 후 원격 레포지토리에 자동으로 업로드 - 효과적으로 지속적인 전달을 수행하기 위해 지속적인 통합에서 지속적인 전달까지 파이프라인 연결 필요
지속적인 배포 CD
- 지속적인 제공의 확장된 형태
- 애플리케이션을 production 환경으로 배포하는 작업을 자동화한 것
- repository의 코드 변경이 감지되면, 변경된 내용들은 고객이 사용 가능한 프로덕션 환경까지 자동으로 release
- 해당 프로세스는 비즈니스적인 결정 후 관리자에 의해 진행
