CI/CD
CI와 CD는 각각 지속적 통합(Continuous Integration, CI)과 지속적 전달/배포(Continuous Delivery/Continuous Deployment, CD)를 뜻합니다.
지속적 통합
지속적 통합은 가능한 자주, 빈번하게 코드의 변경 사항을 레파지토리에 머지해야 한다는 생각으로부터 출발합니다. "빈번하게" 변경 사항을 머지해야 하는 이유는 다음과 같습니다. 긴 시간에 걸쳐 여러 개발자가 레파지토리에 머지하지 않고 개인의 로컬 PC에서 개발을 진행하는 상황을 상상해 보십시오. 그들이 레파지토리에 그들의 변경 사항을 머지할 때 레파지토리에 저장된 코드와 각 개인이 머지하려는 코드는 많이 달라져 있을 것이고, 따라서 변경된 코드 간 충돌이 넓은 범위에서 많이 발생할 가능성이 높습니다. 이렇게 되면 코드를 개발하는 시간보다 충돌을 수정하는 시간이 더 길어질 것입니다. 따라서 가능한 한 자주, 빈번하게 코드의 변경 사항을 레파지토리에 머지하는 것이 좋습니다. 하지만, 레파지토리에 올리기 전에는 반드시 해당 코드가 잘 작동하는지 확인하기 위해 빌드와 테스트를 해야 하므로, "가능한 한 자주, 빈번하게 코드의 변경 사항을 레파지토리에 머지"해야 한다는 것은 개발자들이 하루에도 수십번씩 빌드와 테스트를 해야 한다는 것입니다. 이는 매우 귀찮고 또, 실수로 빌드 혹은 테스트하지 않는 가능성이 있습니다. 이를 해결하기 위해 코드가 레파지토리에 머지되기 전 자동으로 빌드와 테스트가 진행되는 것이 지속적 통합입니다.
CI를 따르면 주기적으로 머지를 하므로 충돌이 일어날 가능성이 작고, 머지되는 코드들은 머지되기 전에 자동으로 빌드되고 자동으로 테스트되므로 혹시 모를 실수를 줄일 수 있습니다. 이러한 장점들로 말미암아 프로젝트의 전체적인 퀄리티가 향상됩니다.
지속적 전달 / 지속적 배포
지속적 전달과 지속적 배포는 레파지토리에 있는 코드를 배포하는 과정에서 일어납니다. "지속적 전달"은 빌드 단계 이후에 모든 코드 변경 사항을 확인하고 사람이 수동으로 배포하는 방식을 말합니다. 이는 자동화된 테스트 외에도 자동화된 릴리스 프로세스가 있고 버튼을 클릭하여 언제든지 애플리케이션을 배포할 수 있음을 의미합니다. "지속적 배포"는 "지속적 전달"보다 한 단계 더 나아갑니다. 이 방법을 사용하면 프로덕션 파이프라인의 모든 단계를 통과하는 모든 변경 사항이 고객에게 릴리스 됩니다. 사람의 개입이 없으며 테스트에 실패하면 새로운 변경 사항이 프로덕션에 배포되지 않습니다. "지속적 배포"는 고객과의 피드백 루프를 가속화하고 더 이상 "출시일"이 없으므로 팀의 부담을 덜어줄 방법입니다. 개발자는 소프트웨어 구축에 집중할 수 있으며, 기능을 업데이트한 후 몇 분 안에 실제 프로덕션에서 해당 기능이 실행되는 것을 볼 수 있습니다.
CI/CD 미사용 vs CI/CD 사용
CI/CD 미사용
- 개발자는 코드를 로컬 환경에서 개발하고, 변경 사항을 GitHub에 푸시합니다.
- 머지 작업을 수행하기 위해 테스트를 위한 환경이 필요하고 해당 환경을 관리해야 하며 해당 환경에서의 테스트를 수동으로 진행해야 합니다.
- 테스트를 통과한 코드는 수동으로 배포 환경으로 전달되어 수동으로 배포 작업을 수행합니다.
이러한 과정은 전부 수동으로 이루어지기 때문에 시간이 오래 걸리고, 인간이 실수할 수 있는 가능성이 커져 안정성이 보장되지 않을 수 있습니다.
CI/CD 사용
- 개발자는 코드를 로컬 환경에서 개발하고, 변경 사항을 GitHub에 푸시합니다.
- CI/CD 파이프라인이 설정되어 있어, GitHub에서 푸시된 코드가 자동으로 머지되고 빌드 및 테스트 됩니다.
- 테스트를 통과한 코드는 자동으로 배포 환경으로 전달되어 자동으로 배포 작업이 수행됩니다.
이러한 과정에서 인간의 개입이 최소화되고, 자동화된 스크립트를 통해 안정성과 신뢰성 그리고 프로세스의 속도가 향상됩니다. 개발자는 빠른 피드백을 받으며 문제를 빠르게 수정하고 새로운 기능을 신속하게 배포할 수 있습니다.
CI/CD 장점
- 빠른 피드백과 오류 감지: 자동화된 테스트를 통해 코드 변경 사항의 문제를 빠르게 감지하고 개선할 수 있습니다.
- 자동화된 빌드 및 배포: 코드 통합, 테스트, 배포 작업을 자동화하여 시간과 인력을 절약할 수 있습니다.
- 안정성과 신뢰성: 자동화된 테스트와 배포 과정을 통해 인간의 실수 가능성을 줄이고 일관된 품질을 유지할 수 있습니다. 이를 통해 안정적인 소프트웨어 배포가 가능해집니다.
- 빠른 배포와 지속적인 개선: CI/CD를 통해 빠른 속도로 새로운 기능과 버그 수정을 배포할 수 있습니다. 작은 단위로 지속적으로 개발, 배포하면서 사용자 요구사항에 신속하게 대응할 수 있습니다.
- 협업 강화: CI/CD를 통해 개발자들은 동일한 코드 베이스에서 작업하고, 자동화된 테스트 결과와 배포 상태를 공유함으로써 팀 내 협업을 강화할 수 있습니다. 문제를 빠르게 파악하고 해결하며, 개발자 간의 의사소통과 지식 공유를 촉진합니다.
- 확장성과 유연성: CI/CD 파이프라인을 구성하여 다양한 환경에서 적용할 수 있으며, 필요에 따라 구성을 조정하고 확장할 수 있습니다. 이는 프로젝트의 규모와 요구사항에 맞춰 유연한 개발과 배포를 가능하게 합니다.
- 오류 복구와 롤백: 자동화된 배포 과정에서 오류가 발생하면 롤백 기능을 통해 이전 안정적인 버전으로 쉽게 되돌릴 수 있습니다. 이를 통해 장애 상황에서의 복구 시간을 단축하고 안정성을 유지할 수 있습니다.
정리
앞에서 보았듯 CI와 CD는 따로따로 분리된 개념이긴 하나 비슷한 업무의 동일선상에 자리 잡고 있기 때문에 같이 불리곤 합니다. CI/CD 파이프라인을 한 번 더 정리하자면 다음과 같습니다.
-> 개발자가 작은 단위로 개발하고 주기적으로 코드를 메인 레파지토리에 머지합니다. (CI)
-> 자동으로 빌드됩니다 / 자동으로 테스트됩니다. (CI)
-> 릴리즈하기 전 수동 혹은 자동으로 확인하고 배포합니다. (CD)
** 참고로, CI/CD 툴로는 Jenkins, Buildkite, Github Actions, circleci 등이 있습니다.
https://www.youtube.com/watch?v=0Emq5FypiMM
Continuous integration vs. delivery vs. deployment
Learn the difference between continuous integration, continuous delivery, and continuous deployment in modern software development and DevOps.
www.atlassian.com
'프로그래밍 기초' 카테고리의 다른 글
| Docker Compose (0) | 2023.05.23 |
|---|---|
| 깃허브 액션 (2) | 2023.05.15 |
| 클린 아키텍처 번역 (0) | 2023.03.28 |
| int와 Integer의 차이 (0) | 2022.11.05 |
| 커플링(coupling), 디커플링(decoupling) - 번역 (0) | 2022.10.22 |