CI/CD

 CI/CD는 개발 환경프로세스 이다.

간단하게 말하면,어플리케이션 개발 단계부터 배포때까지 모든 단계들을 자동화를 통해서 조금더

효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것을 말한다.

 

CI => Continuous Integratio

지속적인 통합

버그 수정이나 새로 만드는 기능들이 메인 Repository에 주기적으로 build되고 test가 되어서, merge되는 것을 말한다.

이 방식은 1991년 Grady booch에 의해서 처음으로 사용되어지다가 나중에는 extreme programming 개발 방법론에서 채택되어 졌다.

 

point

 

1. 코드 변경사항을 주기적으로 비번하게 머지해야 한다.

 

+어떻게 작은 단위로 나눠서 메인 Repository에 반영할지, 또는 작은 단위로 나눠서 사용자에게 배포 할 수 있을지 하는 고민이 필요하다. ->작은 단위로 나눠서 개발하고 통합해 나가는 것이 중요.

 

2. 통합을 위한 단계(빌드,테스트,머지)의 자동화

 

+주기적으로 merge된 코드의 변경사항이 자동으로 build되기 때문에,  변경 후 에도 build가 성공적으로 되었는지 확인해야 한다. 또 변경 자체의 버그 뿐만 아니라 기존의 시스템에 영향을 끼쳐 버그를 초래하지 않았는지 여부도 자동으로 test되어야 한다.

 

+CI Server에 merge가 되었으면, 자동으로 팀에서 만든 CI Script를 통해서 추가된 코드와 함께 Repository가 build가 된다. build가 잘 되었다면, 팀에서 작성한 unit테스트, integration 테스트 등등 여러가지 test들도 Script를 통해서 실행이 된다. test도 통과가 되어서 초록 사인이 나오면,나중에 배포될 때 반영이 될 수 있다. 반면, build는 잘 됐지만 test에서 실패해서 빨간 사인이 뜨면, 문제를 일으킨 개발자에게 자동으로 알려준다.

 

장점

• 개발 생산성 향상
• 문제점을 빠르게 발견
• 버그 수정 용이

+주기 적으로 merge를 해서 코드의 변경 사항이 작다. 그래서, 문제를 해결 할 때도 조금더 고립된 작은 단위로 문제를 좁힐 수 있기 때문이다.

 

• 코드의 퀄리티 향상

+CI를 잘 운영하기 위해서 모든 개발자들이 자신이 작성하는 코드에 한해서는 unit 테스트를 꼭 거쳐가야 하기 때문이다.

 

CD => Continuous Delivery(Deployment)

지속적인 제공의 약자(배포)

-마지막 배포 단계에서 최대한 자동화를 시킬수 있는지에 대한 고민이다.

 

CI를 통해서 주기적으로 merge되 변경 사항들이 자동으로 build와test 되었다면, 이제 배포 단계에서 release할 준비 과정(Prepare Release)을  거친다. 여기서 준비된 release가 괜찮은지, 정상적인지, 아무런 문제가 없는지, 개발자나 검증팀이 검증을 한다. 최종적으로 사용자에게 배포를 해도 되겠다고 결정이되면, 수동적으로 배포하는 이 단계를

Continuous Delivery라고 한다. 또는, release가 준비가 되자마자 자동으로 사용자에게 배포되게 만들 수 도 있는데, 이 것을 Continuos Deployment라고 한다. Delivery와 비슷하지만 최종단계가 자동화가 여부에 따라 부르는 용어에 차이가 존재한다.

 

CI/CD Tools

 

[출처-https://youtu.be/0Emq5FypiMM]