같은 코드를 여러 팀이 관리할 때 테스트 환경은 어떻게 제공해야할까?(feat Argo CD Pull Request generator)

같은 코드를 여러 팀이 나눠 관리하면, 배포 전 코드를 검증할 테스트 환경을 어떻게 나눠 줄지가 문제가 됩니다. 이 글은 테스트 환경을 제공하는 세 가지 방법을 비교하고, 그중 PR 단위로 임시 환경을 만드는 방법을 ArgoCD Pull Request generator로 구현하는 원리와 실습을 다룹니다.

 

여러 팀이 하나의 코드를 관리하는 상황

같은 코드를 여러 팀이 관리하는 경우는 종종 있습니다. 거대한 소프트웨어에서 기능마다 담당 팀이 나뉘어 있는 경우, 또는 버전을 올리는 동안 v1을 유지보수하는 팀과 v2를 개발하는 팀이 같은 코드베이스를 함께 보는 경우가 그렇습니다.

 

그럼 이 여러 팀에게 테스트 환경을 어떻게 나눠줘야 할까요?

 

(경험담) 테스트 환경을 나누는 세 가지 방법

팀마다 별도 환경 제공

가장 단순하고 이상적인 방법은 팀마다 독립된 테스트 환경(또는 물리 서버)을 주는 방식입니다. A팀에게는 A 환경을, B팀에게는 B 환경을 그대로 줍니다.

문제는 비용입니다. 팀이나 기능이 늘어날 때마다 서버와 네트워크를 함께 늘려야 해서, 비용이 팀 수에 비례해 커집니다. 네트워크도 물리적으로 분리해야 하므로 관리 포인트도 같이 늘어납니다.

 

하나의 환경에서 배포를 순서대로 조율

환경은 하나만 두고, 그 환경에 어떤 팀의 코드를 배포할지 시간을 나눠 조율하는 방법도 있습니다. CPU의 time slice와 같은 방식으로, 환경을 쓸 시간만 정하면 됩니다.

다만 기능 배포가 잦아지면 팀들이 환경을 쓰기 위해 대기하는 시간이 늘어나고, 그만큼 기능 출시도 늦어집니다. 배포 순서를 둘러싼 팀 간 조율 비용도 함께 커집니다.

 

PR 이벤트가 발생할 때만 임시 환경 생성

아니면 git branch를 merge하기 위한 이벤트, 예를 들어 GitHub PR이 열릴 때마다 그 코드를 위한 테스트 환경을 임시로 만드는 방법도 있습니다. PR이 생성되면 임시 환경이 만들어지고, PR이 close되면 그 환경은 사라집니다.

임시 환경을 만들 때는 workload와 네트워크를 PR 단위로 나눠야 합니다. 쿠버네티스라면 PR마다 Pod을 분리하고, 그 Pod을 호출할 엔드포인트도 따로 둡니다. 인프런 사례는 HTTP 헤더로 요청을 구분해 임시로 만든 Pod에만 트래픽이 가도록 분기했고, 네트워크 분기는 linkerd 서비스 메시로 처리했습니다.

• 인프런 사례: https://tech.inflab.com/20251121-pr-preview/

 

ArgoCD Pull Request generator로 PR마다 Application 만들기

원리: ApplicationSet의 generator

ArgoCD Pull request generator는 ApplicationSet의 generator 중 하나입니다.

 

Pull request generator의 핵심은 PR의 open/close 이벤트에 맞춰 Application의 생성과 삭제까지 이 generator가 자동으로 처리한다는 점입니다. PR이 열리면 그 PR을 위한 ArgoCD Application이 생기고, PR이 close되면 해당 Application이 사라집니다.

 

pullRequest를 설정하는 방법은 ApplicationSet에서 pullRequest 필드를 사용하면 됩니다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
  namespace: argocd
spec:
  generators:
  - pullRequest:
...

 

원하는 PR대상 지정

pullRequest generator만 켜두면 열려 있는 모든 PR이 감시 대상이 됩니다. 팀에서 여는 모든 PR마다 테스트 환경이 생기는 셈이라, 원치 않는 리소스가 계속 쌓일 수 있습니다. 이를 막으려면 GitHub label로 대상을 제한하면 됩니다. 아래 설정은 argocd-preview label이 붙은 PR만 골라서 감시합니다.

 

ApplicationSet 설정은 pullRequest.github.labels 필드입니다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
  namespace: argocd
spec:
  generators:
  - pullRequest:
      github:
        labels:
        - "<PULL_REQUEST_LABEL>"
      ...

 

동작 확인

ApplicationSet을 생성하면 아래처럼 ApplicationSet 리소스가 보입니다.

 

argocd-preview label이 붙은 PR이 열리면, ApplicationSet이 PR 번호를 이름에 포함한 ArgoCD Application을 생성합니다.

 

PR이 close되면 생성됐던 Application이 함께 삭제됩니다.

 

실습

실습 코드는 github에 공개돼 있습니다.

• github: https://github.com/choisungwook/portfolio/tree/master/kubernetes/argocd/pull_request_generator
• 실습 환경: kind cluster
• 네트워크 분리: istio ambient mode로 HTTP 헤더 분리

 

적용한다면 고민할 점

Argo CD Pull Request Generator를 실제 적용한다면 몇 가지를 고민할 수 있습니다.

1. PR이 증가할 수록 그만큼 물리적인 노드수가 필요합니다. 또는 노드를 자동으로 증가시키는 노드 auto scaler를 고민해야합니다.
2. ArgoCD 장애로 삭제 동기화가 밀리면, 닫힌 PR의 환경이 그대로 남아 있을 수 있습니다.

 

참고자료

• PR 환경마다 미리보기 제공하기 - 인프랩 기술 블로그