title: "GitOps를 위한 Git 관리 전략"
description: "GitOps에서의 Git repository 관리를 위한 Best Practice"
cleanUrl: /sw-engineer/git-management-in-gitops
floatFirstTOC: right

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

</aside>

**Operations via Pull Request

…** GitOps의 아이디어는 (개발자의 그것과) 동일한 workflow를 인프라 및 애플리케이션 변경에도 적용하는 것입니다. 변경은 해당 Git 저장소로의 Pull Request를 발행하는 것으로 제안됩니다 …

Motivation

• CD용 git으로의 (manifest) code merge에는 어떤 전략을 취해야 하는지 고민 도중 BP를 찾다가…
• 알고보니 CD용 git으로의 merging 조차 Pull Request를 한다는 것을 마주치면서 CD용 git 관리 BP가 필요하다는 것을 보면서..

Git Workflows BP

application code와 configuration code를 분리 (Separate Your Repositories)

• 일반적으로 application code와 configuration code는 독립적인 라이프사이클을 가지며, 함께 있을 경우 CI / CD 프로세스 상호간 불필요한 간섭, 마찰이 발생하기 마련임
• (DevOps가 CI/CD 간 장벽 제거를 추구하지만) 각각을 담당하는 팀 분리는 발생하기 마련이며, 이들 코드가 분리되어 있으면 상대적으로 유리.

environment의 구분을 branch가 아닌 directory로 (Separate Development in Directories, Not Branches)

• 예컨데, staging용 configuration과 production용 configuration을 branch가 아닌 각각의 directory로 구분하라고.
• branch를 쓸 경우 merge가 필요하고 merge는 결코 간단한 일이 아님. 특히 cherry-pick 연산이 개입될 경우 더욱 어려워짐.

TBD (Trunk Based Development)

• 다음의 TBD 특징이 GitOps와 특히 잘 맞음
  • 애플리케이션 변경사항의 신속한 전달에 초점을 맞춤. 이는 지속적인 통합과 지속적인 전달을 가능케 함.
  • cherry-pick할 필요가 별로 없음.
  • Git 저장소에 있는 것이 실제로 환경으로 이동하는 것이라는 확신을 더 많이 갖게 함
• production 과 prod 는 trunk branch로 많이 쓰이는 이름임

정책과 보안 (Policies and Security)

• TBD의 단일 branch 정책은 production 뿐 아니라 조직 전체에 해당하므로 trunk의 안정성 유지는 매우 중요하며 안정성 유지를 위한 장치, 즉 정책과 보안이 필요.