--- name: gitops-change description: > Git에 선언된 운영 상태·배포 설정·이미지 버전을 GitOps 경로로 변경할 때 쓴다. 대상 환경의 저장소, 값 우선순위와 배포 경로를 확인해 변경안과 PR을 준비하고 요청 범위의 반영을 확인한다. 장애 원인 조사만 필요하면 incident-triage를 쓴다. --- # GitOps 변경 GitOps가 관리하는 리소스는 저장소와 배포 파이프라인을 통해 변경한다. 대상 시스템에 직접 넣은 변경은 다음 조정(reconcile)에서 되돌아가거나 desired/live 차이를 남길 수 있다. ## 대상과 정책 확인 1. 요청한 변경, 대상 환경과 종료 조건을 확인한다. 조사, 파일 수정, PR 생성과 배포를 구분한다. 2. 실제 컨트롤러와 저장소의 source, revision, 설정 적용 순서와 동기화 정책을 읽는다. 3. 저장소 지침·설정·생성 원본·배포 workflow에서 고칠 파일과 값의 소유자를 찾는다. 4. 변경 전후 값, 영향 범위, 필요한 검증과 되돌리는 방법을 정리한다. Helm이면 values 순서와 template, Kustomize이면 base·overlay, 다른 선언형 시스템이면 해당 합성·생성 규칙을 확인한다. 디렉터리 이름만으로 적용 환경을 추정하지 않는다. 요청 범위를 표현하는 가장 좁은 원본을 수정하고 공통 설정이나 다른 환경에 미치는 영향을 확인한다. ## 이미지와 배포 경로 이미지 버전과 생성된 설정을 누가 갱신하는지 확인한다. 파이프라인·이미지 자동화가 소유하면 그 경로를 사용하고 다음 실행에 덮일 생성 결과만 수정하지 않는다. 특정 브랜치·환경 이름이나 자동화 이벤트를 가정하지 않는다. 자동화의 직접 반영 정책은 수동 커밋·배포 권한이 아니다. ## 변경과 PR 1. 현재 파일 내용을 읽고 필요한 값만 수정한다. 무관한 변경과 사용자 작업을 섞지 않는다. 2. 저장소에서 정한 lint·템플릿 렌더링·검증 절차를 확인하고 사용할 수 있는 도구로 수행한다. 렌더링 결과에서 대상 리소스, 값의 타입과 다른 환경에 미치는 영향을 확인한다. 3. 허가된 경우 작업 브랜치에 커밋하고 PR을 만든다. 커밋·푸시·PR 생성 권한은 각각 요청 범위로 판단한다. 4. 변경 파일, 검증 결과와 PR URL을 전달한다. 실행하지 못한 검사는 이유와 함께 남긴다. 원격 작업에는 현재 저장소 서비스의 연결된 도구와 실제 schema를 사용한다. 도구가 없으면 변경 파일 경로, 패치나 최종 내용과 PR 초안을 제공한다. 없는 도구를 가정하거나 반영하지 않은 변경을 완료로 보고하지 않는다. 추가 권한이 필요한 작업은 최종 변경안과 영향을 보여 준 뒤 요청한다. 이미 허가된 작업을 다시 묻지 않는다. PR 생성 요청만으로 머지·배포·컨트롤러 sync를 실행하지 않는다. ## 본문 연결된 `pr-description`이 있으면 사용한다. 없으면 변경 값과 파일, 이유, 환경·재시작 영향, 검증과 되돌리는 방법을 적는다. 한 PR에 한 목적을 담고 확인한 사실과 예상 영향을 구분한다. “설정 최적화” 대신 “memory limit을 512Mi에서 1Gi로 변경한다”처럼 구체적인 값과 대상을 쓴다. ## 반영 확인 배포 확인까지 요청받았다면 다음 순서로 확인한다. 1. 저장소에 원하는 변경이 반영됐는가. 2. 실제 GitOps 컨트롤러가 해당 revision을 적용했는가. 3. 대상 시스템의 실제 리소스·배포 상태가 예상과 일치하는가. 4. 지표·로그나 해당 기능 확인으로 의도한 효과가 관측되는가. 단계별로 확인된 상태를 보고한다. PR 생성까지만 요청받았으면 이후 반영 확인 항목을 남긴다. 일부 단계의 도구가 없으면 관측하지 못한 범위를 밝힌다. ## 되돌리기와 예외 - 원복도 GitOps 경로로 처리한다. revert가 데이터·스키마·외부 상태까지 복구하는지 별도로 확인한다. - 실제 컨트롤러의 자동 삭제 정책(예: Argo CD의 `prune: true`)에서 리소스 정의를 삭제하면 클러스터 리소스도 삭제될 수 있다. 삭제 대상과 데이터·서비스 영향을 먼저 확인하고 명시적으로 허가된 범위에서만 실행한다. - 긴급 직접 변경은 사용자가 해당 조치를 명시적으로 요청한 경우에만 검토한다. sync 충돌, 영향과 복구 방법을 확인하고 임시 변경 내역과 저장소에 반영할 후속 작업을 남긴다.