버그 수정이나 새로 만든 기능들이 main repository에 주기적으로 빌드되고 테스트 되어서 merge 되는 것을 말한다.
코드 변경사항을 주기적으로 빈번하게 머지해야 한다.
머지 하는데 시간을 오래 쓸 수도 있기 때문에 최대한 작은 단위로 나누어서 개발하고 통합하는 것이 중요하다.
주기적으로 merge 될 코드의 변경사항이 자동으로 빌드가 되어서 코드 변경사항 이후에도 빌드가 성공적으로 되는지 확인이 되어야 함.
그리고 새로 추가 될 코드의 변경사항 뿐만 아니라 기존의 시스템에 다른 버그를 초래하지는 않았는지 자동으로 테스트까지 되어야 함.
따라서 ‘코드의 퀄리티’가 향상된다.
왜냐하면 이렇게 CI를 잘 운영하기 위해서는 모든 개발들은 자신이 작성한 새로운 코드에 ‘Unit Test’를 꼭 포함해야 하기 때문.
그래서 CI를 사용한다면 프로젝트의 대부분의 소스코드들이 자동으로 테스트가 될 수 있도록 만들기 때문에 조금 더 안정성있는 제품을 개발해 나갈 수 있다.
최종 단계에서 자동화가 되었는지 아닌지에 따라 차이가 있다.
Continuous Delivery: 최종 단계(릴리즈 준비 완료 → 사용자에게 배포)에서 개발자나 검증팀이 검증을 한 뒤 수동적으로 배포하는 단계를 말한다.
Continuous Deployment: 릴리즈 준비가 되자마자 사용자에게 바로 배포할 수 있도록 자동화 해 놓는 것
회사마다 어느정도, 얼마만큼을 자동화 하느냐에 따라 달라지기 때문
회사마다 팀마다 다른 방식으로 적용해서 사용할 수 있다.
컴퓨터 과학에서 데이터 파이프 라인 (일반적으로 파이프 라인이라고 함)은 제공된 데이터 또는 코드에 대해 사전 정의 된 작업을 수행하는 일련의 처리 단계다.
파이프 라인 사용의 목적은 반복적 인 프로세스를 자동화하여 시간을 절약하고 정밀도를 높이는 것이다.
파이프 라인의 이러한 장점은 CI / CD 인프라와의 호환성과 효율성을 높여준다.
특히 CI / CD 파이프 라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계를 수행할 수 있다.
코드 (개발자가 버그,기능 등을 메인 레파지토리에 머지 함)
빌드 (소프트웨어 컴파일),
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사
Jenkins, Buildkite, GitHub Actions
그 외 GitLab CI/CD, Bitbucket Pipelines, circleci
참고자료
https://www.youtube.com/watch?v=0Emq5FypiMM
https://inpa.tistory.com/entry/%F0%9F%91%A9%E2%80%8D%F0%9F%92%BB-CI-CD-%ED%8C%8C%EC%9D%B4%ED%94%84-%EB%9D%BC%EC%9D%B8-%EC%9D%B4%EB%9E%80