CI, CD 정리

CI, CD 기초

Udemy 강의 DevOps, CI/CD for Beginners 참고

 

기본적으로 SDLC(Software/System Development Life Cycle) 에 대해서 이해하고 CI, CD를 통해서 IT시스템이 어떻게 발전했는지 확인

 

 

CI (Continuous Integration)

1. 이전 방식의 소프트웨어 개발 라이프사이클

CI/CD 적용 이전에 라이프사이클

1. 개발자가 git 등 저장소 각자의 브랜치에 코드를 커밋

2. Build, Integration을 담당하는 파트에서 각 브랜치를 merging하고 빌드 통해서 완성된 소프트웨어 패키지를 Operation 파트에 전달

3. 테스트 환경에 배포된 버전으로 QA팀에서 QA진행

4. 버그 발견 시, 다시 1번 스텝으로 돌아가고 QA 검증 완료 시, 운영환경에 배포

2. 이전 방식의 Integration의 단점

위의 라이프사이클에서 1 → 2로 넘어가는 스텝을 좀 더 자세히 보기 위해서 A회사에는 크게 개발파트가 회원, 상품, 주문 이렇게 세 파트로 나뉘어진다고 가정.

각 파트별로 개발 건은 각자의 브랜치에 커밋해두고 Integration 작업 시에 각 파트 리더가 Build&Integration 팀과 협업해서 각자의 개발 건이 문제 없이 빌드 될 수 있도록 협업한다. 하지만 이러한 과정에 비효율이 발생한다.

1. 보통 이러한 Integration 작업이 수작업으로 이루어졌기 때문에 시간소요가 많았고 잘못된 머징으로 에러가 자주 발생한다.
2. 각 파트별 작업분이 모두 합쳐진 완성본은 라이프사이클의 마지막에서 테스트 환경에 배포된 이후에야 확인할 수 있으므로 이슈를 확인, 수정하는 작업이 늦어진다.
3. 기능 오류의 경우, QA 단계 이후에 이를 확인할 수 있으므로 다시 개발자에게 수정요청이 오는 피드백시간이 길다.

3. Continuous Integration

CI (지속적 통합) 은 개발자가 git과 같은 코드 저장소에 자신의 작업분을 짧은 텀으로 계속 업데이트해서 코드의 최신화를 최대한 보장한다.

 

보통 CI를 "빌드프로세스 자동화" 로만 생각하는 부분이 있는데 그것보다 전체적으로 개발자들이 일하는 방식의 변화라고 생각하면 좋을 듯 하다.

1. CI를 위해서 각 개발파트는 동일한 소스컨트롤 리파지토리를 사용해야하고, 모든 작업이 완료된 이후에 한번에 브랜치의 내용을 master브랜치로 머지하는 것이 아니라 수시로 해당 머지 작업을 해야한다. 이렇게 함으로써 이전 라이프사이클에서 Build, Integration파트에만 있던 소스 머징에 대한 롤이 각 영역별 개발자들에게 분배된다. 개발자가 자신의 코드를 제일 잘 알기 때문에 Integration 작업을 수행하는데 있어서 가장 효율적으로 처리할 수 있다.
2. 개발자가 자신의 코드를 커밋하고 이것이 기존 코드와 충돌없이 제대로 돌아가는지 알기 위해서 주기적으로 컴파일을 해야한다. 기존 라이프사이클에서 Integration, Build 파트에서 수기로 작업하던 부분을 자동화하기 위해서 따로 Build Server를 두고 이를 처리한다. 전체적인 빌드 프로세스는 커밋에 자동 트리거 되어서 돌아가도록 한다. 빌드 오류 발생 시, 이를 해당 개발자, 파트에 메일 발송해서 바로 확인할 수 있도록 한다.
3. 빌드 시점에 중요한 중요한 유닛테스트 등을 자동 수행해서 코드의 퀄리티를 보장할 수 있도록 한다. 그리고 전체적인 빌드 파이프라인(컴파일, 테스트, 패키징)에 소요되는 시간이 최대한 줄임으로써 개발자가 자신이 개발한 코드에 대한 빠른 피드백을 받을 수 있도록 한다.
4. 컴파일 에러 등이 발생 시, 다른 개발자들의 빌드프로세스에도 영향을 미칠 수 있으므로 오류수정이 가장 최우선의 태스크가 되어야 한다.

4. CI 도입을 통해서 이전 방식에서 어떤 개선이 있었는가

CI 이전에 Integration 단계에서 발생하던 문제가 CI 도입 이후에 어떻게 해결될 수 있는지 정리되어 있다.

옛날 방식의 Integration의 단점이 CI 도입 이후에 어떻게 해결될 수 있는지

결과적으로 시간, 개발리소스 등의 낭비를 줄이고 훨씬 안전한 방법으로 작업하는 코드의 최신화, 안정화를 보장할 수 있다.

 

CD (Continuous Delivery)

1. CD 이전 방식의 단점

이전 프로세스를 통해서 전체적인 빌드가 완료되면 개발팀에서는 구동 가능한 패키지, 배포 instruction을 Operations 팀에 전달하고 Operations 팀에서는 instruction을 참고해서 배포하고자 하는 테스트 서버 환경에 배포하고 이후에 QA를 통해서 운영에 나가도 되는 퀄리티라면 운영배포를 진행한다. 하지만 수기로 배포를 진행하면 발생할 수 있는 문제점이 몇가지 있다.

1. 사람이 직접 배포하면 각 배포 환경 별 차이(ex. 환경변수 등) 가 혼동될 수 있다.
2. 마이너한 수정본이 배포를 나간다고 해도 배포를 담당하는 파트에 요청하는 것부터 전체 스텝을 다 거쳐야 하므로 시간이 오래 걸린다. 그리고 배포를 위한 서버 downtime 또한 늘어나게 된다.

2. CD (Continuous Delivery)

CD는 소프트웨어가 언제든지 운영에 릴리즈 될 수 있음을 반영한다. CD가 가능하려면 기본적으로 CI가 보장되어 있어야 하므로 CI, CD는 하나의 큰 꼭지에서 이해하는 것이 맞다.

CI 를 통해서 나온 빌드 최종 산출물인 패키지는 운영이나 테스트환경에 바로 배포될 수 있고 이를 서버에 배포하기 위한 쉘스크립트를 작성해서 관리하면 사람이 수기로 배포에 관여하지 않고 자동화 할 수 있다.

 

운영배포까지 전체적인 프로세스가 모두 자동화되어서 처리되지는 않고 QA를 통해서 실제 운영배포 여부는 확인 후 처리가 필요하다.

3. CD 도입을 통해서 이전 방식에서 어떤 개선이 있었는가

결과적으로 자동화, 단축된 배포시간 등을 통해서 휴먼 에러를 줄이고 필요한 배포건이 있을때 신속하게 이를 운영환경에 배포할 수 있다.