한이음 프로젝트

[한이음] CI/CD

딤섬뮨 2022. 7. 27. 12:24
728x90

우리 프로젝트 중 CI/CD가 있는데 내 파트는 아니지만 처음 들어봤기 때문에 맨날 틈틈이 보다가 드디어

정리를 해본다.

CI/CD는 한마디로 아래와 같이 정의할 수있다.

애플리케이션 개발부터 배포까지 모든 단계의 '자동화'를 통해서 좀 더 효율적이고 빠르게 배포할 수 있는 것을 말한다.

애플리케이션을 완성했다면, 아래와 같은 순서로 사용자에게 서비스할 수 있다.

  1. 컴파일
  2. 빌드
  3. 배포

여기서 CI/CD가 언급되는 곳은 배포 단계이다.

예를 들어 프로젝트에 2명 이상 참여를 하는데 한 명은 빈번한 merge를 실행하고 한명은 2~3일 만에 merge를 하면 충돌이 날것이고, 개발자는 그 충돌을 수정하는데 시간을 쓸 것이다. 이렇게 되면 수정하는데 시간을 더 써서 비효율적이다.

그렇기에 가능한 작은 단위로 빈번하게 계속해서 통합하는 것이 중요하다.

CI (Continuous Integration


CI는 Continuous Integration의 약자로 그대로 해석하면 '지속적인 통합'이라는 의미를 가지고 있다.

개발에서 지속적인 통합이란? 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되는 것을 의미한다.

CI를 적용하게 되면, 개발자 각자가 자신이 구현해야 할 기능을 구현하기만 하면 된다. 완성이 되면, main 브랜치와 통합하고 코드가 잘 빌드되는지 확인한 뒤 올바르게 동작하는지 테스트하며 코드에 버그가 있다면 해결한다.

하지만, 개발자가 직접 코드를 병합하고 빌드, 테스트를 검증하는 것은 시간이 많이 소요될 뿐만 아니라 매우 매우 귀찮고 그 양도 프로젝트의 크기가 커질수록 많아질 수밖에 없다.

또한 기능이 추가될 때마다 merge하지 않고, 며칠 동안 작업한 많은 코드를 한 번에 merge 한다면, 분명히 충돌되는 많은 코드가 발생할 것이다.

이를 자동화하면 빌드와 테스트를 개발자가 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 함으로써 빌드와 테스트를 검증할 수 있다.

1. 개발자들은 계속해서 깃헙같은 관리 시스템에 통합

2. 통합된 코드가 잘 작동하는지 빌드 및 테스트 진행

3. 버그 발생 시 수정

 

이러한 단계를 거치게 되는데

 

사실 이 과정이 너무 귀찮다.

Build 하고 테스트하는건 굳이 사람이 반복적으로 하지 않아도 되고 통합 할 때마다 진행해야해서 한번에 몰아서 빌드 테스트 하는 것보다 시간이 오래 걸림.

여기서 자동화를 해주는 것이 바로 CI/CD github에 코드만 올리고 나머지 작업인 테스트와 빌드는 프로그램이 해준다!!!

 

1. 개발자들은 계속해서 깃 헙 같은 관리 시스템에 통합

2. CI/CD를 통해 날아온 버그는 해결

 

결과적으로 버그를 신속하게 찾아 해결할 수 있으며 소프트웨어 품질을 개선하고, 새로운 소프트웨어 업데이트를 검증하고 배포하는 데 걸리는 시간을 단축할 수도 있다.

MSA 환경에서는 기능 추가가 매우 빈번하게 발생하며, 작은 micro service의 동작 테스트도 중요해진다. 이러한 환경에서 CI의 적용은 엄청난 이점을 가져다줄 것이다.

 

CD (Continuous Deployment)


CD는 Continuous Delivery의 약자로 지속적인 배포로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념이다.

CI에서 Build, Test 된 후에 병합까지를 수행했다면, 그 후 저장소에 업로드되면서 배포까지 되는 범위가 CD이다.

CD를 적용한 후의 흐름은 아래와 같다.

  1. CI를 적용하여 코드를 검증한다.
  2. 배포 환경과 비슷한 곳에서 검증을 진행한다.
  3. 검증된 소프트웨어를 실제 프로덕션 환경으로 배포한다.

그리고 CD를 통해 얻을 수 있는 장점은 아래와 같다.

  1. 개발자는 배포보다 개발에 더욱 신경쓸 수있게 된다.
  2. 수작업 없이 빌드, 테스트, 배포까지 자동화를 할 수있다.
 

자 이제 CI/CD를 적용하기 전과 후를 비교해보자.

먼저 CI/CD를 적용하기 전 코드 통합 과정은 아래와 같다.

  1. 개발자들이 코드를 작성하고 수정한다.
  2. 각자의 브랜치에 코드를 push한다.
  3. 코드를 git에 올리고 merge한다.
  4. 에러가 발생했지만, 어디서 에러가 발생했는지 모르기 때문에 디버깅하고 코드를 수정한다.
  5. 1~4의 과정을 반복한다.
  6. 에러가 해결되었으면 배포를 시작한다. 하지만, 배포 과정또한 개발자가 직접 배포과정을 거치므로 많은 시간을 소요한다.

이번에는 CI/CD를 적용한 후의 과정이다.

  1. 개발자들이 코드를 작성하고 수정한뒤 브랜치에 코드를 push한다.
  2. git push를 통해 Trigger되어 CI 서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송한다.
  3. 개발자가 결과를 전송받고 에러가 발생했다면 에러가 발생한 부분을 수정하고 코드를 master 브랜치에 merge한다.
  4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행된다면 CI 서버에서 알아서 Deploy 과정을 수행한다.

CI/CD의 종류로는 아래와 같은 것들이 있다.

  • Jenkins
    • 무료이고, Ref, 정보 생태계가 풍부함
    • Windows, mac, Ubuntu와 같은 다양한 OS 지원
    • 설치와 사용이 간단
  • Bamboo
    • 유료 서비스
    • Windows, mac, Linux와 같은 플랫폼 지원
  • TravisCI
    • 간결하고 직관적인 웹 인터페이스를 제공하는 인터넷 기반 CI 서비스
    • 무료와 기업용 버전이 따로 있다. 오픈소스 프로젝트일 경우 무료로 사용가능하다.
    • Github와 연동하여 Commit/push를 기반으로 CI가 자동 동작하며 Push 외에도 Pull Request에도 반응하도록 설계되어 있다.
  • Github Actions
    • public은 무료, private는 무료 사용량 이후에 과금 부과
    • 별다른 복잡한 절차 없이 Github를 통해 사용할 수있다.
    • GibHub와 통합
    • 모든 언어 애플리케이션 빌드, 테스트 배포 지원

[출처]

CI/CD란?|작성자 조정현

CI/CD란 무엇일까? — 개발자 Miro (tistory.com)

728x90