코드 작성을 마치면 테스트를 진행한다. 테스트가 성공적으로 수행되면 이를 로컬에서 빌드하거나 클라우드 서버를 통해 빌드를 하게 된다. 빌드를 통해 아키텍트가 생성되면 이를 배포하는 과정을 거치게 된다.
한 번 배포하면 끝인가? → 아니다. 사용중에 버그가 발생할 수 있고, 테스트 과정에서 발견하지못한 버그가 있을 수 있다. 이러한 버그를 고치기 위해 앞에 있었던 과정을 사이클을 그리며 계속 반복하게 된다. 이는 짧은 주기로 반복되는데, 이를 개발자가 계속 수정 반복하는 것은 굉장히 시간이 소요되는 작업일 수 밖에 없다. 그래서 여기서 CI / CD가 등장한다.
지속적인 통합
프로젝트가 앞서 말한 사이클을 돌 때, 짧은 주기로 자동화하고 개선하는 것을 말한다. ( 배포를 제외한.. ) 코드, 빌드, 테스트, 배포, 디버그까지의 행위들을 하나로 묶어서 사이클을 만든다고 생각하면 쉬워진다.
지속적인 제공 / 배포
뭔가 싶을 것이다. 왜 CD는 두 개로 나뉘는 걸까 ?? 하는 행위 자체는 비슷하나 목적이 다르다. 배포를 할 때는 크게 두 가지로 나눌 수 있다. 개발 환경의 배포와 운영 환경의 배포이다. 개발 환경의 경우 개발하면서 API도 테스트하고 로컬이 아닌 서버에서 어떤 식으로 작동하는 지 확인하기 위함이다. 운영 환경은 실제 사용자들이 사용하게 되는 서비스가 구동되는 환경을 의미한다.
Delivery는 그 중 코드 → 빌드 → 테스트 → 개발 환경 배포까지의 자동화를 의미한다. 개발 환경까지는 개발자가 손을 댈 것이 없지만 그 이후 운영 환경을 배포하기 위해서는 직접 배포해야한다.
Deployment는 개발 환경까지에서 멈추는 것이 아니라 운영환경까지의 배포 자동화를 의미한다.