Dev. CI/CD
배경
과거 개발자들은 각자의 코드를 개발하고 머지데이라는 날을 정해 개발한 코드들을 병합하는 날이 있었습니다. 이때 사람이 수동으로 병합 작업부터 빌드, 테스트, 배포까지 했습니다. 머지와 배포의 과정에서 사용되는 리소스가 많았고, 만약 에러라도 난다면 디버깅을 하기 위해서 소요가 발생했습니다. 수동으로 하는 과정을 자동화할 수 없을까라는 고민에서 나온 개념이 CI와 CD입니다.
CI/CD
CI/CD를 간단하게 말한다면 어플리케이션의 개발 단계부터 배포까지 모든 단계를 자동화를 통해 조금 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것입니다.
개발부터 배포까지의 과정을 살펴보면 Code를 작성하고 Build와 Test 과정을 거쳐서 다른 사람의 Code와 병합합니다. 그 후 Repository 환경에 Release하고 최종적으로 고객이 사용 가능한 Production 환경으로 배포됩니다.
CI
Continuous Integration(지속적인 통합)의 약자로 개발자가 Code를 작성한다면 CI가 적용된 도구는 Build,Test 후 Merge까지 자동으로 해줍니다. 그 때 오류가 발생한다면 개발자에게 수정을 요구합니다.
CI의 4가지 규칙 by 마틴 파울러
- 모든 소스코드가 살아있고 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화해서 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
- 테스팅을 자동화해서 언제든지 시스템에 대한 건전한 테스트 수트를 시행할 수 있게 할 것
- 누구든 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
필요한 과정
- 코드의 변경 사항을 주기적으로 자주 병합해야합니다. 자주 병합하기 위해서는 해결해야할 문제들을 작은 단위로 나눌 필요가 있습니다.
- 통합을 위한 단계(Build, Test, Merge)의 자동화
장점
- 자동화를 통한 개발 생산성 향상
- 작은 단위로 나눠진 문제들은 문제점을 빠르게 발견할 수 있어 버그 수정에 용이합니다.
- 중간중간 오류를 확인하기 때문에 코드의 퀄리티의 향상
- CI 개념을 사용하면 여러 개발자가 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있습니다.
코드의 병합이 CI를 통해 자동으로 완료되었습니다. 그렇다면 이제 서버에 배포하면 됩니다. 이때 배포해야할 서버의 수가 적다면 직접 수동으로 배포할 수 있습니다. 하지만 서버의 수가 많아진다면 수동으로 하기에는 힘들것입니다. 이 과정까지 자동할 수 없을까라는 고민에 나온 것이 CD입니다.
CD
Continuous Delivery(지속적인 제공)와 Continuous Deployment(지속적인 배포)로 해석됩니다. CI에서는 과정이 끝나고, 남은 과정은 Repository에 Release하는 것과 Production에 배포하는 것입니다. Continuous Delivery는 최종 배포 전 Repository에 Release까지의 자동화를 의미하고, Continuous Deployment는 최종 배포까지 자동화한 것을 의미합니다.
Tools
- Jenkins
- buildkite
- github actions
- gitlab ci/cd
- bitbucket pipelines
- circleci