“CI/CD가 뭐지?”
“CI/CD가 왜 필요한거지?”

CI/CD에 대해 이해를 돕기 위한 예시를 보겠습니다.
한명의 개발자가 프로그램을 만드는 상황과
팀 단위의 프로그램을 개발하는 2가지 상황입니다.
개인 개발을 할 때는 로컬 PC에서 작업을 하고, 깃허브와 같은 코드 저장소에 PR을 하며 프로그램을 작성 후, 완성되면 배포하면 끝 입니다.
여기서는 별다른 문제를 발견할 수 없습니다.
하지만 팀 단위의 개발을 한다면 달라집니다.
깃허브와 같은 코드 저장소는 여러명이 함께 공유하기 때문에, 누군가가 코드 저장소에 PR을 했다면 다른사람들도 똑같이 코드의 변경점을 자기의 로컬 환경으로 가져와서 이어서 개발을 진행해야 합니다.
만약 그렇지 않을경우, 사람마다 코드의 버전이 달라지기 때문에 충돌을 유발할 수 있습니다.
CI/CD는 이러한 상황을 해결하기 위해 필요하게 되었습니다.

CI는 Continuous Integration의 줄임말로 한국어로는 ‘지속적인 통합’ 이라고 합니다.
동일한 프로젝트에서 작업하는 모든 사람이 주기적으로 코드의 변경 사항을 중앙 저장소에 병합하도록 하는 방식 입니다.
CI의 프로세스를 설명하자면, 팀 단위의 개발 상황일 때 각각의 팀원이 코드를 저장소에 merge하게 될 때
이 저장소의 상태를 CI Server가 감지해서 그 결과를 빌드-테스트하게 됩니다.
결국 CI는 개발자를 위해 빌드와 테스트를 자동화하는 과정이라고 볼 수 있습니다.
이를 주기적으로 실행하기 때문에 여러 명이 동시에 작업을 해도 충돌을 방지하고 모니터링할 수 있습니다

CD는 2가지 의미로 볼 수 있습니다.
우선 Continuous Delivery는 지속적인 제공이라는 뜻으로,
CI작업을 통해 코드의 빌드와 테스트를 성공적으로 진행했을 때
코드 저장소에 자동으로 업로드하는 과정을 말합니다.
Continuous Delpolyment는 지속적인 배포 라는 뜻으로,
지속적 제공을 통해 성공적으로 병합한 코드 내역을 배포환경으로 보내는 것입니다.


CI/CD 툴은 여러가지가 있지만, 저는 그 중에서 GitHub Actions를 썼습니다.
GitHub Actions는 위의 특징들을 가지고 있고, 이 툴을 사용해 배포까지 했을 때 적당히 해볼만했던 것 같습니다.

깃허브 액션의 플로우를 간단히 설명하자면,
개발을 끝낸 사람이 코드를 Github에 PR하게 되면, 깃허브는 runner라는 가상의 컴퓨터 하나를 빌려주며 여기에서 코드를 빌드 & 테스트하게 됩니다.
깃허브 액션에서 빌드와 테스트가 성공하게 되면, 서버에 배포해주는것을 자동화해줍니다.