왜 GitLab CI/CD인가?
DevOps 속도는 기업의 경쟁 우위입니다. DORA(DevOps Research and Assessment)에 따르면 더 자주 배포하는 회사는 시장에서 더 나은 성과를 냅니다. 모두 자신의 업무를 더 잘 수행하고 더 자주 배포하기를 원하지만, 조직이 성장함에 따라 속도 향상이 계속해서 방해를 받고 있습니다:
- 너무 많은 통합 지점 – DevOps 툴 체인(toolchain)의 다른 모든 도 구에 CI/CD를 연결하는 것은 혼란스럽고 프로세스에 더 많은 단계와 실패 지점을 계속 추가합니다.
- 부서지기 쉬운 도구 – 실제로 새로운 기능을 만드는 것보다 이러한 도구를 유지 관리하고 업데이트하는데 더 많은 시간을 소비합니다.
- 느린 현대화 – 우리는 마이크로서비스와 클라우드 네이티브 개발을 활용하고 싶지만, 불을 끄는데(문제를 해결하는데) 너무 많은 시간을 소비합니다.
이러한 속도 증가로 인해 복잡한 워크플로, 파이프라인 가시성 부족, 프로세스에 대한 혼란이 발생합니다. 유지관리에 더 많은 리소스가 사용됨에 따라 총소유비용 (Total Cost of Ownership, TCO)이 증가하여, 팀은 혁신할 여유가 없습니다. 조직이 확장됨에 따라 이러한 복잡성은 더욱 악화합니다.
피곤해 보이시죠?
현재 CI/CD 도구
GitLab은 투명성을 매우 좋아하여 핵심 가치 중 하나로 만들었습니다. 또한, 웹 사이트에 다른 모든 DevOps 도구를 나열하는 이유이기도 합니다(실제로는 아닙니다). 개방적이고 직접적인 커뮤니케이션은 올바른 결정을 내리는데 필요한 피드백을 받는 가장 빠른 방법이라고 생각합니다. DevOps 팀의 경우 적절한 도구는 일을 더 쉽게 만들어 주어야 하지만 더 많은 것이 항상 더 나은 것은 아니라는 것을 발견했습니다.
높은 유지보수
CI/CD 도구를 나머지 툴 체인과 통합하는 것은 복잡해질 수 있습니다. 이러한 도구를 정기적으로 관리하고 업데이트하는 것은 더 이상 쉽지 않습니다. 많은 팀이 도구 전문가에게 의존하여 모든 것이 원활하게 실행되도록 합니다.
클라우드 네이티브 호환성 부족
더 많은 조직이 마이크로서비스와 클라우드 네이티브 개발을 활용하기 위해, 모던 아키텍처를 지원하는 CI/CD 도구가 필요합니다. 일부 CI/CD 플랫폼의 경우, 팀은 Kubernetes 또는 컨테이너 레지스트리(container registry)에 연결하기 위한 추가 플러그인이 여전히 필요합니다. 레거시 CI/CD 도구를 사용하는 팀은 이러한 클라우드 네이티브 기능을 얻으려면 업그레이드해야 합니다.
툴 체인 복잡성
툴 체인은 때때로 Rube Goldberg 장치와 너무 많은 공통점이 있습니다. 더 많은 애플리케이션, 더 많은 플랫폼, 더 많은 핸드오프(handoffs)를 추가하면 복잡성이 증가하여 팀의 속도가 느려집니다. 여기에 이러한 개별 도구를 관리하기 위한 유지관리, 플러그인 및 업그레이드 요구사항을 추가하면 생산성이 더 어려워집니다.
GitLab CI/CD를 좋아하는 이유
CI/CD 도구는 복잡한 통합 및 플러그인 유지관리로 인해 부담을 주지 않으면서, 파이프라인에 대한 가시성을 높여 엔지니어의 삶을 편하게 만들어야 합니다. GitLab CI/CD는 팀이 바로 사용할 수 있도록 간단하게 설계되었습니다.
사용하기 쉬운
GitLab은 모든 개발자가 이해할 수 있는 YAML 구성을 사용하므로 파이프라인을 더 빠르게 빌드할 수 있습니다.
클라우드 네이티브 CI/CD
내장된 컨테이너 레지스트리와 Kubernetes 통합을 통해, GitLab은 클라우드 네이티브 개발을 지원합니다.
간단한 아키텍처
하나의 권한 세트가 있는 하나의 통합 애플리케이션