-
자주 배포하는 팀을 위한 릴리스 관리 프로세스
소프트웨어 팀을 위한 릴리스 관리 프로세스를 범위 계획부터 회고까지 일곱 단계로 나누고, 단계마다 담당자와 완료 기준을 정했다. DORA 지표도 소개한다.
엔지니어링6분 분량
-
체인지로그는 누가 쓰는가, 그리고 누가 써야 하는가
체인지로그는 누가 쓰는가? PR 작성자는 무엇이 바뀌었는지 알고 PM은 왜 중요한지 안다. 어느 쪽도 혼자서는 쓸모 있는 항목을 쓸 수 없다.
엔지니어링4분 분량
-
체인지로그 파일 형식, JSON인가 YAML인가 그냥 Markdown인가
체인지로그 파일의 형식은 페이지와 위젯을 공급할 수 있는지 사람만 읽는지를 정한다. Markdown, JSON, YAML이 각각 치르는 대가를 비교한다.
엔지니어링4분 분량
-
GitHub Actions용 체인지로그 체크
GitHub Actions 체인지로그 체크는 항목 없는 머지를 막는다. 기억에 의존하면 일정 앞에서 실패하는 이유와 체크 자체가 깨뜨리는 것을 다룬다.
엔지니어링4분 분량
-
Git 태그, 릴리스, 그리고 당신의 체인지로그
Git 태그, 릴리스, 체인지로그 항목은 하나의 사건에 대한 세 가지 기록이다. 이를 혼동하면 체인지로그가 실제 릴리스에서 벗어난다. 맞추는 법을 설명한다.
엔지니어링4분 분량
-
모노레포 체인지로그: 하나로 합칠까, 패키지마다 따로 둘까
모노레포는 저장소 전체를 위한 체인지로그 하나나 패키지마다 하나를 둘 수 있다. 잘못 고르면 릴리스가 너무 시끄럽거나 흩어진다. 기준은 구조가 아니라 독자다.
엔지니어링4분 분량
-
시맨틱 버저닝과 당신의 체인지로그, 함께 보기
시맨틱 버저닝은 호출자가 체인지로그 항목을 읽기 전에 릴리스가 얼마나 아플지 알려준다. 각 숫자가 약속하는 것과 항목이 그에 대해 져야 할 책임을 설명한다.
엔지니어링4분 분량
-
사람들이 계속 찾아오는 체인지로그 페이지 만드는 법
체인지로그 페이지는 사람들이 다시 돌아올 때 가치가 있다. 어디에 둘지, 항목에 무엇이 필요한지, 피드와 마크업, 위젯과의 관계를 설명한다.
엔지니어링5분 분량
-
체인지로그 자동화, 그리고 그 한계에 대하여
수집, 포맷팅, 발행은 자동화해도 좋지만 무엇을 선별하고 어떻게 쓸지는 자동화해선 안 된다. 그 경계선이 어디인지, 옮겨지면 어떻게 되는지 살펴본다.
엔지니어링5분 분량
-
Conventional commits에서 체인지로그로
Conventional commits는 체인지로그를 도출 가능하게 하지만 읽기 쉽게 만들지는 못한다. 이 관례가 사주는 것과 한계, 그 간극을 메우는 법을 살펴본다.
엔지니어링4분 분량
-
Keep a Changelog, 실제로 적용해 보니
Keep a Changelog 명세는 한 페이지이고 읽는 데 십 분도 걸리지 않지만, 구현하면서 대부분의 팀이 어긋난다. 명세가 말하는 것과 열어둔 것, 틀린 곳을 살펴본다.
엔지니어링4분 분량
