我在一家产品开发公司工作。我们首先进行内部发布,然后是公开发布。我想知道,其他产品开发公司如何管理他们的发布?你怎么给发布号?标记源代码管理?
8 回答
我们使用 SubVersion,其中标签和分支的创建成本很低。
就发布而言,我们遵循以下约定:
(主要版本)。(次要版本)。(补丁版本)。(SVN修订版)
- 补丁发布 = 错误修复
- 次要版本 = 二进制兼容 / 接口兼容
- 主要版本 = 包括重大更改。
那有意义吗?如果您需要更多信息,请添加评论,我将编辑我的帖子以澄清。
我创建了一个类似的问题,但我想补充一点:我强烈建议使用Jira 之类的东西来管理发布周期。您可以将提交与请求/问题/错误相关联,然后将它们标记为发布的一部分。
特别是,如果您想知道如何管理一个良好的发布周期,请查看 Apache 基金会是如何做到的,因为他们将其归结为一门科学。例如,这里是Mahout 项目中的发布路线图。
除了跟踪问题并将它们捆绑在发布包中的工作系统外,您还需要开始将其与持续集成(我使用过 CruiseControl 和 Hudson)和单元测试集成,以便您的构建周期与所有内容一起管理别的。
我曾在一家定制软件供应商工作,当客户决定不想实施自己的呼叫中心和网站时,该供应商最终转变为解决方案供应商。
在那种环境下,每个主要客户都有机会定制系统工作方式的某些方面。因此,开发有一个核心产品,其中包含所有合同通用的组件,并为每个客户提供单独的分支(一些客户需要进行细微调整,其他客户需要与其他系统进行重大集成)。
它工作得很好,直到业务增长和分支机构数量扩大,通常是为了适应真正蹩脚的变化。在某一时刻,我认为他们拥有相同代码库的 15 个不同的活动版本……这使得事情变得非常不灵活且难以支持。
不要做我们所做的——让你的发布规模扩大!
正如其他人所说,处理管理释放的最佳方法是分支。我强烈建议您查看 TFS 分支指南 ( http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785 ),它解释了根据项目大小和不同创建分支结构的几种方法向最终用户提供软件的方式(主要版本、服务包、修补程序)。其中大部分并非特定于 TFS,因此您可以将其应用于大多数其他源代码控制系统。
在我的公司,当一个版本准备好时,我们为主要/次要版本号创建一个分支,称为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)
| |
. .
. .
. .
基于 ITIL 框架的答案(或多或少等于其他框架)。
ITIL 将版本分为 3 组:主要软件版本、次要软件版本和紧急软件修复。
来自 ITIL 书籍:
• 主要软件版本和硬件升级,通常包含大量新功能,其中一些可能会使对问题的干预性修复变得多余。主要升级或发布通常会取代之前的所有次要升级、发布和紧急修复。
• 次要软件版本和硬件升级,通常包含小的增强和修复,其中一些可能已经作为紧急修复发布。次要升级或发布通常会取代之前的所有紧急修复。
•紧急软件和硬件修复,通常包含对少数已知问题的更正
所以,按照这个你应该有:
主要:v1、V2、v3 等
次要:v1.1、V2.1 等
紧急情况:v1.1.1、V2.1.1 等。
我们使用 SVN 并为每个版本创建两个分支。一个是用于构建此版本的源代码的标签,一个是实际发布的二进制文件的新导入。这很重要,因为(无论您多么尝试使两个开发人员的机器相同,或尝试维护稳定的构建机器)当您尝试在 6 个月后重新生成构建 X 时,您会不可避免地发现一些东西已经改变并且产生的二进制文件略有不同。
小补丁在从发布源分支复制的分支中制作,并合并到主干中。然后可以通过将发布源分支复制到新分支并合并所需的任何补丁来轻松制作次要版本。
主要工作在从主干复制的分支中进行,完成后合并回主干。然后可以从主干进行主要版本。
跟进 co-cat 关于 TFS 的回答。有一个新的 URL,其中包含 VS2010 和 VS11 的一些更新