릴리스 관리 - 모범 사례

Question

저는 제품 개발 회사에서 일합니다. 먼저 내부 릴리즈를 수행 한 다음 공개 릴리스를 수행했습니다. 다른 제품 개발 회사가 어떻게 제품 릴리스를 관리하는지 궁금합니다. 발매 번호는 어떻게 알 수 있습니까? 소스 컨트롤에 태그를 지정 하시겠습니까?

Answer 1

우리는 SubVersion을 사용합니다. SubVersion은 태그와 브랜치를 만드는 것이 저렴합니다.

지금까지 출시, 우리는이 규칙에 따라 이동로 :

(주요 릴리스) (부 릴리스) (패치 릴리스) (SVN 개정)

• 패치 출시 = 버그 수정
을...
• 부 릴리스 = 이진 호환/ 인터페이스 호환
• 주 릴리스 = 변경 내용이 포함되어 있습니다. 변경.

의미가 있습니까? 더 많은 정보가 필요하면 의견을 추가하고 내 게시물을 수정하여 명확하게합니다.

Answer 2

내 회사에서 출시가 준비되면 R_2_1과 같은 부/부 릴리스 번호에 대한 지점을 만듭니다. 초기 릴리즈는 R_2_1_0이라고하는 즉시 스냅 샷 분기 또는 레이블을 만들어 수행합니다. 릴리스에 대해 QA 파일 버그가 발생하면 R_X_Y 분기에서 코드가 변경된 다음 해당 릴리스를 표시하기 위해 R_2_1_1 분기가 만들어집니다. 그래서 나무는 다음과 같습니다

Mainline 
| 
|- R_2_1 
| | 
| |-R_2_1_0 (locked) 
| | 
| | 
| |-R_2_1_1 (locked) 
| | 
. . 
. . 
. . 

Answer 3

나는 고객이 자신의 callcenters 및 웹 사이트를 구현하고자하지 않았다는 것을 결정했을 때 결국 솔루션 제공 업체로 변신 사용자 정의 소프트웨어 공급 업체 일했다.

이러한 환경에서 각 주요 고객은 시스템 작동 방식의 일부 측면을 사용자 정의 할 수있는 기회를 가졌습니다. 따라서 개발에는 모든 계약서에 공통된 구성 요소가있는 핵심 제품과 각 고객별로 별도의 지점이 있습니다 (일부 고객은 사소한 수정이 필요하고 다른 일부는 다른 시스템과의 통합이 필요했습니다).

비즈니스가 성장하고 지점 수가 확장되어 실제로 종종 절름발 한 변화를 수용 할 때까지 제대로 작동했습니다. 한 번은 같은 코드베이스의 15 가지 활성 버전과 같은 것을 가지고 있다고 생각합니다 ... 어떤 것들은 정말 융통성이없고 지원하기가 어려웠습니다.

우리가 한 일을하지 마십시오. 출시 규모를 확장하십시오!

Answer 4

우리는 SVN을 사용하고 각 릴리스마다 두 개의 분기를 만듭니다. 하나는이 릴리스를 빌드하는 데 사용 된 소스 코드의 태그이고, 하나는 실제 릴리스 된 바이너리의 새 가져 오기입니다. X 6 개월 동안 빌드를 다시 생성하려고 할 때 필연적으로 (필연적으로 두 개발자의 기계를 같게 만들거나 안정된 빌드 기계를 유지하려고 시도해도) 중요합니다. 결과가 바이너리와 미묘하게 다릅니다.

마이너 패치는 릴리스 소스 분기에서 복사 된 분기에서 만들어지고 트렁크에 병합됩니다. 릴리스 소스 브랜치를 새 브랜치에 복사하고 필요한 패치가 있으면 병합하여 마이너 릴리스를 쉽게 만들 수 있습니다.

주요 작업은 트렁크에서 복사 된 분기에서 수행되고 완료되면 트렁크로 병합됩니다. 그런 다음 트렁크에서 주요 릴리스를 만들 수 있습니다.

Answer 5

ITIL 프레임 워크에 기반한 대답 (다른 질문과 다소 비슷 함).

ITIL은 주요 소프트웨어 릴리스, 부 소프트웨어 릴리스 및 응급 소프트웨어 수정과 같은 세 그룹의 릴리스를 분류합니다. ITIL 책에서

:

일반적으로 중복 문제로 수정을 중재 할 수있는 몇 가지있는 새로운 기능의 넓은 지역을 포함, 소프트웨어 릴리즈 및 하드웨어 업그레이드 주요 •. 주요 업그레이드 또는 릴리스는 일반적으로 이전의 모든 부 업그레이드, 릴리스 및 응급 수정보다 우선합니다.
• 사소한 소프트웨어 릴리스 및 하드웨어 업그레이드. 보통 약간의 개선 및 수정이 포함되어 있으며 일부는 이미 응급 수정으로 발급되었을 수 있습니다. 사소한 업그레이드 또는 릴리스는 일반적으로 이전의 모든 긴급 수정보다 우선합니다. 비상 소프트웨어 및 하드웨어 수정 •
, 일반적으로 이것은 당신이해야 다음, 그래서 문제

알려진 소수에 수정을 포함 :

전공 : V1, V2, V3 등
마이너 : V1 .1, V2.1 등
응급 : v1.1.1, V2.1.1 등

Answer 6

다른 말처럼, realeases를 관리하는 가장 좋은 방법은 분기하는 것입니다. 프로젝트 크기와 최종 사용자에게 소프트웨어를 제공하는 다양한 방법 (주요 릴리스, 서비스 팩, 핫픽스)에 따라 지점 구조를 만드는 여러 가지 방법을 설명하는 TFS 분기 가이드 (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785)를 살펴 보는 것이 좋습니다.). TFS에만 국한된 것은 아니므로 대부분의 다른 소스 제어 시스템에 적용 할 수 있습니다.

Answer 7

I created a similar question이 항목에 추가하고 싶습니다. 릴리스주기를 관리하려면 Jira과 같은 것을 사용하는 것이 좋습니다. 커밋을 요청/문제/버그와 연관시킨 다음 릴리스의 일부로 플래그를 지정할 수 있습니다.

특히 좋은 릴리스주기를 관리하는 방법을 알고 싶다면이라는 과학에 이르기까지 Apache 기초가 어떻게 작동하는지 살펴보아야합니다. 예를 들어 roadmap for releases in the Mahout project입니다.

문제를 추적하고 릴리스 패키지에 번들로 제공하는 작업 시스템과 함께,이 사이클을 빌드주기가되도록 연속 통합 (CruiseControl과 Hudson을 모두 사용함) 및 단위 테스트와 통합하는 것이 좋습니다. 다른 모든 것들과 함께 관리됩니다.

Answer 8

TFS에 대한 공동 고양이의 답변에 대한 후속 조치. 새로운 VS2010에 대한 몇 가지 업데이트 URL과 VS11

http://vsarbranchingguide.codeplex.com/releases