릴리즈 날짜가 가까워지고 빌드가 성공했고 QA가 승인했으며 alguien이 팀이 나중에 늦게 들은 질문을 물어보는 경우가 있습니다: “릴리즈 노트를 작성하는 사람 누구인가?”
그것은 일반적으로 혼란의 시작입니다. 엔지니어들은 커밋을 훑어보고 제품은 Jira를 확인하고 지원은 고객을 대면하는 3개의 수정 사항을 기억합니다. 그러나 이 수정 사항들은 드래프트에 포함되지 않았습니다. 마케팅은 더 깨끗한 요약을 원합니다. 릴리즈 노트가 공개되기까지, 그들은 사용자에게 도움이 되지 않거나 너무 추상적이어서 변경된 내용을 설명하지 못합니다.
좋은 애플리케이션 릴리스 노트는 릴리스 프로세스의 마지막에 발생하지 않는다. 그들은 변경 사항이 여전히 빌드, 검토 및 배포 중일 때 workflow가 시작되는 훨씬 이전에 발생한다. 릴리스 노트를 배달의 일부로 다루는 팀은 더 빠르게 릴리스를 발행하고, 중요한 세부 정보를 놓치지 않고, 사용자에게 릴리스한 내용을 훨씬 rõ ràng하게 전달할 수 있다.
목차
- 잘 제작된 릴리스 노트는 비밀 무기다.
- 릴리스 정보를 체계적으로 제공하는 방법
- 사용자가 실제로 읽을 수 있는 릴리스 노트를 작성하고 포맷한다.
- 다양한 채널과 대상자에 대한 배포 전략
- CI/CD 및 최신 도구를 사용한 릴리즈 노트 자동화
- 롤백 및 규정 준수에 대한 기업급 노트
Why Well-Crafted Release Notes Are a Secret Weapon
많은 사람들이 애플리케이션 릴리스 노트를 패키징 물질처럼 다루고 있습니다. 필요하지만 중요하지 않다고 생각합니다. 이러한 마음가짐은 의미 있는 결정이 이미 이루어진 후에 작성이 시작되기 때문에 약한 노트를 만듭니다.
보다 나은 관점은 간단합니다. 릴리스 노트는 제품 커뮤니케이션의 일부입니다. 사용자에게 변경 사항, 그 중요성, 그리고 다음 단계를 알려줍니다. 릴리스 노트 구조에 대한 지침은 이제 엔지니어링 로그에서 벗어나 사용자 대면 형식으로 이동했습니다. 헤더, 개요, 이슈 요약, 해결, 영향 섹션과 주요 릴리스에 대한 더 자세한 설명, 그리고 미니 릴리스에 대한 짧은 요약이 포함됩니다. 이 guide to release note structure.
이 변화는 중요합니다. 사용자는 제품을 스프린트 보드처럼 경험하지 않습니다. 그들은 신뢰를 경험합니다. 앱이 변경되고 사용자가 왜 그런지 이해하지 못하면 신뢰가 떨어집니다. 기능이 출시되고 nobody가 이를 알아차리지 못하면 릴리스는 여전히 발생하지만 가치가 착륙하지 않습니다.
What strong notes actually do
좋은 릴리스 노트는 세 가지 방식으로 도움이 됩니다.
- They set expectations: 사용자는 변경이 화려한 것인지, 운영에 영향을 미치는 것인지, 또는 사용자가 행동해야 하는 것인지 알 수 있습니다.
- They surface value: 스토어 설명서 또는 지원 문서에 숨겨진 기능 발표는 timely한 릴리스 노트와 같은 주목을 받지 못합니다.
- They reduce confusion: 지원 팀은 문제가 고쳐졌는지, 변경되었는지, 아직 배포 중인지 설명하는 데 시간을 덜 소비합니다.
실용적인 규칙: 사용자가 몇 초 안에 릴리스가 자신에게 영향을 미치는지 알 수 없다면, 노트는 팀을 위해 작성된 것입니다, 고객을 위해 작성된 것은 아닙니다.
특히 반복 업데이트가 있는 제품에서 중요합니다. 명확한 커뮤니케이션이 없는 빈번한 변경은 불안정하게 느껴집니다. 명확한 커뮤니케이션이 있는 빈번한 변경은 활발하고 반응적인 것으로 느껴집니다. 이러한 차이는 시간이 지나면서 수용, 고객 신뢰 및 유지율에 영향을 미칩니다. 고객 참여에 관심이 있는 팀은 릴리스 커뮤니케이션을 온보딩 및 습관 형성과 같은 시스템으로 다루어야 합니다. 릴리스 메시징은 개선된 앱 사용자 유지율에 대한 더 광범위한 대화에 속하는 것이기도 합니다. weak 노트의 예.
weak 노트는 일반적으로 세 가지 방법 중 하나로 실패합니다.
문제
| 사용자가 보는 것 | 그것이 유발하는 것 | too 기술적 |
|---|---|---|
| 내부 단어, 티켓 ID, 구현 세부 사항 | internal wording, ticket IDs, implementation details | 사용자는 업데이트를 무시합니다. |
| 너무 추상적입니다. | “버그 수정 및 개선” | 사용자는 아무것도 배울 수 없습니다. |
| 너무 늦습니다. | 릴리스 노트가 출시 후에 잘못된 위치에 게시됩니다. | 사용자는 혼란을 연결하는 대신 지침을 연결합니다. |
잘 제작된 릴리스 노트는 단순한 업무가 아닙니다. 릴리스 노트는 출시와 이해 사이에 직접 위치하는 제품 항목 중 하나입니다. 그 이유로 그것은 비밀 무기입니다. 팀은 그들에 대해 과소 투자하는 경향이 있습니다. 그들은 릴리스 노트에 대해 더 명확하게 작성하는 팀은 빠르게 선별될 수 있습니다.
릴리스 정보를 체계적으로 제공하는 방법
잘못된 릴리스 노트는 일반적으로 잘못된 수집으로 시작합니다. 입력이 GitHub, Jira, Slack, QA 쓰레드 및 지원 티켓에 흩어져 있으면 쓰기 과정이 추측과 같습니다.
강한 워크플로는 개발, 버전 관리 및 프로젝트 관리 시스템에서 변경 사항을 추출하고 사용자 영향에 따라 정렬하여 중요한 항목이 먼저 나타나고 깨진 변경 사항이 명확하게 표시되도록 합니다. 그 구조는 이 월요일닷컴에서 제공하는 릴리스 노트 워크플로우 템플릿에서 권장됩니다.와 실제 경험 팀이 실제로 수행하는 것과 일치합니다.
배포 intake 프로세스를 구축하여 draft가 존재하기 전에 해당 질문에 대한 답변을 얻으십시오.
실용적인 pipeline은 일반적으로 다음과 같은 소스에서 데이터를 가져옵니다.
버전 관리
-
커밋 히스토리는 __CAPGO_KEEP_0__의 실제 기록을 제공합니다. 팀이 Conventional Commits를 사용한다면 extraction이 더 쉬워집니다. Commit history gives you the factual record of code movement. If your team uses Conventional Commits, extraction gets easier because
feat,fix,refactor이미 의도와 함께 이미지를 가지고 있습니다. 커밋 메시지에 대한 팀 표준은 Conventional Commits를 사용하여 CI/CD를 자동화할 때 다시 보상합니다.breaking프로젝트 관리 Jira, Linear, Asana, 또는 ClickUp는 Git가 부족한 평문 설명을 포함하고 있습니다. 티켓도 수락 기준, 레이블, 우선순위, 고객 요청과 관련된 정보를 포함하고 있습니다. 이러한 정보는 변경이 릴리스 노트에 포함되는지 결정하는 데 도움이 됩니다.. -
지원 및 성공 입력 프로젝트 관리
-
Jira, Linear, Asana, 또는 ClickUp는 Git가 부족한 평문 설명을 포함하고 있습니다. 티켓도 수락 기준, 레이블, 우선순위, 고객 요청과 관련된 정보를 포함하고 있습니다. 이러한 정보는 변경이 릴리스 노트에 포함되는지 결정하는 데 도움이 됩니다. 사용자에게 피해를 주는 버그를 알고 있는 지원팀. 고객 성공팀은 고객이 특정 기능을 요청한 계정을 알고 있습니다. 이 채널을 무시하면, 노트는 백엔드 작업을 과대평가하고 고객이 관심을 두는 것을 과소평가합니다.
-
QA 및 릴리즈 관리 QA는 릴리즈가 포함된 변경 사항을 확인할 수 있습니다. 이는 명백한 것처럼 보이지만, 팀은 “계획된” 변경 사항 대신 “배포된” 변경 사항을 기록하는 경우가 많습니다.
릴리즈 자료를 수집하는 것은 모든 변경 사항을 찾는 것이 아니라 사용자가 알 수 있는 변경 사항, 운영자에게 알려야 하는 변경 사항, 개발자가 나중에 필요로 하는 변경 사항을 식별하는 것입니다.
변경 사항을 순위 매기기
릴리스 자료가 존재하는 raw 목록이 생성되면, 영향 수준에 따라 분류합니다. flat 백로그 덤프에서부터 작성하지 마십시오.
다음과 같은 간단한 분류 모델을 사용하세요.
- Tier A: 새로운 기능, 주요 UX 변경, 기능 중단, 가격 또는 접근 변경, 보안 관련 수정
- Tier B: 기존 워크플로우에 의미 있는 개선, 사용자가 느낄 수 있는 신뢰성 수정, 중요한 관리자 변경
- Tier C: 소규모 수정, 시각적 완성, 낮은 가시성 유지 작업
__CAPGO_KEEP_0__
이 순위는 두 가지 일반적인 문제를 해결합니다. 첫 번째로, 높은 영향력을 가지는 항목이 작은 수정의 쌓인 산더미 아래에 묻히지 않도록 합니다. 두 번째로, 검토자의 주의가 가장 높은 위험이 있는 곳에 집중할 수 있게 하여 승인 과정을 쉽게 만듭니다.
릴리즈 노트의 참조 소스 생성
릴리즈 노트의 초안 자체가 참조 소스가 아닌 것이 중요합니다. 릴리즈 레코드의 구조화된 레코드를 사용하여 작성이 시작되기 전에
- 다음과 같은 field를 포함하세요:
- 버전 또는 빌드 식별자
- 릴리즈 날짜
- 변경 소유자
- 사용자에게 보이는 요약
- 대상
- 위험 수준
- 롤백 고려 사항
- 이슈, PR, 문서 링크
그 기록은 notion, airtable, 구글 시트, 저장소 내 markdown 파일, 또는 릴리즈 데이터베이스에 저장될 수 있습니다. 도구의 중요성은 일관성보다 더 중요합니다. 중요한 것은 모든 배포된 항목이 한 곳을 통과하기 전에 alguien이 문장을 쓰기 전에 통과하는 것입니다.
팀이 이것을 잘하면 쓰기는 편집이 됩니다. 그들이 이것을 생략하면 쓰기는 고고학이 됩니다.
사용자가 실제로 읽을 수 있는 쓰기 및 형식화 노트
많은 애플리케이션 릴리즈 노트가 실패하는 이유는 내부 작업의 형태를 보존하는 것입니다. 사용자는 컨트롤러가 리팩토링되거나 마이그레이션 스크립트가 정리된 것을 신경 쓰지 않습니다. 그들은 로그인에 더 신뢰할 수 있게 작동하거나 보고서가 더 쉽게 내보내거나 불편한 버그가 사라진 것을 신경 쓰지 않습니다.
산업 지침은 노트를 카테고리별로 구분하는 것을 권장하고 있습니다. 예를 들어 "새로운", "개선된", "수정된" 등입니다. 그리고 "수정된"이란 "검색 결과가 지금은 로드되었습니다"와 같은 정량화된 결과를 특히 강조합니다. 새로운, 개선된수정된 수정된정량화된 결과 40% 빠른implementation details 보다는 이러한 Appcues에서 제공하는 릴리즈 노트 예시.
사용자가 스캔하고 읽는 순서를 고려한 구조를 사용하세요
대부분의 사용자는 스캔하고 읽는 순서를 반복합니다. 명확한 형식은 마찰을 줄입니다.
실용적인 레이아웃은 다음과 같습니다.
| Element | 내용 |
|---|---|
| Header | 제품 이름, 릴리즈 번호, 날짜 |
| Summary | 변경 사항에 대한 단순한 자연어 문장 |
| 새로운 | 새로 추가된 기능 또는 사용 가능한 워크플로우 |
| 개선된 | 이미 존재하는 기능이 더 잘 작동하는 것 |
| 수정된 | 버그가 해결되거나 문제가 해결된 것 |
| 작업이 필요합니다 | 사용자 또는 관리자가 해야 할 일 |
| 기술 참고서 | 개발자, 관리자 또는 지원을 위한 선택적 참고서 |
포맷이 단어보다 중요합니다. 짧은 섹션, 가시적인 레이블, 날짜가 있는 항목을 사용하여 릴리스 기록을 쉽게 훑어보세요. 릴리스 기록이 여러 릴리스를跨하는 경우 사용자에게 검색 가능한 아카이브를 제공하는 것이 좋습니다. 긴 블로그 피드에서 스크롤을 강요하는 것보다.
기술적인 작업을 사용자 가치로 번역하세요
주요 기술은 번역입니다. 기술적인 진실은 유지되어야 하지만 구현에서 영향으로 언어를_shift해야합니다.
이전과 후의 예시입니다.
이전
검색 인덱스 PIPELINE을 리팩토링하고 비동기 쿼리 핸들러를 최적화했습니다.
후
개선
검색 결과가 로드됩니다. 40% 빠르게 일반 쿼리에서, 이는 큰 데이터 세트를 필터링할 때 기다리는 시간을 줄입니다.
두 번째 버전은 사용자에게 변경된 내용을 알려주고, 그들이 느끼는 곳, 그리고 그들이 관심을 가질 이유를 설명합니다. 기술적인 작업을 숨기지 않습니다. 그들을 해석합니다.
또 다른 예시:
- 약함: Fixed issue with token refresh edge case
- 개선됨: Fixed 로그인 문제를 해결하여 장기 세션 중 일부 사용자가 로그아웃되는 문제를 해결했습니다.
강력한 노트는 일반적으로 한 문장에서 세 가지 일을 합니다.
- visible change를 설명합니다.
- 영향을 받는 워크플로우를 이름 지웁니다.
- 사용자에게 미치는 영향을 설명합니다.
실용적인 템플릿
어떤 재미있는 문장을 쓰지 않아도 됩니다.
품질이 높아지도록 반복적인 단어를 사용하세요. 사용할 수 있는 패턴은 다음과 같습니다.
- 사용자에게 보이는 결과를 시작하세요
- 필요한만큼의 맥락을 추가하세요
- 영향이나 행동으로 마무리하세요
예시:
- 새로운 __CAPGO_KEEP_0__ 워크스페이스 간에 공유 대시보드를 복제할 수 있으므로, 관리자는 보고서 설정을 표준화하는 데 더 쉽게 할 수 있습니다.
- 개선된 세션 간에 설정이 유지되도록 export 설정이 이제 저장되므로, 팀은 동일한 옵션을 다시 선택할 필요가 없습니다.
- 수정된 댓글 쓰레드에 나타나지 않는 일부 이미지 첨부물이 나타나지 않는 문제를 수정했습니다.
모바일 또는 하이브리드 앱을 관리하는 경우, 앱 스토어, 인앱 알림, 내부 문서 등에서 일관된 목소리를 유지하기 위해 릴리스 노트와 변경 로그에 하나의 스타일 가이드를 유지하는 것이 도움이 됩니다. 유용한 운영 참조는 이 Capacitor 변경 로그 관리 가이드.
implementation 세부 사항은 주된 본문에서 제외하는 것이 좋습니다. 그러나 설정, 마이그레이션, 또는 호환성 변경이 있는 경우에는 제외하지 마십시오. 대부분의 사용자는 아키텍처가 필요하지 않습니다. 그들은 결과에 관심이 있습니다.
마지막 규칙. '버그 수정 및 개선'이 독립적으로 서술되는 것을 허용하지 마십시오. 이 문구는 사용자에게 배포된 내용이 중요하지 않음을 알려줍니다. 만약 수정이 중요하다면 명확하게 이름을 지어주십시오.
다양한 채널과 대상자에 대한 릴리스 전략
동일한 릴리스는 모든 채널에서 동일하게 읽히지 않아야 합니다. 내부 개발자, 최종 사용자, 지원 담당자, 베타 테스터는 동일한 세부 정보를 필요로 하지 않습니다. 모든 채널에 동일한 일반적인 메시지를 전달하면 각 대상자는 올바른 정보 수준을 얻지 못합니다.
다중 대상자 제품의 경우, 실용적인 패턴은-layered 형식입니다. 짧은 평문 요약으로 시작하여 사용자에게 친화적인 세부 정보를 제공한 후, implementation 노트, API 또는 마이그레이션 지침, 및 문제 해결에 대한 optional 기술 부록을 추가합니다. 이 접근 방식은 이 ServiceNow 릴리스 노트 최적화 방법에 대한 토론.
하나의 릴리스, 여러 독자
이러한 대상자가 실제로 어떻게 다르다는 것을 설명합니다.
| 대상자 | 필요한 내용 | 피해야 할 내용 |
|---|---|---|
| 최종 사용자 | 명확한 이점, 눈에 띄는 변화, 행동 아이템 | __CAPGO_KEEP_0__ ID, 구현 세부 사항 |
| 기술 전문가 | 버전 정보, 업그레이드, API 참고 사항, 알려진 문제 | 세부 사항이 없는 마케팅 표현 |
| 내부 팀 | 지원 지침, 배포 타이밍, 심각도 | 공개된 단순화, 운영 위험을 숨김 |
| 베타 테스터 | 이 코호트에서 변경된 사항, 필요한 피드백 | 전사 차원의 모든 변경 로그 |
layered 노트를 사용하면 한 번에 작성하고 여러 번 게시할 수 있습니다. 요약은 앱 내 카드 또는 푸시 메시지로 변환됩니다. 중간层는 공개 로그 엔트로 변환됩니다. 부록은 문서, GitHub 릴리스 또는 내부 위키에 포함될 수 있습니다.
업무에 적합한 채널을 선택하세요
속도에 더 집중하는 채널과 세부 사항에 더 집중하는 채널이 있습니다.
- 인앱 알림: 사용자가 변화에 직면할 때 짧은 요약과 관련된 좋은 곳입니다.
- 변경 로그 페이지 또는 블로그 게시물: 지속적인 기록, 검색, 및 연결에 더 적합합니다.
- 이메일 요약: 관리자, 챔피언, 및 일일 로그인하지 않는 고객을 위한 유용한 곳입니다.
- 내부 채팅 또는 위키: 지원 스크립트, 롤아웃 상태, 및 사고 맥락에 가장 적합합니다.
- 개발자 문서 또는 GitHub 릴리스: API, SDK, 또는 마이그레이션 세부 정보에 가장 적합한 곳입니다.
The mistake is copying the full note into every destination. Tailor the top layer to the channel, then link readers to the deeper layer if they want more.
만약 팀이 이미 여러 시스템에서 문서 및 릴리스 자산을 관리한다면, 그 아이템이 초안에서 발행된 상태로 이동하는 방식을 표준화하는 것이 도움이 됩니다. MeshBase의 콘텐츠 발행을 관리하는 broader 워크플로에 대한 실용적인 참고 자료는 특히 릴리스 노트가 문서, 업데이트 및 지식베이스 콘텐츠와 함께 있는 경우에 특히 유용합니다.앱을 열어보는 사용자는 안심하고 관련성이 있는 것을 원합니다. 릴리스 역사 읽는 개발자는 정확성을 원하고, 지원 담당자는 두 가지를 원합니다.
효과적인 릴리스 노트 프로그램은 발행을 배포 디자인으로, 복사-붙여넣기 대신 다루는 것입니다. 동일한 릴리스. 다른 패키징.
CI/CD 및 현대 도구를 사용한 릴리스 노트 자동화
주기적으로 릴리스하는 경우 수동 릴리스 노트는 붕괴됩니다. 초안이 빌드 뒤쳐지며, 누군가가 수정을 포함하지 않아 발행된 노트가 더 이상 실시간과 일치하지 않습니다.
자동화는 반복적인 부분을 해결합니다. 판단을 대체하지는 않습니다.
__CAPGO_KEEP_0__ 커밋부터 최종 발행까지의 자동화 릴리스 노트 워크플로를 minh họa하는 여섯 단계 다이어그램입니다.
최고의 분리는 간단합니다.
__CAPGO_KEEP_0__
자동화:
- 변경 추출 커밋, 병합된 풀 요청, 레이블 및 연결된 이슈에서
- 릴리스 노트 템플릿에 조립 버전 및 날짜 삽입
- 변경 로그 페이지, __CAPGO_KEEP_0__ 릴리스 또는 CMS로 게시 단계
- 승인 후 내부 팀에 알림 to a changelog page, GitHub release, or CMS
- 우선 순위 및 순서 prioritization and ordering
for human review
- for internal teams
- 사용자 대면 문구
- 보호된 변경
- 파괴 또는 롤백 언어
- 성능, 호환성 또는 필수 작업에 대한 모든 주장
분할이 게시되지 않은 로봇 노트를 생략하여 시간을 절약합니다. pipeline은 사실을 수집합니다. 리뷰어는 그들을 유용하게 만듭니다.
작동하는 pipeline
GitHub Actions, GitLab CI, 또는 다른 CI/CD 시스템에서 일반적으로 다음과 같은 실용적인 자동화 흐름이 보입니다:
- 릴리스 태그 또는 릴리스 branch로 병합이 트리거를 일으킵니다.
- 스크립트는 병합된 PR 제목, 커밋 메시지 및 링크된 이슈 메타데이터를 가져옵니다.
- pipeline은 기능, 수정, 및 파괴 변경과 같은 레이블로 항목을 그룹화합니다.
- 그것은 표준 형식의 섹션을 포함하는 마크다운 드래프트를 생성합니다.
- 리뷰어는 요약과 고위험 항목을 편집합니다.
- 출판은 노트를 공개하고 릴리스 아티팩트에 첨부합니다.
이것을 사용하여 커스텀 스크립트, 플랫폼 내의 릴리스 도구, 또는 전용 도우미를 사용하여 빌드할 수 있습니다. 릴리스 도구 layer에 대한 아이디어를 찾고 싶다면, Releasebot과 같은 혁신적인 도구를 탐색하는 커뮤니티를 살펴보는 것이 가치가 있습니다. 특히 드래프트 생성 후 수동 청소가 줄어들 수 있는 팀을 위한 것입니다.__CAPGO_KEEP_0__ 앱을 운영하는 팀은 노트 생성을 배포 PIPELINE 및 승인 흐름에 통합할 수 있습니다. 이 __CAPGO_KEEP_0__ Actions 통합 가이드는 __CAPGO_KEEP_1__에서 빌드 자동화와 라이브 업데이트 전달을 연결하는 방법을 보여줍니다.
A team running Capacitor apps can also wire note generation into its deployment pipeline and approval flow. This GitHub Actions integration guide for Capgo 라이브 업데이트 환경은 전통적인 스토어 기반 릴리스와 다릅니다. 사용자는 스토어 릴리스 주기 외에 자바스크립트, CSS, 복사본, 구성, 또는 자산 변경을 받을 수 있습니다.
이것은 릴리스 노트 프로세스가 두 개의 별개의 질문을 답변해야 하는 것을 의미합니다.
버전이 앱 리뷰를 통과한 것을 포함한 바이너리 릴리스에서 무엇이 배포되었는지?
이것은 릴리스 노트 프로세스가 두 개의 별개의 질문을 답변해야 하는 것을 의미합니다.
버전이 앱 리뷰를 통과한 것을 포함한 바이너리 릴리스에서 무엇이 배포되었는지?
- 버전이 앱 리뷰를 통과한 것을 포함한 바이너리 릴리스에서 무엇이 배포되었는지?
- __CAPGO_KEEP_0__
If you support over-the-air delivery, keep a visible distinction between binary notes and post-release update notes. Otherwise support teams won’t know which changes are tied to a store version and which arrived later. One option in that space is Capgo, which publishes signed web bundles for Capacitor apps and keeps version history, logs, and rollback data tied to update delivery.
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
Enterprise-Grade Notes for Rollbacks and Compliance
Enterprise release notes는 공공 업데이트 이외에도 더 많은 무게를 지니며, 감사 자료, 지원 증거, 사고 참조, 운영 제어 증거로 사용될 수 있습니다.
__CAPGO_KEEP_1__
__CAPGO_KEEP_0__
그것은 모든 사용자에게 모든 것을 표시하는 것은 아니다. 그것은 버전별로 기록된 레코드에 여러 단계의 세부 정보를 저장하는 것을 의미한다. 공개 요약이 위에 있고 내부 증거가 아래에 있다.
규제 부문에 속하는 팀의 경우 유용한 기준은 다음과 같다:
- 변경되지 않는 릴리스 기록
- 이름이 지정된 소유자 및 승인자
- 연결된 구현 레코드
- 배송, 롤백, 또는 대체된 릴리스에 대한 명확한 상태
- 급한 사정이나 긴급한 변경에 대한 별도의 처리
롤백 노트는 임의로 만들어지지 않도록 해야 한다. 롤백 노트는 첫 번째 등급의 릴리스 아티팩트여야 한다.
단순한 구조를 사용하라:
Field
| Example content | __CAPGO_KEEP_0__ |
|---|---|
| 되돌린 릴리스 | 버전 또는 업데이트 식별자 |
| 이유 | 사용자에게 보이는 문제, 안정성 문제, 호환성 문제 |
| 범위 | 누구에게 영향을 받았는지 |
| 작업 | 팀이 무엇을 했는지 |
| 현재 상태 | 되돌린, 중단, 재배포, 모니터링 |
| 사용자 지침 | 사용자나 관리자가 무엇을 해야 하는지 |
A rollback note는 정보가 없는 사과문처럼 읽히지 않아야 합니다. 운영 상태를 명확하게 설명하고 변경이 취소된 사실을 숨기지 않아야 합니다. 앱이 실시간 업데이트 지원한다면, 롤백 제어는 릴리스 역사와 배포 채널과 밀접하게 연결되어야 합니다. 이 맥락에서, 롤백을 위한 문서화된 프로세스는 릴리스 커뮤니케이션의 일부가 아니라 단순한 사고 대응만이 아닙니다. 가장 나쁜 롤백 노트는 거의 아무것도 말하지 않습니다. 두 번째로 나쁜 것은 롤백이 발생하지 않았다는 것을 암시합니다. 노트가 행동을 변경했는지 측정하세요. 많은 팀이 아직 해결하지 못한 문제가 하나 있습니다. 릴리스 노트를 발행하지만, 그들이 노트에 반응했는지 보여주지 못합니다. 제품 분석 벤더는 릴리스 노트 페이지가 종종 수동적인 발표 채널로 작용하는 반면, 팀은 그들을 수용, 지원 방지, 또는 기능 발견과 연결하는 데 어려움을 겪고 있습니다. 이에 대한 예는 CalHEERS 릴리스 노트 문서입니다. 이 간격은 기업 환경에서 더 중요합니다. 릴리스 커뮤니케이션은 노트가 노트를 발행하는 데 드는 노력을 정당화해야 합니다. 실질적인 접근 방법은 발행 전에 정의하는 작은 신호 세트입니다. 기능 발견: 사용자가 노트가 게시된 후 변경된 워크플로를 열거나 사용했는지 여부를 측정합니다. Capacitor 업데이트에 대한 롤백 구성 방법을 문서화하는 프로세스가 릴리스 커뮤니케이션의 일부가 아니라 단순한 사고 대응만이 아닙니다. __CAPGO_KEEP_0__ 업데이트에 대한 롤백 구성 방법을 문서화하는 프로세스가 릴리스 커뮤니케이션의 일부가 아니라 단순한 사고 대응만이 아닙니다.
롤백 노트가 거의 아무것도 말하지 않는다면, 그것은 나쁩니다. 롤백 노트가 롤백이 발생하지 않았다는 것을 암시한다면, 그것은 두 번째로 나쁩니다.
노트가 행동을 변경했는지 측정하세요.
릴리스 노트를 발행하지만, 그들이 노트에 반응했는지 보여주지 못합니다.
릴리스 노트 페이지가 종종 수동적인 발표 채널로 작용하는 반면, 팀은 그들을 수용, 지원 방지, 또는 기능 발견과 연결하는 데 어려움을 겪고 있습니다. 이에 대한 예는 CalHEERS 릴리스 노트 문서입니다. 기업 환경에서 릴리스 커뮤니케이션은 노트가 노트를 발행하는 데 드는 노력을 정당화해야 합니다.실질적인 접근 방법은 발행 전에 정의하는 작은 신호 세트입니다.
기능 발견: 사용자가 노트가 게시된 후 변경된 워크플로를 열거나 사용했는지 여부를 측정합니다.
- 릴리스 노트를 발행하지만, 그들이 노트에 반응했는지 보여주지 못합니다. 릴리스 노트 페이지가 종종 수동적인 발표 채널로 작용하는 반면, 팀은 그들을 수용, 지원 방지, 또는 기능 발견과 연결하는 데 어려움을 겪고 있습니다. 이에 대한 예는 CalHEERS 릴리스 노트 문서입니다.
- 지원 영향: 영향받은 이슈에 대한 질문이 감소했나요?
- 관리자 행동: 대상 계정에서 요청된 작업을 완료했나요?
- 사고 명확성: 롤백 또는 단계적 배포 중, 지원이 노트를 참조 지점으로 사용했나요?
완벽한 Attribution을 얻지 못할 것입니다. 그게 괜찮습니다. 목표는 릴리스 노트를 정적 문서로 다루지 않고, 운영적 레버로 다루기 시작하는 것입니다.
팀이 Capacitor 앱에 자주 업데이트를 배포한다면 Capgo 배포, 버전 기록, 롤백 제어 및 릴리스 커뮤니케이션을 같은 워크플로우에서 연결하는 방법입니다. 특히 스토어 릴리스와 라이브 업데이트에 별도의 가시성을 필요로 할 때.
