CI/CD

Continuous Integration/Continuous Delivery/Deployment
Continuous - 계속되는, 지속적인

지속적인 통합, 지속적인 서비스 제공, 지속적인 배포

애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법
새로운 코드 통합으로 인해 개발 및 운영팁에 발생하는 문제(integration hell - 통합 지옥)를 해결하기 위한 솔루션

애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공함.

지속적 통합

Continuous Integration

CI는 Git과 같은 형상관리 시스템 레포지토리 메인 브랜치에 버그수정, 새로운 기능에 대한 코드를 최대한 작은단위로 나누어 빠르고 자주 커밋, 머지하고 이에 대한 변경사항에 대해서 자동으로 빌드하고, 테스트하는 방법임.

순서

1. 메인 브랜치에 코드의 변경사항을 머지함. 단, 코드 리뷰를 통해 적절한 코드인지 확인하는 단계가 필요함.
2. CI의 스크립트를 통해서 추가된 코드와 함께 자동으로 리포지토리가 빌드되고 빌드가 잘 되면 작성한 테스트 코드가 실행됨.
3. 빌드 및 테스트를 통과하면 CD에 반영이 되고, 테스트에 실패하면 테스트를 작성한 개발자에게 알림.

장점

• 주기적, 빈번히 머지하기 때문에 머지 충돌을 피할 수 있음.
• 머지되는 모든 코드들은 자동으로 빌드 및 테스트 되기 때문에 변경되는 코드의 문제나 결함을 빠르게 알 수 있음. 위의 결과에 따라 작고 독립적인 단위의 코드를 다루기 때문에 수정할 때도 좋음.
• 테스트 코드를 포함하기 때문에 더 나은 코드 퀄리티를 유지할 수 있으며 안정성이 좋아짐.

규칙

CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아니라고 하며, 다음과 같은 4가지 규칙을 지켜야 함.

1. 모든 소스 코드가 현재 실행되고, 모든 사용자가 현재 소스코드에 접근할 수 있는 단일 지점을 유지할 것. -> 모든 사용자가 항상 최신 코드에 접근할 수 있도록 해야 함.
2. 누구나 단일 명령을 사용하여 빌드할 수 있도록 빌드 프로세스를 자동화할 것
3. 단일 명령으로 언제든지 테스트를 실행할 수 있도록 할 것.
4. 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것. -> main 브랜치가 자동으로 배포되도록 설정해뒀다면 main 브랜치는 반드시 배포를 했을 때 정상적으로 돌아가는 코드로만 구성해야 함.

지속적 제공/배포

Continuous Delivery/Deployment

CI 과정에서 빌드와 테스트가 완료된 코드를 사용자에게 지속적으로 배포하는 과정
해당 과정이 수동이면 Delivery, 자동이면 Deployment라고 함.

CI/CD 파이프라인

1. CODE: 개발자가 메인 브랜치에 머지
2. BULID: 자동으로 빌드
3. TEST: 자동으로 테스트 진행
4. RELEASE: 릴리즈 준비
5. DEPLOY: 수동 혹은 자동 배포

사용하는 이유?

• 더 적은 버그와 오류
• 가치 실현 기간(time-to-value) 단축
• 개발자의 시간 단축: 개발자는 테스트, 코드 디버깅에 많은 시간을 할애한다고 하는데, 해당 과정을 자동화하여 개발자가 중요한 일에 시간을 사용할 수 있도록 함.

참고 자료

• https://www.redhat.com/ko/topics/devops/what-is-ci-cd
• https://velog.io/@phs880623/CI-CD
• https://hudi.blog/ci-cd/