이 페이지의 도구 중 하나는 저희가 만듭니다. 다른 것들은 어디가 부족한지가 아니라 무엇을 위해 만들어졌는지로 설명하려 했으며, 저희 자체 제품에 대한 섹션은 누가 그것을 사용하면 안 되는지 명확히 말합니다.
세 가지 카테고리
호스팅된 위젯과 페이지
항목을 그들의 에디터에서 작성하고, 그들이 페이지를 호스팅하며 앱 내 위젯을 제공합니다. 가장 빠르게 시작할 수 있으며, 항목은 여러분이 아닌 그들의 인프라에 존재합니다. Beamer와 AnnounceKit이 가장 명확한 예입니다.
changelog가 붙은 피드백 스위트
changelog는 기능 투표, 공개 roadmap, 피드백 받은편지함 옆의 하나의 모듈입니다. 하나의 벤더로부터 전체 루프를 원한다면 가치가 있지만, 릴리스 노트만 게시하고 싶다면 과합니다. Canny, Frill, Featurebase가 여기 속합니다.
저장소에서 생성됨
changelog는 손으로 입력하는 대신 커밋, 풀 리퀘스트, issue에서 생성됩니다. CI에서 구축되는 파일부터 작성·검토·게시되는 항목까지 범위가 있습니다. git-cliff와 github-changelog-generator는 파일 쪽 끝에, LaunchNotes, Released, 저희 자체 제품은 게시 쪽 끝에 있습니다.
한눈에 보기
| 도구 | 종류 | 가장 적합한 대상 |
|---|---|---|
| Beamer | 호스팅된 위젯 | 개발 시간 없이 앱 내 새 소식 패널을 오늘 오후에 바로 띄우고 싶은 팀. |
| AnnounceKit | 호스팅된 위젯 | 위와 같지만, 누가 어떤 공지를 보는지 세분화하는 데 더 신경 쓰는 경우. |
| Canny | 피드백 스위트 | 기능 투표와 공개 roadmap을 원하고, changelog를 그 루프의 마지막 단계로 쓰려는 팀. |
| Frill | 피드백 스위트 | Canny와 같은 구성을 더 가볍게 원하는 소규모 팀. |
| LaunchNotes | 저장소에서 생성 | 여러 팀에 걸친 공지를 조율하는 대규모 조직. 대개 Jira를 중심으로 합니다. |
| Released | 저장소에서 생성 | Jira에서 일하며, Jira를 벗어나지 않고 issue로부터 changelog를 만들고 싶은 팀. |
| git-cliff | 파일 생성기 | 호스팅되는 것 없이 CI에서 conventional commits로 CHANGELOG.md를 만들고 싶은 오픈소스 프로젝트. |
| Changeloop | 저장소에서 생성 | 병합된 풀 리퀘스트로 항목 초안을 작성하고, JSON 피드를 받아 자체 프런트엔드에서 렌더링하고 싶은 팀. |
선택하는 방법
- changelog가 어디에 나타나야 하는지부터 시작하세요. 여러분 제품의 일부처럼 보여야 한다면, 링크를 거는 호스팅된 페이지는 에디터가 아무리 좋아도 실망시킬 것이며, 재스타일링할 수 있는 위젯이나 직접 렌더링하는 피드가 필요합니다. 링크된 페이지로 충분하다면 호스팅된 도구가 훨씬 적은 작업으로 됩니다.
- 다음으로 누가 항목을 작성하는지 물어보세요. 답이 '병합한 엔지니어'라면 여러분의 저장소를 읽는 것을 선택하세요. 다른 무엇이든 모두가 바쁜 바로 그 순간에 수동 단계를 추가하기 때문입니다. 답이 릴리스 계획에 따라 작업하는 제품 마케터라면 에디터가 더 적합하며 저장소 자동화는 방해만 될 것입니다.
- 다음으로 나머지 루프가 필요한지 물어보세요. 기능 투표와 공개 roadmap은 정말로 유용하지만 정말로 더 큰 약속입니다. changelog 모듈을 위해 스위트를 구매하는 것은 팀이 하나를 사용하기 위해 네 가지에 돈을 지불하게 되는 방식입니다.
- 마지막으로, 떠날 경우 여러분의 항목이 어떻게 되는지 확인하세요. 구조화된 데이터로 내보내는 도구는 여러분이 스크래핑해야 하는 호스팅된 페이지에 그것들이 존재하는 도구와 실질적으로 다릅니다.
저희 자체 도구가 맞는 곳, 맞지 않는 곳
Changeloop는 병합된 각 풀 리퀘스트를 읽고, 사용자 지향 항목을 작성하며, 의존성 업데이트와 리팩터링을 필터링하고, 검토를 위해 초안을 보관합니다. 게시되는 것은 옆에 roadmap 피드가 있는 공개 JSON 피드로 가며, 추가로 두 줄짜리 위젯과 호스팅된 페이지가 대체 수단으로 제공됩니다. 피드가 핵심입니다: 의도된 구성은 여러분 자신의 제품 안에서 여러분 자신의 컴포넌트로 changelog를 렌더링하는 것입니다.
다음의 경우 선택하지 마세요:
- 여러분의 릴리스가 저장소에서 나오지 않는 경우. 병합에서, 또는 푸시 모드에서는 푸시에서 초안을 작성하므로, Git 워크플로 밖에서 배포하는 팀은 검토할 것이 아무것도 없습니다.
- 기능 투표와 사용자가 투표하는 roadmap을 원하는 경우. roadmap 피드는 있지만 사용자 투표가 아니라 라벨이 붙은 issue로 움직입니다. 그것에는 피드백 스위트가 올바른 카테고리입니다.
- 세련된 에디터와 메인 제품으로서의 호스팅된 페이지를 원하는 경우. 호스팅된 페이지는 대체 수단으로 존재하며, 자체 페이지를 중심으로 구축된 도구가 그것을 더 잘할 것입니다.
- 저장소에 CHANGELOG.md만 있으면 되는 단독 오픈소스 프로젝트인 경우. 무료이며 정확히 그것을 위해 만들어진 git-cliff를 사용하세요.
자주 묻는 질문
애초에 도구가 필요한가요?
한동안은 아닙니다. markdown 파일이나 자체 사이트의 페이지도 충분히 좋은 changelog이며 비용이 전혀 들지 않습니다. 도구가 값을 하기 시작하는 시점은 항목 작성이 생략되는 단계가 될 때, 또는 세 곳에서 동일한 항목을 원하지만 세 개의 사본을 유지하고 싶지 않을 때입니다.
나중에 이 중 하나에서 이동할 수 있나요?
항목이 구조화된 데이터로 다시 나오는지에 전적으로 달려 있습니다. 시작하기 전에 물어보세요, 나중이 아니라: 이것이 목록에서 잘못 답하면 비용이 큰 유일한 질문입니다. changelog는 계속 성장하는 아카이브이며, 2년치 내용을 다시 입력하는 것은 누구도 승인할 프로젝트가 아니기 때문입니다.
AI 어시스턴트로 작성하는 것은 어떤가요?
이들 대부분은 이제 어딘가에서 모델로 작성합니다. 모델이 무엇을 받는지가 훨씬 더 중요합니다. 커밋 제목만 보는 도구는 그 제목만 다시 쓸 수 있습니다. 풀 리퀘스트의 제목과 설명을 보는 도구는 사용자에게 그것이 무엇을 하는지의 관점에서 변경 사항을 설명할 만큼 충분히 가지고 있습니다. AI가 있는지가 아니라 입력이 무엇인지 물어보세요.
더 읽어보기: changelog 자동화와 그 한계, 네 단계 중 어느 것이 자동화되어야 하는지에 대해.
피드를 최우선으로 하는 것
여러분이 병합한 풀 리퀘스트에서 작성되고, 검토를 위해 보관되며, 직접 렌더링하는 JSON 피드에 게시됩니다. 저장소 1개까지 무료, 카드 필요 없음.
무료로 시작하기