CI/CD란???

개발자 혹은 it업계 종사자들은 종종 CI/CD 파이프라인이라는 말을 사용한다. "CI/CD구축해야해요.", "사용했어요." 등등. 근데 CI/CD가 정확하게 뭘까?

 

프로그렘(어플리케이션)을 개발할때 각각의 모든 단계를 '자동화'하여 좀 더 빠르고 효율적으로 구축해

소비자(사용자)에게 지속적으로 배포 할 수 있는 프로세스를 의미한다.

쉽게 말해서 하나의 개발 프로세스이다.

 

젠킨스, 깃허브, 깃렙, 등의 툴을 사용할 수 있는데 CI/CD를 조금 풀어서 알아보도록 하자.

 

 

Continuous Integration(지속적인 통합)

1991년 Grady라는 분을 통해 처음으로 나타나게 되었는데 단어의 말 뜻 그대로 지속적인 통합을 의미한다. 개발자들은 최대한 자신이 만들 코드를 작은 단위로 나누어서 Repository에 반영하거나 사용자에게 배포할 수 있을지 고민해야한다.  또한 이런 코드를 만들때 변경사항 등을 개발자 개인이 스스로 알고 이해하는것으로 끝나는것이 아닌 merge(병합)하기 위한 설명 등을 할 필요가 있다. 이것으로 어떻게 다른 개발자들과 협업하여 통합, 적용할지 고민해야한다.

또한 이런 과정을 거친 이후 변경된 코드가 자동으로 빌드되고 변경사항이 잘 이루어졌는지 확인해야한다. 또한 사용자의 의도대로 작동하는지 개발자의 생각대로 코드가 구동되는지, 변경된 코드로 인해 다른 라인에 버그가 발생하지 않는지 등을 파악할 필요도 있다.

 

일반적으로는 개발자가 변경한 코드를 바로바로 배포하는것이 아닌 CI server에 변경된 코드를 올리면 여기서 빌드와 테스트 작업을 거친 후 애러 유무를 파악하여 개발자에게 알린다. 이러한 주기적인 머지로 인해 다른 개발자들과 협력을 할때 서로 비슷한 코드를 설정하는 충돌을 막을 수 있으며 이로 인해 개발생산성을 높일 수 있다. 또한 문제점을 빠르게 즉각적으로 발견할 수 있어서 코드의 결함, 문제점 등을 확인하기 쉽다. 이로 인해 버그를 수정하기 아주 쉬워진다.
이런 현상으로 인해 코드 자체의 퀄리티가 상승된다.


Continuous Delivery(Deployment)(지속적인 제공(배포))

CI단계에서 아무런 문제없이 배포할 수 있게 된다면 배포를 해야하는데 이 단계에서 어떻게 자동화를 할 수 있을지 고민하는 단계이다.

조금 구체적으로 시나리오를 이야기 하자면 CI를 통해 자동으로 빌드, 테스트 이후 배포를 해야하는데 이때 준비과정을 거치고 개발자나 검증팀이 검증을 한 이후 배포 결정을 내리고 수동적으로 배포하는 단계를 Continuous Delivery 라고 한다. 마지막 단계에서 배포 결정마저 자동화 하게 된다면 ContinuousDeployment라고 한다.

즉 최종단계에서 배포를 위한 검증을 자동화로 할 것이냐 수동으로 할 것이냐에 따라 CD에서의 D 가 바뀌게 된다.