애자일의 시맨틱 버전 관리

새로운 기능에 대한 몇 가지 이야기, 개선 사항 및 수정해야 할 버그가있는 14 일 스프린트 반복이 있다고 가정 해 봅시다. 또한 준비가되면 변경 사항을 배포합니다. 스프린트 종료를 기다리지 않습니다.

내 문제는-이와 같이 개발되고 유지 관리되는 제품의 의미 버전 관리를 추적하는 방법은 무엇입니까? 14 일마다 릴리스 할 경우 쉬울 것입니다. 버전 번호를 늘리고 변경 로그의 모든 변경 사항을 기록합니다. 그러나 변경 사항이 지속적으로 배포되면 어떻게됩니까? 무언가를 배포 할 때마다 버전이 증가해야합니까? 또는 스프린트가 끝날 때까지 기다린 후이 후 "재개"를하고 실제 배포에서 독립적으로 반복 당 한 번만 버전 번호를 늘려야합니까? Agile의 시맨틱 버전 관리에 대한 모범 사례는 무엇입니까?

편집 : 내 요구를 더 잘 설명하기 위해 먼저 이해 관계자에 대한 변경 로그를 원합니다. 나는 모든 변경 사항이 배포 된 후에 변경 로그의 새로운 기록에 관심이 있다고 생각하지 않습니다.

일반적인 릴리스 관리의 경우 빌드 시스템에서 빌드 번호를 생성하여 DLL이 배포 될 때마다 버전이 지정되도록해야합니다. 그러면 나중에 특정 서버에 배포 된 버전을 확인할 수 있습니다.

일반적으로 출시 노트에 포함되거나 사이트에 게시 된 '마케팅'버전은 각 버전을 업데이트하지 않아야합니다. 이 릴리스 노트는 스프린트 종료 시점에 맞춰 누적되고 그룹화되어야합니다.

클래식 의미 체계 버전 지정 체계 "MAJOR.MINOR.PATCH"가 의미가있는 경우 배포 대상, 특히 최종 사용자 에게 배포하는시기 및 빈도에 따라 다릅니다 . 이 구성표는 4.5.0으로 시작하는 안정 릴리스 "4.5"로 작업 할 때 가장 유용합니다. 버전 4.5.1, 4.5.2 등에는 버그 수정 만 포함되어 있으며 내부적으로 이미 버전 4.6에서 작업하고 있습니다.

예를 들어, 최종 사용자에게 "안정적인 브랜치"를 제공하는 경우 초기 배포에는 버전 4.5.0, 패치를 릴리스 할 때마다 4.5.1, 4.5.2를 제공하십시오. 내부 "민첩한"개발 및 스프린트 중간 배포에서는 이미 버전 4.6을 가질 수 있으며 "베타 버전"이라고합니다. 스프린트 중간에 배포 할 때마다 "4.6.beta build 123"과 같은 자동 생성 빌드 번호를 추가하십시오. 스프린트가 끝나면 "4.6.0"을 할당하고 다음 스프린트의 버전 번호를 내부적으로 "4.7"로 전환하십시오. ".0"으로 시작하는 것은 규칙 일뿐 아니라 ".0"을 사용하여 베타 버전에 태그를 지정하고 최종 사용자의 경우 ".1"로 시작할 수도 있습니다. IMHO "베타"라는 단어는 훨씬 더 표현력이 뛰어나며, 스프린트가 "아직 완료되지 않았다"고 말합니다.

각 베타 버전으로 전체 최종 사용자 변경 로그를 릴리스하지만 적어도 스프린트 끝에서 변경 로그를 완료해야하며 최종 사용자에게 버그 수정을 제공 할 때마다 업데이트해야합니다. 역사 문서.

Inkscape, Firefox 또는 7-zip과 같은 많은 오픈 소스 제품에서 두 개의 분리 된 분기, 의미 버전 번호가있는 "안정된"분기 및 빌드 번호 또는 이와 유사한 것으로 표시된 "개발 분기"를 릴리스하는 전략을 찾을 수 있습니다.

그러나 별도의 안정적인 분기 및 개발 분기로 작업하지 않고 매일 최종 사용자에게 새 버전을 릴리스하는 경우 매일 버전 번호를 늘려야합니다. 이러한 경우 버전 번호 "4.5.1", "4.5.2"는 ... 개별 배포를 반영하고 버그 수정과 다른 변경의 차이를 나타내지 않습니다. 괜찮을 수도 있습니다. 더 이상 고전적인 "의미 적 버전 관리"가 아닙니다. 이 시나리오에서는 실제 차이가없는 버전 4.5, 4.6, 4.7, 4.8을 배포 할 수도 있습니다.

변경 로그의 항목에 대한 질문 : IMHO 최종 사용자에게 표시되는 항목은 변경 사항을 배포하자마자 변경 로그의 항목에 해당합니다. 예를 들어, 기능 토글을 사용하고 아직 사용자에게 활성화되지 않은 일부 구운 기능을 변경하면 해당 기능이 변경 로그에 속하지 않습니다. 사용자가 눈에 띄게 변경하지 않고 리팩토링 만 수행하는 경우 변경 로그에 속하지 않습니다. 일부 사용자에게 영향을 줄 수있는 버그를 수정하면 변경 로그에 해당 버그가 있으며 버그 수정을 배포 할 때 동시에 언급해야합니다. 매일 또는 매월 또는 매년 릴리스해도 문제가되지 않습니다.

빌드 번호를 사용합니다. 일반적으로 빌드 번호는 버전 제어 시스템의 최고 버전에 해당합니다. 월요일 빌드 번호가 1745이고 화요일 동안 5 개의 변경 사항이 확인 된 경우 화요일 저녁 빌드 번호는 1750입니다.

그런 다음 1745와 1750 사이에 변경된 사항에 대해 간단히 요약하십시오.

그런 다음 시스템의 버전 ​​번호를 업데이트 할 때마다 빌드에서 모든 짧은 요약을 추가하여 마지막 버전 번호에서 새로운 버전으로 변경 사항을 가져올 수 있습니다.

내가 적어도 몇 년 동안 사용해온 내가 선호하는 방법은 각 이야기가 완료된 후 숫자를 늘리는 것입니다. 이는 스프린트 종료시 릴리스 된 버전이 연속적이지 않음을 의미합니다 (예 : 1.2.3 이후 1.4.0이 아닌 1.5.2를 찾을 수 있음).

변경 로그에서 중간 버전을 해당 설명과 함께 나열하거나 모든 변경 사항을 "릴리스 된"버전으로 그룹화하고 그 사이의 버전을 건너 뛸 수 있습니다.

처음에는 사용자가 버전 번호 사이의 "구멍"에 문제가 있음을 알았지 만 일단 알고 있으면 실제로 문제가되지 않습니다. 가장 큰 장점은 각 스토리 후에 숫자를 늘리면 프로세스가 오류를 덜 발생 시킨다는 것입니다. 다음 버전 번호를 결정하기 위해 2 주에서 전체 작업을 확인할 필요가 없습니다. 단일 스토리를 볼 때 분명합니다. . 또한 각 릴리스 간 버전 번호의 "도약"은 릴리스에 변경된 변경 수에 대한 대략적인 추정치를 제공합니다. 대체로이 시스템이 잘 작동한다는 것을 알았습니다 (이것은 회사 내부 고객과 관련이 있었지만 이미 민첩한 릴리스 주기로 작업하는 경우 외부 고객에게도 적용됩니다).