Continuos Integration / Continuous Delivery , CI / CD란?

 

제목에 나와있다시피

지속적 통합과 지속적 배포를 CI / CD라고 한다.

이것의 목적은 통합도 자동화요. 배포도 자동화다. 그리고 그 자동화를 효율적으로 고도화하는 것이 목적이다.

알아보자

 

---

 

CI부터 알아보자

어떤 식으로 진행되는 것인지부터 보자

 

1. 개발자가 작업 내용을 커밋한다.

2. 커밋을 하면 자동화된 툴이 해당 내용을 적용해서 빌드를 뽑아낸다.

이것이 CI이다.

 

CI를 하는 이유는 디버깅을 빠르게 하는 것이다. 

작업 내용이 적용되었을 때 예상치 못한 오류가 생기는 경우가 많은데

자동화가 이루어진다면 개발자는 CI가 뱉어낸 오류에 대해서 디버깅을 하면 된다.

**만약 작업내용의 크기가 엄청 크다면.. 찾아야 할 버그도 많다는 말이다.

=> 지속적으로 커밋을 통해 버그를 detect 하자

 

개발자가 직접 빌드를 뽑아서 확인할 필요가 없단 말이다.

즉, 시간적으로 효율성을 가져온다. 그렇게 되면 업데이트 주기를 더 앞당길 수 있다.

유명한 CI 툴들은 Jenkins, TeamCity, Bamboo, GitLab등이 있다.(나는 젠킨스만 알았다.)

 그림으로 조금 더 쉽게 보자

 

 

 

지속적 통합을 통해 개발자는 Git과 같은 버전관리 툴로 레포지토리를 관리하며 파이프라인을 통해서 자동으로 빌드하고, 저장하고, 단위 테스트를 실행하게 된다.

**물론 작업내용이 커지지 않게 Main에 커밋/병합이 일어날 경우 CI가 되도록 구성하는 것이 좋다.

 

---

 

다음은 CD다.

 

지속적 배포는 왜 필요한 것일까?

개발환경은 항상 배포환경과는 다르다.

다시 말해서 개발환경과 실제로 서비스가 제공되는 환경은 다르다.

모바일 어플리케이션만 해도 

윈도우, Mac, Linux 에서 빌드되지만 사용되는 곳은 iOS, Android 이다. 

그렇다면 실제로 문제가 발생하는 것을 찾기 위해서는 프로덕션 환경까지 테스트를 해봐야 한다는 것이다.

그래야 시간도 절약하고 디버깅하는 시간도 아낄 수 있다.

 

CD는 다시 말해서 소프트웨어 릴리스 프로세스를 자동화하는 것이다.

릴리스 비용을 절감하고, 소프트웨어 품질 향상, 생산성 향상에 거의 필수적인 요소가 되었다.

결국 이것도 업데이트 주기를 앞당기는 좋은 점을 불러온다.

 

하지만 우리는 CI/CD라고 하듯이 같이 일어난다.

다시 말해서 개발환경을 위해서 CI가 일어나고 프로덕션의 오류를 방지하기 위해 CD가 일어나는데 그것을 하나로 묶어서 프로세스 전체에 문제가 없음을 확인할 수 있다.

 

위의 그림을 보면 

개발자의 코드가 레포지토리에 올라가는 커밋/병합 작업이 일어나는 동시에 빌드, 테스트가 진행되고

CI가 완료되면 코드는 추가 자동화 테스트(Acceptance, 등) 을 거쳐서 Staging 환경에 배포되고 마지막에는

실제로 고객들과 서비스를 제공하는 Deployment까지 자동화 될 수 있다.

결국 소프트웨어 라이프사이클을 극단적으로 줄여서 생산성을 높였다고 말한다.

 

요약하자면 CI/CD는 자동화 툴의 도움을 받아서 하루에도 수 십번씩 소프트웨어를 프로덕션에 릴리스할 수 있게 레포지토리의 통합 코드를 사용하는 것이다.

 

CI/CD 특징을 요약하자면

 

• 자동화되고 빠른 코드 통합
• 짧은 주기와 반복으로 인해 오류 감지 및 응답이 빠르다.
• 자동화 툴이 관리하기 때문에 사람의 실수가 들어갈 확률이 적다.
• 자동화된 스크립팅으로 인해 빠르다.
• 배포는 하루에 여러 번 수행할 수 있다. 

그래서 누가 뭐가 좋냐고 물어보면

5가지로 말하면 된다.