검증 · 출시 · 양식
릴리즈 노트 양식
사용자 공지와 내부 변경 기록을 한 문서에서 함께 쓴다.
이럴 때 써요
- 배포한 변경 사항을 사용자와 내부에 알릴 때
- 무엇이 언제 왜 바뀌었는지 이력을 남길 때
양식 구성
9개 절로 이루어져 있습니다.
- 릴리즈 정보
- 버전 · 영향 범위 · 작성자 · 배포일
- 1 사용자용 릴리즈 노트
- 사용자가 읽습니다. 내부 용어 대신 사용자가 쓰는 말로 씁니다.
- 2 내부용 변경 사항
- 팀이 알아야 할 변경을 적는다. 요구사항 ID 와 이어 두면 무엇이 빠졌는지 보인다.
- 3 정책 변경
- 정책이 바뀌면 기존 데이터를 어떻게 할지 함께 적는다. 이 칸이 비면 CS 문의가 몰린다.
- 4 데이터 변경
- 스키마·데이터 변경을 적고 되돌릴 수 있는지 표시한다. 되돌릴 수 없으면 배포 전에 다시 검토한다.
- 5 운영 영향
- 운영·CS 가 이번 배포로 무엇을 다르게 해야 하는지 적는다.
- 6 신규 이벤트 로그
- 새로 쌓기 시작하는 이벤트를 적는다. 대시보드에 반영됐는지도 함께 확인한다.
- 7 롤백 정보
- 이 릴리즈를 되돌리는 방법과 한계를 적는다.
- 8 미포함 · 이월 항목
- 이번에 못 넣은 것과 이유를 적는다. 다음 릴리즈로 넘긴다는 말만 남기면 그대로 잊힌다.
바로 써 보기
로그인 없이 바로 쓸 수 있습니다. 다 쓰면 PDF·Word·한글(HWPX)·Markdown 으로 내보냅니다.
검증 · 출시 단계의 다른 양식
- 테스트 계획서 — 무엇을 어떤 범위와 방법으로 검증할지, 언제 누가 할지를 케이스 작성 전에 확정한다.
- 테스트 케이스 (TC) — 검증 시나리오와 기대 결과를 케이스 단위로 작성한다.
- 오픈 체크리스트 — D-7 부터 배포 당일, 롤백 판단까지 출시 절차를 점검한다.
- 배포 계획서 — 배포 절차와 순서, 검증 방법과 롤백 트리거·절차를 명령 단위로 확정한다.