25_Study(지속적 통합 - CI/CD 리뷰)

블로그를 시작한지 얼마 안됐을 때 CI/CD 파이프라인에 대해 포스팅한 적이 있습니다. 현 시대에서 CI/CD파이프라인은 개발과 배포에 있어 중요한 역할을 수행하고 DevOps에 대해 공부를 한다면 좀 더 면밀히 살펴봐야 한다 생각합니다. 오늘은 CI/CD 리뷰와 지속적 통합에 대한 개념, 그리고 테스트 섹션에 대해 공부하고 GitHub Action을 이용한 빌드 및 테스트 자동화 까지 진행해보도록 하겠습니다.

 

먼저 서비스가 사용자에게 도달하기까지 어떤 과정이 이루어지는지에 대해 전통적인 소프트웨어 전달방식과 클라우드 서비스 전달 방식의 비교로 설명하겠습니다.

 

전통적인 소프트웨어 전달방식

 

전통적인 소프트웨어 전달 방식은 서비스 출시에 대한 기한을 미리 정해놓고 그 기한에 맞춰 소프트웨어를 완성하는 방식으로 주로 폭포수 모델 즉 Waterfall 모델로 많이 알려져 있습니다.

이 방식의 문제점은 명확하기 보여지는데 크게 두 가지로 말할 수 있습니다.

 

• 일반적으로 출시 시점이 정해져 있기 때문에 급하게 완성되는 경우가 많았고 막상 배포를 했을 때 소프트웨어의 신뢰성, 안정성을 보장할 수 없습니다.
• 위와 같은 맥락이지만 출시를 약속하고 출시일이 다가와 막상 결과물을 열어봤을 때 산더미처럼 쌓여있는 버그가 문제가 됩니다.

이러한 문제점이 많이 발생되자 사람들은 소프트웨어 안정성을 개선하기 위해 노력을 했습니다 

바로 베타 버전 등을 통해 테스트를 걸쳐 정식 배포하기 전에 버그를 최대한 많이 잡아내려 했습니다.

 

하지만 결국에는 전통적인 소프트웨어 전달방식이 가지는 특징 때문에 점차 사용이 감소되지만 꾸준히 사용되는 분야도 있습니다. 특징은 다음과 같습니다.

 

• 사용자가 항상 소프트웨어을 최신 상태로 업데이트해야 합니다.
• 따라서 버그 수정(patch)을 사용자에게 전달하기 매우 어려움을 겪습니다, 물론 몇몇 소프트웨어는 지속적 전달을 위해 자동 업데이트를 도입했습니다.
• 그리고 아까 언급했던 것처럼 모바일 애플리케이션 분야에서는 여전히 사용하는 전달 방식입니다.

이번에는 클라우드 서비스의 전달 방식에 대해 알아보겠습니다.

클라우드 서비스의 전달방식은 '고객의 요구에 민첩하게 대응하여 지속적 전달을 수행하는 애자일(Agile)모델'을 기반으로 합니다.

 

주로 SaaS(Software as a Service)로 알려져 있으며 말 그대로 서비스로서의 소프트웨어로 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있고 매일매일 진화하는 소프트웨어입니다.

 

 이 방식의 장점은 다음과 같습니다

 

• 사용자 업데이트에 대한 걱정에서 벗어남
• 하루에 여러 번의 릴리즈도 가능 ㅡ> 빠른 문제 해결 가능
• 다양한 배포 방식을 적용하거나 A/B 테스트가 가능
• 빠른 배포를 보장

이러한 장점을 달성하기 위해 전달 워크플로가 수립되어야 하며, 자동화가 필수적입니다.

코드를 빌드하고 테스트 릴리즈 그리고 배포까지의 CI/CD 파이프 라인을 구성하는 것 역시 DevOps의 영역입니다.

즉 DevOps는 서비스 전달/배포 Workflow를 구성할 수 있어야 합니다.