CI는 Continuous Integration의 약자로, 지속적 통합이라는 의미.
여러 사람들이 하나의 프로젝트에 대해 개발을 수행하며, 여러 코드들이 각자의 로컬에 존재하게 된다. 지속적 통합은 이렇게 각자 개발한 코드들을 하나로 합치는 과정을 지속 가능한 형태로 수행하는 것을 의미한다.
즉, 작업한 코드를 주기적으로 Build -> Test -> Merge 하는 과정이다.
ex) 두 명의 개발자가 하나의 파일을 작업한 후, 오랜 기간이 지나서야 Merge를 하게 된다면?


ex) 팀 내 개발자들이 개발 후에 하루에 수십번 Main Branch에 Merge 한다면?

CD는 Continuous Delivery 및 Continuous Deployment의 약자로, 지속적 제공/지속적 배포 두 가지 의미를 가진다.
두 가지 모두 마지막 배포 단계에서 어떻게 자동화해서 배포할까? 를 고민하는 단계이다.
가장 큰 차이점은 수동 배포, 자동 배포 라고 생각하면 된다.
상황을 고려하여 둘 중 하나를 선택하여 사용한다.
CI 단계에서 Build되고, Test된 후, 배포 준비 상태가 확인되면 개발자 혹은 검증팀이 수동으로 배포하는 것.

CI 단계에서 Build되고, Test된 후, 배포 준비 상태가 확인되면 자동으로 배포까지 진행하는 것.

- CI/CD 파이프라인
Deploy 과정을 수동으로 수행하면, 지속적 제공.
Deploy 과정까지 자동으로 수행하면, 지속적 배포.
CI와 CD를 거쳐서 배포가 이루어지므로, CI/CD라고 불린다.

프로젝트 규모에 따라 필요한 리소스와 관리 방식이 달라진다.
소규모: 간단한 CI/CD 툴을 사용해 빠르게 설정 가능. 예를들어, GitHub Actions이나 Travis CI와 같은 간단한 도구를 사용해도 충분히 효과적이다.
중규모: 좀 더 확장 가능한 툴이 필요하다. Jenkins나 GitLab CI/CD와 가은 도구를 사용하여 자동화와 통합을 강화할 수 있다.
대규모: 복잡한 파이프라인이 필요할 수 있다. AWS CodePipeline이나 Azure DevOps와 같은 클라우드 기반 솔루션을 통해 대규모 배포와 관리가 가능하다.
프로그래밍 언어와 프레임워크: 팀이 사용하는 언어와 프레임워크에 맞는 도구를 선택해야한다. 예를 들어, Java 기반 프로젝트라면 Jenkins가 유리할 수 있고, NodeJS 기반 프로젝트라면 Github Actions가 적합할 수 있다.
도구와 서비스: 팀이 이미 사용중인 도구와 통합 가능한 CI/CD툴을 사용한다. 형상관리 프로그램으로 Git을 사용하고 있다면 GitLab CI/CD를, 클라우드 서비스를 사용하고 있다면 AWS CodePipeline 또는 Azure DevOps, GCP DevOps를 고려할 수 있다.
다음 글에서는 Jenkins에 대해 공부해 볼 것이다.
https://sehun5515.tistory.com/159
https://ccomccomhan.tistory.com/297
https://www.elancer.co.kr/blog/detail/759