🌱 개념
Continuous Integration: 지속적인 통합
Continuous Delievery or Continuous Deployment: 지속적인 제공 or 지속적인 배포
CI, CD 두 과정을 합쳐서 애플리케이션 개발 단계부터 배포까지의 모든 단계를 자동화를 하여, 조금 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것을 말합니다.
CI
CI는 버그수정이나 새로 만드는 기능들이 메인 리포지토리에 주기적으로 Bulid되고 Test되어 Merge(통합)되는 것입니다. 이 방법은 Grady Booch에 의해 제안된 방법론이며 Extreme programming 개발 방법론에 채택되었습니다.
과정
CI를 위해서는 코드 변경 사항을 주기적으로 빈번하게 merge해야 합니다. 예를 들어, 동일한 소스 코드를 두 명의 개발자가 코드를 따로 짜고 있다가 오랜 기간이 지나서 나중에 merge를 할려고 할 때, 서로 다른 코드를 어떻게 통합해야할 지 골머리를 앓습니다. 이러면 새로운 기능을 개발하기 위해서 코드를 작성하는 시간보다, merge 충돌을 해결하기 위해서 더 많은 시간을 사용해야 할 수도 있겠죠. 그래서 최대한 작은 단위로 개발하고 통합해 나가는 게 효율적입니다.
효율적인 통합을 위해서는 빌드, 테스트, merge의 자동화가 필요합니다. 주기적으로 merge된 코드의 변경 사항이 자동으로 build가 되어서 코드 변경 사항 이후에도 build가 성공적으로 되었는지 확인이 되어야하고, 새로 추가된 코드의 변경 사항 뿐만 아니라 기존의 시스템에 다른 버그를 초래하지는 않았는지 자동으로 test까지 되어야 합니다.
메인 리포지토리가 있으면 개발자들은 하루에도 몇 번씩 변경사항을 merge를 하죠. merge가 되었으면 자동으로 팀에서 만든 CI script를 통해서 추가된 코드와 함께 빌드가 잘 되는지 확인한 다음, 팀에서 작성한 유닛 테스트나 통합 테스트가 스크립트를 통해서 실행이 됩니다. 빌드와 테스트가 제대로 되면 리포지토리에서 초록색 사인이 나오고 통과하죠. 만약 변경 사항을 merge했는데 빌드가 실패하거나 테스트가 실패하면 빨간색 사인이 뜨면 이슈를 발생시킨 개발자에게 자동으로 알려줍니다.
이러한 방법을 사용하면 주기적으로 merge를 하기 때문에 merge 충돌을 피할 수 있어서 개발 생산성 향상을 불러오고, merge되는 코드들은 자동으로 빌드되고 테스트되기 때문에 코드의 문제점이나 버그가 빠르게 발견될 수 있다는 장점이 있습니다. 그래서 수정도 빠르게 할 수 있습니다. 코드 자체가 작은 단위로 고립되어있어서 문제를 고치기 쉽기 때문이죠. 결국 이러한 장점들 덕에 최종적으로 코드의 퀄리티가 향상됩니다. 모든 개발자들이 자신이 새로 작성하는 코드에 한해서는 유닛 테스트를 꼭 포함해야하기 때문입니다.
CD
CI로 인해서 주기적으로 merge된 코드의 변경사항들이 자동으로 빌드가 되고 test가 되었다면, 이제 배포하는 단계에서 릴리즈 준비과정을 거쳐 준비된 릴리즈가 정상적인지, 또 문제가 없는지 검증팀이 직접 검증을 한 다음에 이제 배포해도 되겠다고 결정이 되면 수동적으로 배포하게 되는 이 단계를 Continuous Delievery라고 합니다. 또는 릴리즈가 준비가 되자마자 자동으로 사용자에게 배포가 되도록 해놓는 다면 Continuous Deployment라고 합니다.
CI/CD 툴
- Vercel
- Cloudfront
- GitHub Actions
- Netlify
- GitLab CI/CD
- Buildkite
- Bitbucket Pipelines
