发布管理-最佳实践

我们使用SubVersion,其中标签和分支的创建成本很低。

就发行版而言,我们遵循以下惯例:

(主要版本)。(次要版本)。(补丁版本)。(SVN修订版)

• 补丁发布=错误修复
• 次要版本=二进制兼容/ 接口兼容
• 变化。

I created a similar question ,但我想补充一点:我强烈建议使用 Jira 管理发布周期。您可以将提交与请求/问题/错误相关联,然后将其标记为发布的一部分。

特别地, 如果你想知道如何管理一个好的发布周期,看看Apache基金会是怎么做的,因为他们已经把它归结为一门科学。 . 例如,这里是 roadmap for releases in the Mahout project .

除了一个跟踪问题并将其捆绑在一个发布包中的工作系统之外,您还需要开始将其与您的持续集成(我使用了CruiseControl和Hudson)和单元测试集成,以便您的构建周期与其他所有东西一起管理。

我为一家定制软件提供商工作,当客户决定不想实现自己的呼叫中心和网站时,它最终演变成了解决方案提供商。

在这种环境下,每个主要客户都有机会定制系统工作方式的某些方面。因此,开发有一个核心产品,包含所有合同通用的组件,并为每个客户提供单独的分支(一些客户需要稍作调整,其他客户需要与其他系统进行重大集成)。

在业务增长和分支机构数量扩张之前,它运行得还不错,通常是为了适应非常糟糕的变化。在某一点上,我认为他们有15个不同的活动版本相同的代码库。。。这让事情变得很僵硬,很难支撑。

正如其他人所说,处理资产管理的最佳方法是分支。 我强烈建议您看一下TFS分支指南( http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785 )它解释了根据项目大小创建分支结构的几种方法,以及向最终用户提供软件的不同方式(主要版本、服务包、修补程序)。大多数不是特定于TFS的,因此您可以将其应用于大多数其他源代码管理系统。

在我的公司,当发行版准备好后,我们为主要/次要发行版编号创建一个分支,叫做 R_2_1 . 初始版本是通过在之后立即生成一个快照分支或标签来完成的,称为 R_2_1_0 . 当QA针对某个版本提交bug时,在 R_X_Y 分支,然后是一个 R_2_1_1 创建分支以标记该版本。所以这棵树看起来是这样的:

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

我们使用SVN并为每个版本创建两个分支。一个是用于构建此版本的源代码的标记,另一个是实际发布的二进制文件的新导入。这一点很重要,因为(无论您如何尝试使两个开发人员的计算机相同,或者试图维护一个稳定的构建计算机),当您尝试在6个月后重新生成build X时,您将发现某些东西发生了更改,并且结果的二进制文件有细微的不同。

次要补丁是在从发布源代码分支复制的分支中生成的,并合并到主干中。然后,通过将发布源代码分支复制到新分支并合并到需要的修补程序中,就可以轻松地生成一个小版本。

主要工作是在从主干复制的分支中执行的,并在完成后合并回主干中。然后可以从主干进行主要的发布。

一个基于ITIL框架的答案(这或多或少等同于其他框架)。

ITIL将发布分为3组:主要软件版本、次要软件版本和紧急软件修复。

来自ITIL图书:

主要的软件版本和硬件升级,通常包含大面积的新功能,其中一些可能使问题的干预性修复变得多余。主要升级或发布通常会取代之前所有的小升级、发布和紧急修复。
小型软件版本和硬件升级,通常包含小的增强和修复,其中一些可能已经作为紧急修复发布。小的升级或发布通常会取代之前所有的紧急修复。
紧急软件和硬件修复,通常包含对少量已知问题的更正

专业:v1、V2、v3等

紧急情况:v1.1.1、V2.1.1等。。

跟进co cat关于TFS的回答。有一个新的URL,其中包含VS2010和VS11的一些更新

http://vsarbranchingguide.codeplex.com/releases