CI/CD 란?
요즘같이 빠르게 진화하고 변화하는 시대에서는 시장과 고객의 요구에 빠르게 반응해서 제품 출시 & 업데이트를 해야 한다.
Application 개발 단계부터 배포까지 Application Life-cycle 전체에 걸쳐 지속적인 자동화와 모니터링을 통해 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것을 말한다.
이러한 구축 사례를 CI/CD pipeline 이라 부르며, 개발 및 운영팀의 Aglie 방식 협력을 통해 DevOps 또는 SRE 방식으로 지원된다.
CI (Continouse Integration) 지속적인 통합
DevOps 의 life-cycle 단계로, 버그수정이나 새로 만드는 기능들이 main repository 에 주기적으로 build -> test -> merge 되는 것을 말한다.
예를 들어, 어떤 project 를 배포한 후에 특정 기능에 문제가 생겨 정상적으로 동작하지 않았다면, 문제파악 -> 버그수정 -> 빌드 -> 테스트 -> 재배포 등의 과정을 거쳐야 한다. 이 과정들은 시간도 오래 걸릴 뿐더러 개발자가 수동으로 진행하기 때문에 실수할 확률도 커지게 된다.
2가지의 point
- 코드 변경사항을 주기적으로 빈번하게 merge 해야 한다.
예로, 2명의 개발자가 각기 다른 코드를 작성하고 있다가 오랜기간 후 merge 를 할 경우, 그 충돌을 해결하는데 있어서 많은 시간을 소비하게 된다. 때문에 버그를 수정하거나 새로운 기능을 개발할 때에는 최대한 작은 단위로 나눠서 통합해 나가는 것이 중요하다. - 주기적으로 merge 된 변경사항이 자동으로 build 되고, 기존 시스템에 다른 버그를 초례하지는 않았는지 테스트까지 자동으로 되어야 한다. 또한 각 step 마다 성공/실패 여부를 알아야한다.
process
- 개발자들은 code review 를 통해 적절한 code 인지 confirm 을 받은 후 주기적으로 코드 변경사항을 main repository 에 merge 한다.
- 이후 merge 된 코드들은 CI script 를 통해 추가된 코드와 함께 main repository 에 build 된다.
- 성공적으로 build 된다면 팀에서 작성한 unit test, intergration test 등 여러 test 들도 script 를 통해 실행된다.
- 위 과정을 실행하는 도중 문제가 발생하면 문제가 발생한 부분과 함께 문제를 일으킨 개발자에게 자동으로 알려준다. (예: 방금 merge 한 부분에서 문제가 발생했다고 slack 을 통해 알려줌)
CI 의 규칙 및 원칙
main repository 에 자주 commit/check-in 해야 한다.
개발자가 코드를 작성 후 Test 하지 않고 오래 보유하고 있을 수록 main repository 와 merge 단계에서 충돌이 발생할 확률이 커진다.
별도의 Build 및 Test 서버 유지
빌드 목적으로만 전용 시스템을 유지 관리해야 한다. 이렇게 하면 빌드 프로세스 속도가 빨라지고 다른 개발자의 workflow 에 미치는 영향이 최소화된다.
Build 및 Test 는 자동화되어야 한다.
main repository 에 commit 된 모든 코드 조각은 CI tool 을 사용하여 자동으로 Build 되고 Test 되어야 한다.
Production 과 같은 Test 환경 사용
테스트 환경은 최종 Production 환경을 Simulation 해야 한다. 이를 통해 Test 환경의 유용성을 보장하고 배포 전반에 걸쳐 기대치를 일관되게 유지한다.
CI 장점
- 주기적으로 merge 를 하기 때문에 merge 충돌을 피할 수 있어서 개발 생산성이 향상된다.
- merge 되는 코드들은 자동으로 Build -> Test -> Merge 되고 이 과정을 거칠 때마다 자동화된 build tool 이 check-in 또는 브랜치를 검증하여 오류를 조기에 발견할 수 있다.
- 발견된 결함은 빠르게 수정이 가능하다. 이유는, 주기적으로 merge 를 하기 위해서는 코드를 작은 단위로 나눠서 통합을 해야하기 때문에 발견된 문제를 수정할 때에도 조금 더 고립된 작은 단위의 문제를 수정하면 되기 때문이다.
- 이런 것들을 통해서 조금 더 나은 코드 퀄리티를 가질 수 있다. 이유는, CI 를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성하는 코드에 한해서 unit test 를 꼭 포함해야 하기 때문이다.
- CI 를 사용한다면 project 대부분의 소스코드들이 자동으로 test 가 될 수 있도록 만들어야 하기 때문에 조금 더 안정성 있는 제품을 개발해 나갈 수 있다.
CD (Continuouse Delivery or Continouse Deployment)
Continouse Delivery 란, CI 를 통해 주기적으로 merge 된 변경사항들이 자동으로 Build 되고 Test 되는 과정을 거친 후, release 준비과정을 거쳐 준비된 release 에 문제가 없는지 검증을 마치고 수동으로 배포하는 단계 말한다.
그리고 Continouse Deployment 란, release 가 준비되자마자 최종 사용자가 사용 가능한 production 환경까지 release 하는 과정 전체를 자동화 해놓는 것을 라고 한다.
이런 모든 과정들을 어떻게 자동화를 해두냐, 어떻게 script 를 쓰느냐, 그리고 이 자동화와 Testing 에 대해 얼마나 자신감이 있느냐에 따라서 최종 단계는 수동으로 release 할 수도 있다.
CI/CI 파이프라인 정리
- 개발자가 작은 단위로 기능을 나눠서 주기적으로 main repository 에 merge 를 한다.
- 자동으로 Build 를 거친다.
- 자동으로 Test 과정을 거친다.
- Release 준비
- 수동 또는 자동으로 최종 배포를 진행한다.
결론
CI/CD 는 pipeline 으로 표현되는 실제 process 를 의미하고, Application 개발에 지속적인 자동화 및 모니터링을 추가하는 것을 의미한다. 대부분의 기업에서는 CI 를 먼저 추가한 다음 cloud native application 의 일부로서 배포 및 개발 자동화를 구현해 나간다.
Tool 정리
- Jenkins
- Buildkite
- Github Actions
용어정리
- cloud native application
- SER
참조
'개발 > DevOps' 카테고리의 다른 글
| Flutter 에서 CICD 적용기 (with github actions) (0) | 2025.09.29 |
|---|---|
| [Flutter] fastlane 도입기 (0) | 2025.01.23 |
| CI/CD 도입 일지 (2) | 2024.12.16 |
