1. CICD란 무엇일까?
CICD는 Continuous Integration / Continuous Deployment 의 약자 입니다. 한국어로 하면 지속적인 통합 과 지속적인 배포 입니다. Continous 즉 지속적이라는 단어는 바로 자동화를 통한 지속을 이야기 합니다. CICD 시스템은 빌드, 테스트 그리고 배포를 자동화 함으로서 개발자들의 생산성을 높이고 (개발에만 신경쓸 수 있으므로) 배포를 더 빠르게 그리고 더 자주 할 수 있도록 합니다. 이렇듯 더 빠르고 더 자주하는 배포를 바로 지속적인 배포라고 표현하는 것입니다. 다음 이어지는 자세한 설명을 통해 정확히 어떠한 과정을 통해서 지속적인 배포가 되게 하는지 알아보도록 하겠습니다.
2. Continuous Integration(CI)
CICD 는 이름이 명시하는데로 크게 2부분으로 나뉩니다. CI(Continuous Integration) 부분과 CD(Continuous Deployment) 부분으로 나뉘어집니다. 그 중 먼저 Continuous Integration, 즉 지속적인 통합 부분에 대해서 알아보도록 하겠습니다. 여기서 Integration (통합)은 바로 개발자들이 작업한 코드가 통합되어서 하나로 합쳐지는것을 이야기 합니다. 즉, Git 환경에서는 개발자들이 구현한 코드를 담고 있는 feature branch들이 develop branch에 머지되어 스테이징 서버에 배포(혹은 실제 서버에 배포 되지 않더라도 배포 될 수 있는 package나 artifact 형태로 생성)되는 것을 말합니다.
예를 들어, 개발자가 검색 기능을 구현한다고 가정해보겠습니다. 개발자는 다음 과정을 통해서 검색 기능을 구현하고 완료할것입니다.
- 검색 기능을 작업할 feature branch인 feature/search 브랜치를 생성한다.
- 검색 기능을 구현 한 후 feature/search 브랜치에 커밋한다.
- 문제가 없는지 확인하기 위해 (빌드 후) unit test를 실행한다.
- Unit test가 문제 없이 모두 통과하면 (PR 리뷰를 거친 후) develop 브랜치에 merge한다.
- Develop 브랜치에 merge 된 후 develop 브랜치에서 다시 unit test를 실행하여 develop 브랜치에 merge후 버그나 이상이 없음을 확인 한다.
CI는 바로 위 과정중 3번에서 5번까지의 과정을 자동화하여, 개발자가 개발을 끝내고 커밋하는 순간 테스트와 머지까지 자동으로 신속하게 이루어지게 하는 것을 이야기 합니다.
그림[2-1] 개발에서 CI로 이어지는 배포흐름
빌드 부터 테스트 그리고 develop 브랜치까지 merge되는 과정이 자동화가 되었기 때문에, 개발자가 코드를 커밋하고 푸쉬하는 만큼 지체 없이 바로 테스트와 merge가 (하루에도 여러번) 지속적으로 이루어 질 수 있습니다.
3. Continuous Deployment(CD)
Continuous Deployment는 이름 그대로 지속적인 배포를 뜻합니다. Continuous Integration의 다음 부분들이 자동화되는 것을 생각하시면 됩니다. 앞서 살펴본 CI 과정을 거치면 최신 코드들이 develop 브랜치에 merge가 되어 있을것입니다. 이제 실제 유저들이 사용할 수 있도록 배포되려먼 production 서버에 배포가 되어야 합니다. Production 서버의 배포까지 이루어 지기 위해서는 그 전에 많은 테스트들이 이루어져야 합니다.
예를 들어, 다음 과정을 거쳐서 production으로 배포가 이루어질 것입니다:
- Staging 서버에서 최신 코드를 배포한다.
- Staging 서버에서 다음과 같은 다양한 테스트를 실행하여 production에 배포가 될 수 있을지를 판단한다:
- Integration Test
- E2E(End-To-End) Test
- 그 외 Load Test등 필요한 테스트들
- 모든 테스트가 통과 하면 Production 서버에 배포하고 master(혹은 main) 브랜치에 merge한다.
Continuous Deployment는 위 과정들을 자동화하여, 개발자가 개발을 끝내고 커밋 및 푸쉬를 하면 그대로 모든 테스트를 자동으로 거치고 바로 production 배포까지 완료되는 것을 이야기 합니다.
그림[3-1] CI에서 CD로 이어지는 배포흐름
Continuous Integration에 이어 Continuous Deployment 까지 구축이 되면, 개발자는 개발에만 신경쓸 수 있는 개발환경이 구축이 됩니다. 빌드 부터 테스트 그리고 producton 배포 과정까지 모두 자동화가 되었기 때문에, 개발자가 코드를 커밋하고 푸시하자 마자 바로 모든 테스트를 거쳐 production에 배포가 지속적으로 이루어 질 수 있습니다. CICD 시스템이 잘 구축되어 있으면 하루에도 production 배포를 여러번 할 수 있게 됩니다. 실제로 netflix같은 기업은 하루에도 100번 이상 배포를 한다고 알려져 있습니다. 개발자로서, 내가 오늘 구현한 코드를 바로 같은 날에 유저가 사용하게 될 수 도 있는것입니다.
4. Continuous Delivery?
CICD의 CD는 Continuous Deployment의 약자라고 언급했습니다만, Continuous Deployment외에도 Continuous Delivery 로 구현될 수 도 있습니다. Continuous Delivery 와 Continuous Deployment 의 차이는 바로 production 배포까지 모두 100% 자동으로 이루어 지는지, 아니면 production 배포는 사람의 승인을 거친 후에 이루어 지는지에 있습니다.
Continuous Deployment는 잘만 구축되면 정말 개발자의 생산성을 높일 수 있는 좋은 개발 환경을 제공하게 될것입니다. 말그대로 내가 오늘 개발한 기능을 같은날에 유저가 사용할 수 있을정도로 빠르고 신속한 배포가 이루어지기 때문이죠. 개발자는 개발만 잘하면 되기때문에 개발자의 시간을 정말 효율적으로 잘 쓸수 있게 됩니다. 하지만 production 배포가 모두 자동화가 되기 위해서는 테스트의 자동화가 정말 구축이 잘 되어 있어야 합니다. 테스트를 통과하면 유저가 바로 사용하기에 문제가 없다는 확신이 있어야 하는데, 사실 자동화 할 수 있는 테스트만으로는 그런 확신을 얻기가 굉장히 어렵습니다. 그정도로 촘촘한 테스트 자동화 시스템을 구축하기 위해서는 굉장히 많은 공수가 들어가는데 (때로는 실제 개발보다 더 많은 공수가 들 수도 있습니다) 규모가 어느정도 있는 회사가 아니면 그정도의 테스트 자동화 시스템을 구축하기는 어렵습니다. 대부분은 production에 배포되기전에 사람이 직접 실행하는 테스트를 마지막으로 거친 후에 production 배포를 하게 됩니다. 하여, 많은 기업들이 production 배포까지는 자동화를 하지 아니하고 일단 사람의 승인을 거친 후 배포되도록 CICD (Continuous Integration / Continuous Delivery) 시스템을 구축합니다.
그림[4-1] CI에서 CD로 그리고 다시 개발로 이어지는 배포흐름
'Cloud Service > AWS 공부' 카테고리의 다른 글
| [CICD] Github Action으로 CICD 구축하기 4) (0) | 2023.10.28 |
|---|---|
| [CICD] 다양한 CICD Tools 알아보기 3) (0) | 2023.10.28 |
| [CICD] CICD는 언제, 왜 필요할까? 1) (0) | 2023.10.28 |
| [AWS] ALB - [Network] Nginx를 사용한 Load Balancing 적용** (0) | 2023.10.28 |
| [AWS] ALB - [Network] Proxies & Load Balancing (0) | 2023.10.28 |