update roadmaps and add m-cicd-operations task

This commit is contained in:
toki 2026-05-30 20:47:06 +09:00
parent 01a4ae9032
commit 03c72e6715
9 changed files with 456 additions and 86 deletions

View file

@ -105,6 +105,19 @@ docker compose up
4. workspace 수준 검증이 필요하면 `bin/test`, `bin/lint`, `bin/build`를 사용한다. 4. workspace 수준 검증이 필요하면 `bin/test`, `bin/lint`, `bin/build`를 사용한다.
5. 서버 런타임 검증이 필요하면 `services/core/compose/`를 사용한다. 5. 서버 런타임 검증이 필요하면 `services/core/compose/`를 사용한다.
## 운영 업데이트/배포 흐름
upstream baseline이나 runtime image가 바뀌면 하나의 변경 기록에서 다음 항목을 함께 남긴다.
1. server, webapp, push-proxy baseline ref와 nexo Flutter SDK compatibility 범위.
2. 배포 후보 image tag 또는 digest, compose input hash, 적용 lane.
3. secret profile label과 주입 방식. 실제 값, credential, host, port는 tracked 문서와 task/review log에 쓰지 않는다.
4. smoke 결과와 실패 분류. 실패는 server, webapp, push-proxy, SDK contract, infra 중 하나로 후속 이슈화한다.
5. rollback ref와 rollback evidence 위치. 공개 기록에는 private run log 참조와 판정만 남긴다.
compose lane, secret 주입, rollback 기준은 `services/core/compose/README.md`
Deployment Loop를 따른다.
## 환경 변수 ## 환경 변수
### Core Compose ### Core Compose

View file

@ -0,0 +1,83 @@
# Milestone: CI/CD와 운영 업데이트 루프
## 위치
- Roadmap: `agent-roadmap/ROADMAP.md`
- Phase: `agent-roadmap/phase/upstream-runtime/PHASE.md`
## 목표
Mattermost server/webapp/push-proxy update와 nexo Flutter SDK 검증을 반복 가능한 CI/CD와 운영 runbook으로 연결한다.
upstream 업데이트에 따른 이슈를 빠르게 분류하고, 수정/보류/rollback 결정을 남길 수 있는 흐름을 만든다.
## 상태
[완료]
## 승격 조건
- 없음
## 구현 잠금
- 상태: 해제
- 결정 필요:
- 없음
- 결정 완료:
- [x] 2026-05-27: upstream update를 쉽게 따라가기 위한 CI/CD와 이슈 대응 루프를 프로젝트 방향성에 포함한다.
- [x] 2026-05-30: CI 검증 기준은 workspace helper, optional gate, compose smoke, SDK optional check로 정리했고, 남은 결정은 마일스톤 전체 잠금이 아니라 `deploy-pipeline` 구현 컨텍스트로 좁힌다.
- [x] 2026-05-30: `deploy-pipeline` 표준선은 private/internal compose lane, ignored secret profile, release note/follow-up issue의 sanitized rollback evidence로 정한다.
## 범위
- workspace `bin/test`, `bin/lint`, `bin/build` 기반 기본 검증
- optional Go test/vet/build와 webapp/npm 검증
- compose smoke, server ping, webapp 접근, push-proxy smoke
- Flutter SDK Dart/integration/Android native test
- upstream update 실패 이슈화, rollback, release note 흐름
## 기능
### Epic: [ci] Continuous verification
upstream-followable runtime과 nexo SDK를 같은 변경 흐름에서 검증한다.
- [x] [workspace-checks] CI에서 `bin/test`, `bin/lint`, `bin/build`를 실행하고 skip된 도구를 보고하는 기준을 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/01_core_webapp_checks/complete.log`에서 `bin/test`, `bin/lint`, `bin/build` 실행과 기본 skip 출력 계약 PASS를 확인했다.
- [x] [core-checks] optional Go test/vet/build와 webapp 검증을 upstream update 또는 core 변경 시 실행하는 기준을 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/01_core_webapp_checks/complete.log`에서 core Go/webapp optional gate와 `NEXO_CORE_WEBAPP_*` 계약 PASS를 확인했다.
- [x] [compose-smoke] compose로 core, webapp, db, push-proxy를 올리고 최소 smoke를 확인하는 CI 또는 원격 검증 흐름을 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/02_compose_smoke/complete.log`에서 `bin/smoke-compose` helper, 원격 runtime smoke, core/db/webapp/push-proxy 확인 PASS를 확인했다.
- [x] [sdk-checks] Flutter SDK Dart test, client integration test, Android native unit test를 환경별로 나누어 실행하는 기준을 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/03_sdk_checks/complete.log`에서 Flutter integration/Android native optional gate와 evidence sanitation PASS를 확인했다.
### Epic: [cd] Deployment loop
업데이트와 배포 실패가 추적 가능한 이슈로 남도록 운영 루프를 만든다.
- [x] [update-branch] Mattermost server/webapp/push-proxy baseline update용 branch, diff, patch inventory 절차를 정리한다. 검증: `agent-task/archive/2026/05/m-cicd-operations/04_update_response_loop/complete.log`에서 README와 각 `UPSTREAM.md`의 branch, snapshot diff, patch inventory, smoke evidence 계약 및 최종 `rg`/`git diff --check` PASS를 확인했다.
- [x] [deploy-pipeline] dev/test/production-like compose 배포, secret 주입, rollback 절차를 정리한다. 검증: `agent-task/m-cicd-operations/05_deploy_pipeline/CODE_REVIEW-cloud-G07.md`에서 `README.md`, `docs/README.md`, `services/core/compose/README.md`의 deploy loop, secret injection, rollback contract 정리와 최종 `rg`/`git diff --check` PASS를 확인했고, 2026-05-30 사용자 완료/아카이빙 지시로 완료 근거를 확정했다.
- [x] [issue-loop] upstream update 실패를 server, webapp, push-proxy, SDK contract, infra 중 하나로 분류하고 후속 이슈로 남기는 절차를 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/04_update_response_loop/complete.log`에서 실패 분류와 follow-up/rollback/defer 기록 기준 및 최종 PASS 리뷰를 확인했다.
- [x] [release-note] server/front/push-proxy baseline과 Flutter SDK compatibility를 한 번에 볼 수 있는 release note 기준을 만든다. 검증: `agent-task/archive/2026/05/m-cicd-operations/04_update_response_loop/complete.log`에서 release note decision loop와 compatibility 요약 기준 및 최종 PASS 리뷰를 확인했다.
## 완료 리뷰
- 상태: 승인됨
- 요청일: 2026-05-30
- 완료 근거: CI Epic 전체와 CD Epic의 update-branch, issue-loop, release-note는 archived complete.log로 확인했다. `deploy-pipeline`은 active implementation review stub의 정적 문서 점검 PASS와 사용자 완료/아카이빙 지시로 완료 승인됐다.
- 리뷰 필요:
- [x] 사용자가 완료 결과를 확인했다
- [x] archive 이동을 승인했다
- 리뷰 코멘트: 2026-05-30 사용자가 "마일스톤 완료로 하고 아카이빙해"라고 지시했다.
## 범위 제외
- production hardening 전체 구현은 배포 대상과 secret 정책 결정 전까지 진행하지 않는다.
- 외부 공개용 landing page나 marketing site는 포함하지 않는다.
- billing, organization management, 별도 admin console은 포함하지 않는다.
## 작업 컨텍스트
- 관련 경로: `.github/`, `bin/`, `services/core/`, `services/core/compose/`, `packages/messaging_flutter/`, `apps/flutter-test/`, `docs/`
- 표준선(선택): 먼저 private/internal deployment loop를 만들고, runner와 secret 정책이 확정되면 production-like CD로 확장한다
- 선행 작업: 업스트림 팔로잉 기준선
- 후속 작업: 운영 runbook, release/versioning 고도화
- 확인 완료: `deploy-pipeline`은 private/internal compose lane을 production-like 기준으로 삼고, secret은 ignored profile과 runtime data에 주입하며, rollback evidence는 private run log 참조와 release note/follow-up issue의 sanitized 판정으로 남긴다.
- 2026-05-30 동기화: `m-cicd-operations/01_core_webapp_checks`, `02_compose_smoke`, `03_sdk_checks`, `04_update_response_loop` PASS 완료 이벤트를 반영했다. CI Epic의 workspace/core/compose/SDK 검증 기준과 CD Epic의 update branch 절차, issue loop 분류, release note 기준은 완료됐다.
- 2026-05-30 완료 동기화: `agent-task/m-cicd-operations/05_deploy_pipeline/CODE_REVIEW-cloud-G07.md`의 구현 완료 기록과 사용자 완료/아카이빙 지시를 근거로 `[deploy-pipeline]`을 완료 처리했다.

View file

@ -15,12 +15,12 @@ Mattermost server, webapp, push-proxy를 nexo의 upstream-followable 메시징
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다. 완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다. 스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다.
- [완료] CI/CD와 운영 업데이트 루프
- 경로: `agent-roadmap/archive/phase/upstream-runtime/milestones/cicd-operations.md`
- 요약: upstream update, compose 배포, 검증 실패 이슈화를 반복 가능한 파이프라인으로 만든다.
- [진행중] 업스트림 팔로잉 기준선 - [진행중] 업스트림 팔로잉 기준선
- 경로: `agent-roadmap/phase/upstream-runtime/milestones/upstream-following.md` - 경로: `agent-roadmap/phase/upstream-runtime/milestones/upstream-following.md`
- 요약: server/webapp/push-proxy의 upstream baseline, patch 경계, update 판단 기준을 정한다. - 요약: server/webapp/push-proxy의 upstream baseline, patch 경계, update 판단 기준을 정한다.
- [계획] CI/CD와 운영 업데이트 루프
- 경로: `agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md`
- 요약: upstream update, compose 배포, 검증 실패 이슈화를 반복 가능한 파이프라인으로 만든다.
## Phase 경계 ## Phase 경계

View file

@ -1,80 +0,0 @@
# Milestone: CI/CD와 운영 업데이트 루프
## 위치
- Roadmap: `agent-roadmap/ROADMAP.md`
- Phase: `agent-roadmap/phase/upstream-runtime/PHASE.md`
## 목표
Mattermost server/webapp/push-proxy update와 nexo Flutter SDK 검증을 반복 가능한 CI/CD와 운영 runbook으로 연결한다.
upstream 업데이트에 따른 이슈를 빠르게 분류하고, 수정/보류/rollback 결정을 남길 수 있는 흐름을 만든다.
## 상태
[계획]
## 승격 조건
- 없음
## 구현 잠금
- 상태: 잠금
- 결정 필요:
- [ ] CI/CD 실행 위치를 GitHub Actions, 자체 runner, 원격 테스트 서버 중 어디에 둘지 결정한다.
- [ ] production-like 배포 대상과 secret 보관 방식을 결정한다.
- 결정 완료:
- [x] 2026-05-27: upstream update를 쉽게 따라가기 위한 CI/CD와 이슈 대응 루프를 프로젝트 방향성에 포함한다.
## 범위
- workspace `bin/test`, `bin/lint`, `bin/build` 기반 기본 검증
- optional Go test/vet/build와 webapp/npm 검증
- compose smoke, server ping, webapp 접근, push-proxy smoke
- Flutter SDK Dart/integration/Android native test
- upstream update 실패 이슈화, rollback, release note 흐름
## 기능
### Epic: [ci] Continuous verification
upstream-followable runtime과 nexo SDK를 같은 변경 흐름에서 검증한다.
- [ ] [workspace-checks] CI에서 `bin/test`, `bin/lint`, `bin/build`를 실행하고 skip된 도구를 보고하는 기준을 만든다.
- [ ] [core-checks] optional Go test/vet/build와 webapp 검증을 upstream update 또는 core 변경 시 실행하는 기준을 만든다.
- [ ] [compose-smoke] compose로 core, webapp, db, push-proxy를 올리고 최소 smoke를 확인하는 CI 또는 원격 검증 흐름을 만든다.
- [ ] [sdk-checks] Flutter SDK Dart test, client integration test, Android native unit test를 환경별로 나누어 실행하는 기준을 만든다.
### Epic: [cd] Deployment loop
업데이트와 배포 실패가 추적 가능한 이슈로 남도록 운영 루프를 만든다.
- [ ] [update-branch] Mattermost server/webapp/push-proxy baseline update용 branch, diff, patch inventory 절차를 정리한다.
- [ ] [deploy-pipeline] dev/test/production-like compose 배포, secret 주입, rollback 절차를 정리한다.
- [ ] [issue-loop] upstream update 실패를 server, webapp, push-proxy, SDK contract, infra 중 하나로 분류하고 후속 이슈로 남기는 절차를 만든다.
- [ ] [release-note] server/front/push-proxy baseline과 Flutter SDK compatibility를 한 번에 볼 수 있는 release note 기준을 만든다.
## 완료 리뷰
- 상태: 없음
- 요청일: 없음
- 완료 근거: 없음
- 리뷰 필요:
- [ ] 사용자가 완료 결과를 확인했다
- [ ] archive 이동을 승인했다
- 리뷰 코멘트: 없음
## 범위 제외
- production hardening 전체 구현은 배포 대상과 secret 정책 결정 전까지 진행하지 않는다.
- 외부 공개용 landing page나 marketing site는 포함하지 않는다.
- billing, organization management, 별도 admin console은 포함하지 않는다.
## 작업 컨텍스트
- 관련 경로: `.github/`, `bin/`, `services/core/`, `services/core/compose/`, `packages/messaging_flutter/`, `apps/flutter-test/`, `docs/`
- 표준선(선택): 먼저 private/internal deployment loop를 만들고, runner와 secret 정책이 확정되면 production-like CD로 확장한다
- 선행 작업: 업스트림 팔로잉 기준선
- 후속 작업: 운영 runbook, release/versioning 고도화
- 확인 필요: CI/CD 실행 위치와 production-like 배포 대상

View file

@ -79,5 +79,7 @@ nexo 변경이 upstream merge를 어렵게 만들지 않도록 허용 경계를
- 표준선(선택): server/webapp/push-proxy는 upstream-followable runtime, Flutter SDK는 nexo-owned embedded SDK - 표준선(선택): server/webapp/push-proxy는 upstream-followable runtime, Flutter SDK는 nexo-owned embedded SDK
- upstream 추적 방식: 프로젝트 규칙이 repository별 branch, staging 위치, snapshot 기록, merge 분리 원칙을 정의하고, workspace script는 외부 `mattermost/` staging clone update와 이 repo로의 snapshot copy만 자동화한다. 반영 여부는 diff/smoke 확인 후 repo별 merge 요청에서 결정한다. - upstream 추적 방식: 프로젝트 규칙이 repository별 branch, staging 위치, snapshot 기록, merge 분리 원칙을 정의하고, workspace script는 외부 `mattermost/` staging clone update와 이 repo로의 snapshot copy만 자동화한다. 반영 여부는 diff/smoke 확인 후 repo별 merge 요청에서 결정한다.
- 선행 작업: 정체성 기준선 - 선행 작업: 정체성 기준선
- 후속 작업: CI/CD와 운영 업데이트 루프, 메시징 계약 표준화 - 후속 작업: 메시징 계약 표준화
- 완료된 관련 작업: CI/CD와 운영 업데이트 루프는 2026-05-30 archive 완료
- 다음 작업 지점: `[source-baseline]`에서 server/webapp upstream tag/commit, 적용 patch, nexo-local 변경 범위 기록 기준을 먼저 정리한다. 이후 `[snapshot-script]`로 staging clone update와 snapshot copy 계약을 이어간다.
- 확인 필요: 없음 - 확인 필요: 없음

View file

@ -0,0 +1,160 @@
<!-- task=m-cicd-operations/05_deploy_pipeline plan=0 tag=OPS -->
# Code Review Reference - OPS
> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
> The task is NOT complete until every implementation-owned section below is filled in.
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
> Fill implementation-owned sections, then stop with active files in place and report ready for review.
> If implementation is blocked by a user-only decision, external environment prerequisite, or scope conflict, fill `사용자 리뷰 요청` with evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`.
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
> Follow the ownership table at the bottom of this file for which sections you own.
## 개요
date=2026-05-30
task=m-cicd-operations/05_deploy_pipeline, plan=0, tag=OPS
## 이 파일을 읽는 리뷰 에이전트에게
> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
1. 판정을 append한다.
2. `CODE_REVIEW-cloud-G07.md` -> `code_review_cloud_G07_N.log`, `PLAN-cloud-G07.md` -> `plan_cloud_G07_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-cicd-operations/05_deploy_pipeline/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 사용자 결정으로 완료/PASS 해소되면 code-review가 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
---
## 구현 항목별 완료 여부
| 항목 | 완료 여부 |
|------|---------|
| [OPS-1] Workspace deploy pipeline link | [x] |
| [OPS-2] Compose deployment lanes and rollback contract | [x] |
| [OPS-3] Milestone context cleanup | [x] |
## 구현 체크리스트
- [x] [OPS-1] root README와 docs index에 deploy pipeline의 공개 계약 위치와 기록 기준을 연결한다.
- [x] [OPS-2] core compose README에 dev/test/production-like lane, secret profile, rollback evidence 기준을 환경값 없이 정리한다.
- [x] [OPS-3] Milestone 컨텍스트에서 `deploy-pipeline` 진행 전 확인 필요 문구를 구현 표준선으로 좁힌다. 단, task 완료 체크는 code-review PASS 전까지 유지한다.
- [x] 정적 문서 점검 명령을 실행하고 runtime 검증 미실행 사유를 기록한다.
- [x] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
## 코드리뷰 전용 체크리스트
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
- [ ] `코드리뷰 결과``PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [ ] active `CODE_REVIEW-*-G??.md``code_review_cloud_G07_N.log`로 아카이브한다.
- [ ] active `PLAN-*-G??.md``plan_cloud_G07_M.log`로 아카이브한다.
- [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [ ] PASS이면 active task 디렉터리 `agent-task/m-cicd-operations/05_deploy_pipeline/``agent-task/archive/YYYY/MM/m-cicd-operations/05_deploy_pipeline/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
- [ ] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
- [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/m-cicd-operations/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
- [ ] WARN/FAIL이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-cloud-G07.md``CODE_REVIEW-cloud-G07.md`를 작성하고 `complete.log`를 작성하지 않는다.
- [ ] USER_REVIEW이면 `agent-ops/skills/common/code-review/templates/user-review-template.md` 기준으로 `USER_REVIEW.md`를 작성하고 active `PLAN-*.md`, `CODE_REVIEW-*.md`, `complete.log`를 남기지 않는다.
- [ ] USER_REVIEW가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.
## 계획 대비 변경 사항
없음.
## 주요 설계 결정
- 배포 표준선은 tracked 문서에 실제 환경값을 쓰지 않는 공개 계약으로 제한했다.
- `production-like`는 별도 공개 target이 아니라 private/internal compose lane의 release rehearsal로 정의했다.
- rollback evidence는 private run log 참조와 release note/follow-up issue의 sanitized 판정으로 나누어 기록하도록 정리했다.
- `docker-compose.yml`, `.env.example`, runtime image evidence 문서는 변경하지 않았다.
## 사용자 리뷰 요청
- 상태: 없음
- 사유 유형: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 재개 조건: 없음
## 리뷰어를 위한 체크포인트
- tracked 문서와 task/review 로그에 실제 환경값, raw credential, private endpoint가 추가되지 않았는지 확인한다.
- `services/core/compose/README.md`의 lane/secret/rollback 계약이 기존 smoke와 remote parity 설명을 깨지 않는지 확인한다.
- Milestone의 `[deploy-pipeline]` 체크박스가 code-review PASS 전까지 미완료로 유지됐는지 확인한다.
- runtime smoke를 실행하지 않은 사유가 local rule과 일치하는지 확인한다.
## 검증 결과
필수 규칙:
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
- 사용자 리뷰 요청으로 명령을 끝까지 실행하지 못했다면 `사용자 리뷰 요청`에 실행한 명령, 실제 출력, 미실행 명령의 사유를 기록한다.
### OPS-1 중간 검증
```sh
$ rg --sort path -n "운영 업데이트/배포 흐름|deploy loop|rollback evidence|secret profile" README.md docs/README.md services/core/compose/README.md
README.md:108:## 운영 업데이트/배포 흐름
README.md:114:3. secret profile label과 주입 방식. 실제 값, credential, host, port는 tracked 문서와 task/review log에 쓰지 않는다.
README.md:116:5. rollback ref와 rollback evidence 위치. 공개 기록에는 private run log 참조와 판정만 남긴다.
docs/README.md:11:- Core compose runtime, deploy loop, smoke checks, remote parity, and secret boundary:
services/core/compose/README.md:89:| `production-like` | Internal release rehearsal before a stable pointer is treated as deployable. | Image refs, compose input hashes, secret profile label, smoke evidence, and rollback ref are recorded together. |
services/core/compose/README.md:98:git. A tracked report may name the secret profile label and rotation decision,
services/core/compose/README.md:109:hashes, secret profile label, and data snapshot reference in the private run log.
services/core/compose/README.md:113:A rollback restores the previous image refs and secret profile, starts the same
```
### OPS-2 중간 검증
```sh
$ rg --sort path -n 'Deployment Lanes|Secret Injection|Rollback Contract|`dev`|`test`|`production-like`' services/core/compose/README.md
83:### Deployment Lanes
87:| `dev` | Disposable runtime for local feature checks and compose iteration. | Compose config renders, services start, and the smoke checks above pass. |
88:| `test` | Shared validation lane for upstream baseline or image updates before release notes. | Compose inputs match the candidate branch, images pull by immutable tag or digest, smoke passes, and failures are classified. |
89:| `production-like` | Internal release rehearsal before a stable pointer is treated as deployable. | Image refs, compose input hashes, secret profile label, smoke evidence, and rollback ref are recorded together. |
91:Use immutable tags or digests for `test` and `production-like` candidates.
95:### Secret Injection
106:### Rollback Contract
```
### OPS-3 중간 검증
```sh
$ rg --sort path -n "deploy-pipeline|private/internal compose lane|확인 완료" agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md
28: - [x] 2026-05-30: CI 검증 기준은 workspace helper, optional gate, compose smoke, SDK optional check로 정리했고, 남은 결정은 마일스톤 전체 잠금이 아니라 `deploy-pipeline` 구현 컨텍스트로 좁힌다.
29: - [x] 2026-05-30: `deploy-pipeline` 표준선은 private/internal compose lane, ignored secret profile, release note/follow-up issue의 sanitized rollback evidence로 정한다.
55:- [ ] [deploy-pipeline] dev/test/production-like compose 배포, secret 주입, rollback 절차를 정리한다.
81:- 확인 완료: `deploy-pipeline`은 private/internal compose lane을 production-like 기준으로 삼고, secret은 ignored profile과 runtime data에 주입하며, rollback evidence는 private run log 참조와 release note/follow-up issue의 sanitized 판정으로 남긴다.
```
### 최종 검증
```sh
$ rg --sort path -n "운영 업데이트/배포 흐름|Deployment Lanes|Secret Injection|Rollback Contract|private/internal compose lane|rollback evidence" README.md docs/README.md services/core/compose/README.md agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md
README.md:108:## 운영 업데이트/배포 흐름
README.md:116:5. rollback ref와 rollback evidence 위치. 공개 기록에는 private run log 참조와 판정만 남긴다.
services/core/compose/README.md:83:### Deployment Lanes
services/core/compose/README.md:95:### Secret Injection
services/core/compose/README.md:106:### Rollback Contract
agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md:29: - [x] 2026-05-30: `deploy-pipeline` 표준선은 private/internal compose lane, ignored secret profile, release note/follow-up issue의 sanitized rollback evidence로 정한다.
agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md:81:- 확인 완료: `deploy-pipeline`은 private/internal compose lane을 production-like 기준으로 삼고, secret은 ignored profile과 runtime data에 주입하며, rollback evidence는 private run log 참조와 release note/follow-up issue의 sanitized 판정으로 남긴다.
$ git diff --check -- README.md docs/README.md services/core/compose/README.md agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md agent-task/m-cicd-operations/05_deploy_pipeline/PLAN-cloud-G07.md agent-task/m-cicd-operations/05_deploy_pipeline/CODE_REVIEW-cloud-G07.md
# stdout/stderr: no output
```
Runtime smoke, compose execution, remote deployment, and secret-profile validation were not run. `agent-test/local/rules.md` prohibits local tests/verification, and this implementation only changed tracked documentation/roadmap/task files.
---
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
> If anything is blank, go back and fill it in before saving this file.
> Leave review-agent-only sections unchanged.

View file

@ -0,0 +1,152 @@
<!-- task=m-cicd-operations/05_deploy_pipeline plan=0 tag=OPS -->
# Plan - OPS Deploy Pipeline Contract
## 이 파일을 읽는 구현 에이전트에게
`CODE_REVIEW-cloud-G07.md`의 구현 에이전트 소유 섹션을 채우는 것까지가 구현이다. 검증 명령을 실행하고 실제 출력/생략 사유를 남긴 뒤 active 파일을 그대로 두고 리뷰를 요청한다. 사용자 결정, 외부 환경 준비, 범위 충돌 없이는 안전하게 진행할 수 없는 경우 `사용자 리뷰 요청` 섹션에 정확한 결정, 근거, 실행 출력, 재개 조건을 기록하고 중단한다. `complete.log`, archive 이동, 코드리뷰 결과 작성은 code-review 전용이다.
## 배경
`cicd-operations` Milestone에서 CI 기준과 update/issue/release-note 루프는 정리됐고, 남은 항목은 compose 배포, secret 주입, rollback 절차다. private rule 때문에 tracked 문서에는 실제 환경값, host, port, token, credential, 사설 runbook을 남기지 않는다. 따라서 이번 작업은 dev/test/production-like lane의 공통 계약, secret profile 경계, rollback evidence 기준을 공개 가능한 수준으로 정리한다.
## 사용자 리뷰 요청 흐름
구현 중 차단이 생기면 active `CODE_REVIEW-cloud-G07.md``사용자 리뷰 요청` 섹션에 `agent-ops/skills/common/_templates/implementation-user-review-request-section.md` 형식으로 남긴다. code-review가 그 요청을 검증하고 실제 `USER_REVIEW.md` 작성 여부를 결정한다.
## 분석 결과
### 읽은 파일
- `README.md`
- `docs/README.md`
- `docs/runtime-image-validation.md`
- `services/core/compose/README.md`
- `services/core/compose/docker-compose.yml`
- `services/core/compose/.env.example`
- `agent-roadmap/current.md`
- `agent-roadmap/phase/upstream-runtime/PHASE.md`
- `agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md`
- `agent-ops/rules/project/domain/workspace-ops/rules.md`
- `agent-ops/rules/project/domain/core-service/rules.md`
- `agent-ops/rules/private/rules.md`
- `agent-test/local/rules.md`
- `agent-ops/skills/common/plan/SKILL.md`
### 테스트 커버리지 공백
- 문서 계약 추가라 기존 자동 테스트는 직접 커버하지 않는다.
- compose/runtime 동작은 이번 범위에서 실행하지 않는다. local rule이 로컬 테스트/검증을 금지하므로 runtime smoke는 리뷰 또는 별도 원격 검증 작업에서 다룬다.
### 심볼 참조
- 없음. public API, shell helper 이름, compose service 이름을 변경하지 않는다.
### 분할 판단
split decision policy를 먼저 평가했다. 변경은 `README.md`, `docs/README.md`, `services/core/compose/README.md`, Milestone 컨텍스트를 함께 만지지만 모두 하나의 `deploy-pipeline` 문서 계약을 완성하기 위한 cross-link다. API/foundation과 call-site rollout, 테스트 전략, 독립 실패면이 분리되지 않으므로 단일 plan이 더 안전하다.
### 범위 결정 근거
- `docker-compose.yml``.env.example` 값은 변경하지 않는다. 배포 계약을 문서화하는 작업이며 런타임 설정 자체를 바꾸면 production-like 정책 결정 범위를 넘는다.
- `docs/runtime-image-validation.md`는 기존 registry evidence 문서라 이번 작업에서 확장하지 않는다. 실제 endpoint/host가 섞인 과거 evidence를 더 늘리지 않기 위해 compose README에 일반 계약만 추가한다.
- `.github/` workflow와 신규 배포 스크립트는 만들지 않는다. Milestone의 남은 항목은 절차 정리이며 runner/secret provider 확정은 후속 작업이다.
### 빌드 등급
- `cloud-G07`: 운영 배포/rollback/secret 경계 문서화이며 외부 환경과 private rule 제약이 있어 높은 리뷰 주의가 필요하다.
## 구현 체크리스트
- [ ] [OPS-1] root README와 docs index에 deploy pipeline의 공개 계약 위치와 기록 기준을 연결한다.
- [ ] [OPS-2] core compose README에 dev/test/production-like lane, secret profile, rollback evidence 기준을 환경값 없이 정리한다.
- [ ] [OPS-3] Milestone 컨텍스트에서 `deploy-pipeline` 진행 전 확인 필요 문구를 구현 표준선으로 좁힌다. 단, task 완료 체크는 code-review PASS 전까지 유지한다.
- [ ] 정적 문서 점검 명령을 실행하고 runtime 검증 미실행 사유를 기록한다.
- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
## 구현 항목
### [OPS-1] Workspace deploy pipeline link
문제: `README.md:100-106` 개발 흐름은 compose 사용 위치만 말하고, 배포 후보, secret profile, rollback evidence가 어디에 기록되는지 연결하지 않는다. `docs/README.md:10-16` index도 deploy loop를 명시하지 않는다.
해결 방법: root README에 운영 업데이트/배포 흐름 섹션을 추가하고, docs index의 compose 항목에 deploy loop를 포함한다. 문구는 공개 가능한 계약만 남기고 실제 환경값은 쓰지 않는다.
수정 파일 및 체크리스트:
- [ ] `README.md`에 deploy loop 기준 섹션 추가
- [ ] `docs/README.md`의 runtime baseline index 문구 갱신
테스트 작성: 문서-only 변경이라 테스트는 추가하지 않는다.
중간 검증:
```sh
rg --sort path -n "운영 업데이트/배포 흐름|deploy loop|rollback evidence|secret profile" README.md docs/README.md services/core/compose/README.md
```
예상 결과: 새 문구가 세 파일에서 검색된다.
### [OPS-2] Compose deployment lanes and rollback contract
문제: `services/core/compose/README.md:6-75`는 local runtime, secret boundary, smoke, remote parity를 설명하지만 dev/test/production-like lane, ignored secret profile, rollback evidence 계약이 없다.
해결 방법: compose README에 Deployment Lanes, Secret Injection, Rollback 섹션을 추가한다. 실제 host/port/credential 값 대신 lane 목적, promotion gate, 기록해야 할 evidence 종류만 정리한다.
수정 파일 및 체크리스트:
- [ ] `services/core/compose/README.md`에 배포 lane 표 추가
- [ ] `services/core/compose/README.md`에 secret injection 규칙 추가
- [ ] `services/core/compose/README.md`에 rollback 기준 추가
테스트 작성: 문서-only 변경이라 테스트는 추가하지 않는다.
중간 검증:
```sh
rg --sort path -n 'Deployment Lanes|Secret Injection|Rollback Contract|`dev`|`test`|`production-like`' services/core/compose/README.md
```
예상 결과: lane, secret, rollback 섹션이 검색된다.
### [OPS-3] Milestone context cleanup
문제: `agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md:80``deploy-pipeline` 진행 전 확인 필요라고 남아 있어, 지금 선택한 표준선과 맞지 않는다.
해결 방법: 구현 잠금 결정 완료에 배포 표준선을 추가하고, 작업 컨텍스트의 확인 필요를 확인 완료로 바꾼다. `[deploy-pipeline]` 체크박스는 code-review PASS 전까지 미완료로 둔다.
수정 파일 및 체크리스트:
- [ ] `agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md` 결정 완료 항목 추가
- [ ] 같은 파일의 작업 컨텍스트 확인 문구 갱신
테스트 작성: 로드맵 문서 갱신이라 테스트는 추가하지 않는다.
중간 검증:
```sh
rg --sort path -n "deploy-pipeline|private/internal compose lane|확인 완료" agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md
```
예상 결과: task 체크박스는 미완료이고, 구현 표준선 문구가 검색된다.
## 수정 파일 요약
| 파일 | 항목 |
| --- | --- |
| `README.md` | OPS-1 |
| `docs/README.md` | OPS-1 |
| `services/core/compose/README.md` | OPS-2 |
| `agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md` | OPS-3 |
| `agent-task/m-cicd-operations/05_deploy_pipeline/CODE_REVIEW-cloud-G07.md` | 구현 기록 |
## 최종 검증
```sh
rg --sort path -n "운영 업데이트/배포 흐름|Deployment Lanes|Secret Injection|Rollback Contract|private/internal compose lane|rollback evidence" README.md docs/README.md services/core/compose/README.md agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md
git diff --check -- README.md docs/README.md services/core/compose/README.md agent-roadmap/phase/upstream-runtime/milestones/cicd-operations.md agent-task/m-cicd-operations/05_deploy_pipeline/PLAN-cloud-G07.md agent-task/m-cicd-operations/05_deploy_pipeline/CODE_REVIEW-cloud-G07.md
```
예상 결과: 검색 결과가 의도한 섹션만 보여주고 whitespace error가 없다. runtime smoke는 local rule상 실행하지 않으며, 그 사유를 review 파일에 기록한다.
모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다.

View file

@ -8,10 +8,9 @@ Module-specific instructions stay with the module that owns them.
## Runtime Baseline Index ## Runtime Baseline Index
- Workspace runtime and upstream policy: `../README.md` - Workspace runtime and upstream policy: `../README.md`
- Core compose runtime, smoke checks, remote parity, and secret boundary: - Core compose runtime, deploy loop, smoke checks, remote parity, and secret boundary:
`../services/core/compose/README.md` `../services/core/compose/README.md`
- Core upstream snapshot baseline: `../services/core/UPSTREAM.md` - Core upstream snapshot baseline: `../services/core/UPSTREAM.md`
- Mattermost mobile app upstream snapshot baseline: `../apps/mattermost/UPSTREAM.md` - Mattermost mobile app upstream snapshot baseline: `../apps/mattermost/UPSTREAM.md`
- Mattermost push-proxy upstream snapshot baseline: `../services/push-proxy/UPSTREAM.md` - Mattermost push-proxy upstream snapshot baseline: `../services/push-proxy/UPSTREAM.md`
- Runtime Image Validation details: `runtime-image-validation.md` - Runtime Image Validation details: `runtime-image-validation.md`

View file

@ -73,3 +73,44 @@ ssh <host> 'cd ~/docker/services/nexo/compose && sha256sum docker-compose.yml .e
The two `sha256sum` outputs should match for both files before remote runtime The two `sha256sum` outputs should match for both files before remote runtime
smoke is treated as equivalent to local compose smoke. smoke is treated as equivalent to local compose smoke.
## Deployment Loop
The compose deployment loop uses the same input contract for dev, test, and
production-like lanes. The lane changes the target and promotion gate, not the
tracked compose file.
### Deployment Lanes
| Lane | Purpose | Promotion gate |
| --- | --- | --- |
| `dev` | Disposable runtime for local feature checks and compose iteration. | Compose config renders, services start, and the smoke checks above pass. |
| `test` | Shared validation lane for upstream baseline or image updates before release notes. | Compose inputs match the candidate branch, images pull by immutable tag or digest, smoke passes, and failures are classified. |
| `production-like` | Internal release rehearsal before a stable pointer is treated as deployable. | Image refs, compose input hashes, secret profile label, smoke evidence, and rollback ref are recorded together. |
Use immutable tags or digests for `test` and `production-like` candidates.
`latest` remains the stable pointer only after the candidate evidence is already
recorded.
### Secret Injection
Start each lane from `.env.example`, then keep the concrete env profile outside
git. A tracked report may name the secret profile label and rotation decision,
but must not include raw values, credential files, hostnames, ports, tokens, or
private endpoint paths.
Push-proxy FCM/APNS credentials stay under ignored runtime data. If a new secret
path is needed, add only the example variable or sanitized path contract here,
then confirm the concrete file remains ignored.
### Rollback Contract
Before applying a candidate, record the previous image refs, compose input
hashes, secret profile label, and data snapshot reference in the private run log.
The public release note or follow-up issue records only the rollback ref,
classification, and sanitized evidence pointer.
A rollback restores the previous image refs and secret profile, starts the same
compose services, and reruns the smoke checks above. If rollback smoke fails,
classify the failure as `server`, `webapp`, `push-proxy`, `SDK contract`, or
`infra`, then open the follow-up before another promotion attempt.