Lob!

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글이며 기존에 작성했었던 CI / CD 글을 수정한 것입니다.

자동화되지 않은 개발 프로세스의 문제점

상용 서비스, 소프트웨어는 일반적으로 여러 명의 개발자가 협업을 진행하기 때문에 코드의 관리와 배포 후 발생하는 장애 대처 용도로 Git과 같은 버전 관리 도구를 사용하여 각 코드에 대한 이력과 메시지를 남기고 병합하는 과정을 거치게 됩니다.

이러한 프로세스를 계속 수행되다 보면 기존 코드(테스트, 스키마 설정 값, 충돌)와 문제가 발생할 수 있지만 이를 빨리 식별하지 못해 운영 환경에서 서비스 장애가 발생하는 경우가 있을 수 있습니다.

또한 개발, 운영팀이 수동으로 코드를 빌드하고 테스트 및 FTP 등의 프로토콜을 통한 패키지 전달 및 실행이라는 하나의 배포 흐름을 수작업으로 수행하게 되어 주기적으로 팀의 리소스가 낭비되게 됩니다. (인력, 시간, 돈 등)

• 이는 서비스의 크기가 커짐에 따라서, 하나의 서비스가 여러 개의 마이크로 서비스로 분리된 상황이나 사용자 트래픽의 급증으로 인해 빨리 서버를 증설해야 할 때 더욱 큰 문제를 야기할 수 있습니다.

CI / CD 란?

Application 개발 배포 프로세스를 자동화하여 다음 버전을 짧은 주기로 배포하여 사용자에게 제공하는 방법 또는 시스템을 의미합니다. 이를 통해 사용자의 피드백을 받는 주기도 짧아짐으로써 더 나은 서비스를 제공하는데 도움이 됩니다.

• Application Life Cycle 전체에 걸쳐 지속적인 자동화와 모니터링을 제공한다.
• CI/ CD를 도입함으로써 개발자들은 비즈니스 요구 사항, 코드 작성에만 집중할 수 있다.
• CI/ CD 파이프 라인에서 실행되는 회귀, 성능, 유닛, 통합 테스트 등 지속적인 테스트 커버리지와 검증을 요구함으로써 좀 더 안전한 서비스를 제공할 수 있는 여지가 있다.

CI : Continuous Integration

자동화된 프로세스를 통해 애플리케이션 코드 변경 사항이 정기적으로 빌드 및 테스트(유닛, 통합)되어 공유되는 Repository에 병합되는 것을 의미합니다.

• 개발자 간의 코드 충돌을 방지하기 위한 목적을 가지며, 기존 코드와 신규 코드의 충돌이 발생하면 빠르게 발견하고 수정할 수 있는 식별성을 지닙니다.
• 통합 프로세스의 자동화와 일관성을 제공하여 사용되는 리소스를 줄이고 요구 사항에 따른 코드 변경을 더 자주 수행하게 끔 촉진합니다.

CI의 필수 구성 요소

• Repository management
  • CI를 도입하기 위해서는 Version control 도구와 Git-flow와 같은 Branch 전략은 필수적인 요소입니다. Local, Remote, Origin Repository를 각각 관리하여 conflict가 발생할 여지를 줄이고 branch check-out기능과 Commit을 통해 사용 가능한 코드의 식별 및 버전, 이력 관리를 수행해야 합니다.
• Build-automation
  • 개발, 운영 팀은 Build script (Shell, python) 또는 표준화된 Build tool이나 Open-source (jenkins, gitlab, circle ci 등)를 사용하여 Code Build를 수행해야 하며, 이전 Build version에 대한 백업 버전을 관리하여 예기치 못한 상황에서 복구할 수 있는 여지를 남겨 놓아야 하고 이 모든 것은 자동적으로 수행되어야 합니다.
• Self-test (Test-automation)
  • 빠른 수정과 장애 상황 방지를 위해서는 기존에 작성된 Unit Test나 Sonarqube와 같은 Third-part library 들을 연동하여 자동화된 테스트 수행 및 커버리지 관리가 되어야 합니다.
• Source code versioning
  • 정기적인 Source commit을 통해 개발자 간의 이슈 최소화와 작업 상황에 대한 공유가 지속적으로 이루어져야 하고 Commit을 통한 Build를 수행하여 지속적인 Test Cycle을 수행하여야 합니다.

CD : Continuous Delivery / Deployment

해당 용어는 지속적인 서비스 제공 혹은 지속적인 배포를 의미하며, 이 두 가지 용어는 상호 교환적으로 사용됩니다. 최종적으로는 소프트웨어나 서비스를 좀 짧은 주기로 배포, 반영하는 것을 목표로 합니다.

이를 통해 지속적으로 발생하는 피드백, 신규 요구 사항에 대해 유기적으로 대처할 수 있습니다.

Continuous Delivery

지속적인 제공은 개발자들이 적용한 변경 사항이 자동화된 프로세스(Pipeline)를 통해 빌드, 테스트를 거쳐 Repository에 자동으로 업로드되는 것을 뜻하며 운영팀은 이 Repository의 최신 상태를 운영 환경에 실시간으로 빠르게 적용할 수 있습니다.

• 최소한의 리소스로 새로운 코드를 빠르게 수정하고 온전히 통합하는 것을 목표로 합니다.
  • 각 변경 사항은 작은 단위로 최소화하여 문제가 발생하였을 때 확인해야 하는 영역을 줄입니다.
  • Build, Test, Integration 프로세스를 계속 확인할 수 있으며 문제가 발생한 부분을 빠르게 식별합니다.

Continuous Deployment

지속적인 배포는 변경 사항이 생긴 Repository에서 고객이 사용하는 환경이나 테스트를 위한 스테이지 서버로 자동으로 배포, 출시하는 것을 뜻하며 이는 지속적인 수작업으로 인해 개발 팀이나 운영 팀의 리소스 소모 또는 프로세스 병목이 발생하는 것을 방지합니다.

• 최소한의 리소스로 변경된 사항을 빠르게 각각의 환경(Dev, Test, Stage, Production)으로 출시하고 검증하는 것을 목표로 합니다.
• 통합 테스트, QA, 배포 단계를 자동화하여 사용되던 리소스를 최소화하기에 소프트웨어나 서비스에 집중할 수 있는 리소스가 남게 됩니다. 이는 결국 실제 Code와 Test를 작성하는 것에 집중할 수 있고 Legacy code를 Refactoring, Restructuring 할 수 있는 시간을 만듭니다.

CI / CD Tools

CI / CD를 구성하기 위해 사용하는 도구들을 나열합니다.

• Source code management tools
  • Git, AWS Code Commit, SVN, Kraken, Source tree
• Build management tools
  • Maven, Gradle, PyBuilder, make, ANT
• Test automation, quality tools
  • Selenium, Junit, Cucumber, Sonarqube, Jacoco
• CI tools
  • Jenkins, Jenkins X, Gitlab, Circle CI, AWS Code Build, Bamboo, Hudson..
• CD tools
  • Argo CD, AWS Code Deploy..
• Configuration, Provisioning tools
  • Ansible, Puppet, Chef..
• Monitoring tools
  • AWS Cloud Watch, Nagios, Ganglia, Sensu..

도구마다 사용법이나 정의하는 문법 등이 다르기에 도구의 어떠한 점이 중요한 것인가 (Build 서버 구축 여부, Plugin 제공 여부나 생태계의 크기 등)를 고민해보고 있습니다만 우선은 회사에서 사용하는 것이라도 열심히 해야겠습니다. ㅎㅎ 

• 현재 회사에서는 Gitlab-CI의 Docker base Runner 타입으로 사용하고 있으나 따로 CD가 구성되어 있지는 않습니다. 상황에 알맞은 CD 방법을 고려해보고 도입하는 게 중요한 상황인 것 같습니다.

참고 자료

• https://www.plutora.com/blog/understanding-ci-cd-pipeline
• https://www.redhat.com/en/topics/devops/what-is-ci-cd
• http://www.yes24.com/Product/Goods/90624537