title: "GitOps에서의 CI/CD piplining 전략"
description: "GitOps 기반 CI/CD pipelining을 이루는 다양한 전략과 최선에 대해 논한다"
cleanUrl: /sw-engineer/cicd-pipelining-stratedy-in-gitops
ogImage: "<https://oopy.lazyrockets.com/api/v2/notion/image?src=https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F6df04ffd-6c08-4388-95d7-d8279444c782%2FUntitled.png&blockId=e5b6c149-0faa-48be-9187-dfa4ade8575d>"
floatFirstTOC: right

<aside> 💡 참고 : 하기 내용은 The Path to GitOps의 6장에서 추출되었습니다.

</aside>

Motivation

• CI/CD pipeline을 설계하면서 BP가 무엇인지 궁금증이 유발…

CI and CD Can Be Decoupled

… Jenkins와 같은 성공적인 단일 DevOps 시스템은 CI와 CD 모두를 목표로 하기에 사람들은 CI와 CD를 한데 묶어 생각하는 경향이 있다. 하지만 Kubernetes, microservice, 그리고 클라우드 네이티브 아키텍처가 출현하면서, CI/CD를 포함한 많은 패러다임이 분리되기 시작했다 …

Key Idea

• CI와 CD의 decoupling : legacy의 경우 CI / CD 연동에 단일 process(e.g. Jenkins Pipeline)이기에 coupling 발생
• 비동기 활용 : GitOps Controller(e.g. Argo CD)에 의한 비동기식 연동 활용

GitOps의 CI/CD pipeline Models

책에서는 GitOps 기반 pipeline 구현을 위한 3가지 모델을 제시. 첫 번째 것은 사실 상 GitOps라고 보기 어렵고(legacy DevOps) 두 번째는 혼합 단계로서, 사실 상 마지막 모델을 GitOps pipeline으로 추천.

CI가 관리하는 모델 (CI managed model)

• DevOps의 대부분에서 특히 Jenkins를 통해 채용한 방식. 전체 프로세스를 Jenkins pipeline이 관리
• GitOps에 반하는 모델이며 일반적으로 부유하는(floating) 태그(e.g. dev, stage, prod)를 사용하며 이 태그를 붙이는 것은 CI의 일임.
• 환경간의 게이트가 없을 경우(dev → test로의 전환)에 적합하여 완전 자동화가 가능

장점

• 전통적 CI/CD 모델로서 많은 사람들에게 익숙함
• 기존 프로세스와 도구를 바꿀 필요가 없음. 따라서 GitOps 초기 검토 시 유리하며 기존 프로세스를 (상당부분) 재사용이 가능.