CI/CD-목적,주요점,의견

CI/CD는 지속적 통합( Continuous Integration )과 지속적 배포(Continuous Deployment)의 합친 용어입니다. 

소프트웨어 개발에서 코드 변경 사항을 지속적으로 통합하고, 자동으로 테스트하며, 통합된 코드를 지속적으로 배포하는 프로세스를 가리킵니다. 

[목차]

• 목적
• 주요점
• 의견

목적

• 빠른 피드백
  • 코드 변경이 있을 때마다 자동으로 빌드와 테스트를 수행하여 개발자에게 빠른 피드백을 제공합니다. 
• 품질 향상
  • 지속적인 통합과 배포를 통해 소프트웨어의 품질을 지속적으로 향상합니다. 
• 신속한 배포 
  • 변경 사항이 테스트를 통과하면 자동으로 배포되어 신속하게 새로운 기능을 사용자에게 제공할 수 있습니다.

주요점

• 자동화 
  • CI/CD는 주로 자동화된 프로세스를 기반으로 하며, 테스트, 빌드, 배포 등이 자동으로 이뤄집니다. 
• 코드 통합
  • 지속적으로 변경된 코드를 주기적으로 통합하여 충돌을 방지하고, 통합된 코드에 대한 품질을 확보합니다. 

의견

개인적으로는 개발 조직을 셋팅할때 그 무엇보다 먼저 구성해야 하는 것이 바로 CI/CD 환경입니다. 

요즘은 워낙에 도구들이 많고 잘 만들어져서 그다지 어렵지 않습니다. 대표적으로 Jenkins 같은 것이 있습니다. 

왜 가장 먼저 구성해야하면, 

1. 빌드 매니저가 빌드하고 배포하는 시간이 점점 많아집니다. 

2. 소프트웨어의 구성요소가 많아지고 담당자가 많아질수록 통합이 어렵게 됩니다. 

3. 테스트 버전을 배포하는데 번거로움이 많아집니다. 

4. 버전관리가 점점 어려워집니다. 

이렇듯 간단하게 이유를 작성해봤습니다. 

 

처음 개발 조직이 시작이 될때는 한 사람이 빌드 매니저도 하고, 통합도 하면서 개발도 합니다. 

조금 시간이 지나면 BackEnd, IOS, Android, Web 등으로 분업화하고 각각 빌드 매니저가 생깁니다. 

더 시간이 지나면, 각각의 버전 컨트롤이 되지 않기 시작합니다. 즉, 서로 다른 인터페이스 기준으로 만들어지기 시작하는 것입니다. 

그래서, 처음부터 CI/CD를 구축해놓으면 최소한 서로 약속된 시간에 본인들의 코드가 모두 반영된 통합 버전이 만들어질 수 있습니다. 

 물론, 유닛테스트 같은 테스트 코드가 잘 갖춰질 수록 더욱 좋겠지만 최소한 통합이라도 잘 될 수 있습니다. 

 

빌드 매니저는 꼭 존재해야하는 담당자이지만, 사실 아무도 지원하지는 않습니다. 개발자는 소스 코딩이 아닌 업무는 거부감을 많이 가집니다. 그래서, 최대한 불필요한 업무를 줄여주는 게 가장 좋습니다. 

 

이전 빌드매니저 역할을 할때의 기억으로 매주 소스 통합만 하루 밤을 꼬박 보내면서 했던 기억이 있습니다.  통합만 되고 동작이 안 되는 경우도 많았습니다. 통합이 안되었던 대표적인 예로는 각 담당자가 만든 라이브러리의 인터페이스가 맞지 않았기 때문에 최종 바이너리 빌드가 실패하는 경우였습니다. 

매번 담당자별로 다니면서 인터페이스 명세를 다시 확인하고, 수정하고 다시 빌드하는 시간이 얼마나 힘들었는지 생각하기도 싫습니다. 

새벽에는 더욱 참담했던 기억이 납니다.

 

자동화 테스트와 버전 컨트롤도 매우 중요한 비중을 차지합니다. 

모두 중요하지만, 한번에 모두 하기는 어렵고 환경이라도 구성해 놓고 차근히 만들어 가시면 좋겠습니다.