- Today
- Total
개발하는 고라니
[DevOps] CI / CD 본문
기존에 개발을 하며 종종 들어보거나 무엇인지 대충 찾아본 적은 있다. Continous Integration, Continous Delivery or Continous Deployment... 지속가능한 통합, 지속가능한 배포... 이정도로만 알고있었다. 심지어 처음에 들었을 때 '이걸 왜 쓰지??' 라는 생각이 들었다. 그만큼 필요성을 느끼지 못했었고 지금 생각해보면 경험 부족으로 인한 것이었다.
지금은 그 필요성을 느끼게 되었다. 프로젝트를 진행하는데 총 3개의 서버(어플리케이션)을 관리하고 있고, 이를 배포하기 위해 GCP(Google Cloud Platform)를 사용하는데 매번 다음의 과정을 거쳤다.
1) IntelliJ에서 Code 작업
2) git add .
3) git commit
4) Github Repository로 Push
5) GCP의 VM Instance 가서 SSH 켜고,,, Repository에서 Pull
6) Build & Test
7) 기존 서버 죽이기 (kill -9 PID)
8) Deploy (java -jar ,,,)
이 과정을 매번 코드 수정하고 반영할 때마다 하니까 시간도 아깝고 너무 귀찮다. 개발자에게 반복적인 일은 썩 좋지 않은 일이다.
그래서 그동안 익히 들어온 CI/CD의 개념을 잡고, 이를 위해 많은 툴이 있지만 Jenkins를 사용해볼 예정(바뀔 수도 있다)이다. 일단 CI/CD의 정의와 개념을 살펴본다.
CI/CD
※ Summary : [개발 - 빌드 - 테스트 - 배포] 까지의 전 과정을 자동화
매우 빠르게 변화하는 시대 흐름을 따라 서비스도 그에 맞게 맞춰가야한다. 어떻게 하면 시장과 고객의 요구에 빠르게 반응하고, 제품을 출시, 업데이트 할 것이 큰 과제이다. 이를 위해 세계적으로 많은 기업이 CI/CD를 개발 프로세스로 사용하고 있다. 대부분의 회사에서 CI/CD 환경에서 개발하고 있다.
어플리케이션 개발 단계부터 배포 때까지 모든 단계들을 자동화를 통해 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것
CI (Continous Integration)
※ 지속적인 통합
[한 줄 요약]
"여러 개발자가 작성하거나 수정한 코드를 지속적으로 통합하고 테스트하는 것"
CI란, 버그수정을 위해서, 또는 새로 만드는 기능을 위해 작성되는 코드를 Repository에 주기적으로 Build 및 Test해서 Merge 하는 것을 말한다.
CI는 '2가지 핵심 포인트'가 있다.
1. 코드 변경사항을 주기적으로 빈번하게 Merge 해야한다.
동일한 소스파일 위에서 여러명의 개발자가 서로 다른 코드를 작성하고 있다고 가정하면, 오랜기간 변경하다가 Merge 시점이 올 것이다. 이때 서로 다른 코드를 어떻게 통합해서 적용해 나갈 것인지 고생을 하게 된다. 이렇게 되면 코드를 작성하는 시간보다 Merge 충돌을 해결하기 위해 더 많은 시간을 소비하게 된다.
따라서 이 기능을 어떻게 작은 단위로 나누어 메인 Repository에 반영하거나, 작은 단위로 나누어 사용자에게 배포할 수 있을지, 최대한 작은 단위로 나누어 개발하고 통합해나가는 것이 중요하다.
2. 통합을 위한 단계(빌드, 테스트, 머지)의 자동화
주기적으로 Merge된 코드의 변경사항이 자동으로 빌드가 되어 코드 변경사항 이후에도 빌드가 성공적으로 되는지 확인
하고, 기존 시스템에 버그를 초래하지는 않았는지 Test까지 진행되어야 한다.
보통 개발팀에서 이런 식으로 많이 셋업을 하는데, 메인 Repository가 있고 개발자들은 하루에 몇 번씩 메인 Repository에 Merge를 한다. 물론 그 전에 Code Review를 통해 적절한지 컨펌을 받는 것이 선행되긴 한다.
팀에서 만든 CI 스크립트를 통해 추가된 코드와 함께 Repository가 빌드되고, 유닛/통합 테스트 등 여러 테스트도 스크립트를 통해 실행이 된다. 이것이 확인(Green)이 나오면 배포할 때 반영이 될 수 있고, 반대로 실패(Red)가 나오면 문제를 일으킨 개발자에게 자동으로 알림(Slack, Kakao ...)이 간다.
CI는 다음과 같은 장점을 가진다.
- 주기적으로 merge를 하므로 개발 생산성 향상
- 모든 code는 자동으로 Build/Test 되기 때문에 문제점을 빠르게 발견할 수 있다.
- 코드의 변경사항이 작기 때문에 발생되는 결함은 빠르게 수정이 가능하다.
- 모든 개발자들은 자신이 새로 작성한 코드에 한해 '유닛 테스트' 코드를 반드시 포함해야 하므로 더 나은 코드 퀄리티를 가질 수 있다.
CD (Continous Delivery / Continous Deployment)
※ 지속적인 제공 혹은 지속적인 배포
[한 줄 요약]
개발, 통합, 배포, 릴리즈, 테스트를 자동화하여 지속적으로 배포하는 것
Continous Delivery : 배포를 직접 Manage
Continous Deployment : 배포를 Automation
CD는 마지막 배포단계에서 어떻게하면 자동화해서 배포를 만들 수 있을 지 고민하는 단계이다.
CI를 통해 주기적으로 merge된 변경사항들이 자동으로 Build/Test가 되었다면 배포할 준비과정을 거치고, 준비된 Release가 정상적인지 직접 개발자나 검증팀이 검증을 한 뒤 최종적으로 사용자에게 배포해도 되겠다 싶으면 수동적으로 배포한다. (Continous Delivery)
반대로 릴리즈가 준비가 되면 자동으로 사용자에게 배포하게 만들 수 있는데, 이렇게 모든 과정을 자동화 하는 것을 지속적인 배포라고 한다. (Continous Deployment)
둘이 비슷하지만, 이를 자동화 하는지, 수동으로 검증하고 배포하는지에 따라 의미가 조금씩 달라진다.
Continous Delivery
- CI의 Build 자동화, 유닛/통합 테스트 수행 후, 이어지는 지속적 제공 프로세스에서는 유효한 코드를 Repository에 자동으로 Release 한다.
- 개발자가 Application에 적용한 변경 사항이 버그 테스트를 거쳐 Repository에 자동으로 업로드된다.
- 프로덕션 환경으로 배포할 준비가 된 코드베이스를 확보한다.
- 운영팀에서 이 Repository 내 Application을 실시간 프로덕션 환경으로 배포할 수 있다.
- 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.
Continous Deployment
- 지속적 제공의 확장 형태
- 개발자의 변경 사항을 Repository에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 Release한다.
- 개발자가 Application에 변경 사항을 작성한 후 몇 분 이내에 어플리케이션을 자동으로 실행할 수 있는 것을 의미
1. 개발자가 작은 단위로 기능을 나눠 주기적으로 메인 리퍼지토리에 머지 (Code)
2. 자동으로 빌드(Build)
3. 자동으로 테스트(Test)
4. 릴리즈 준비 (Release)
5. 수동/자동으로 최종 배포를 거치게 된다. (Deploy)
CI/CD Tools
CI/CD를 할 수 있는 툴은 다양하게 있으므로, 회사나 팀에 따라 적당한 것을 사용한다고 한다.
각 툴별 차이점은 여기 에서 확인할 수 있다.
# References
드림코딩by엘리 - CI/CD 5분 개념 정리 (현업에서 쓰는 개발 프로세스)
https://velog.io/@hanblueblue/CIContinuous-Integration-CDContinuous-Delivery