版本控制和里程碑之间是否存在相关性?[关闭]

正如古语所说,“标准的美妙之处在于有这么多可供选择。”我不能告诉你我会如何为PHP项目做到这一点,但我可以告诉你我们为我们的商店使用的方法——这是一种。NET商店。

我们使用一个相当传统的四部分版本控制系统,版本的每个部分代表不同的东西。例如:

少校。小。修订。建筑

显然,每一个都是一个数字。对我们来说,这四个部分是微软预先决定的。让我带你回到堆栈中,看看我们如何证明每一个:

• 构建-在我们的商店中自动递增。此指示器就像编译器提供的构建的唯一标识符。
• 修订版-我们将此保留为不会破坏兼容性的版本。暴露的接口被保留,第三方实现可能会在不进行修改的情况下完整运行。
• 次要-这是一个通常引入新功能、更改现有功能并具有更高兼容性风险的版本。
• 重大-涉及大规模重写、大型新功能集并从根本上偏离先前代码库的大规模更改。

里程碑在哪里发挥作用?它们是我们的项目目标。里程碑是在项目启动之前确定的,代表了应该达到预期进度水平的点。它主要用于在发布之前向业务用户介绍功能,并监控发布的整体交付时间表。我们还为每个里程碑在版本控制中应用了一个标签,以帮助在因任何原因需要手动构建里程碑时轻松识别。

在我们店里,里程碑的内容比它的名称更重要。为什么?当有多个原因使复杂的里程碑成为里程碑时,很难以一种传达意义的方式命名它。我们在日历和维基上放置了里程碑,并描述了其中预期实现的目标。

正如我之前提到的,我相信你也会得到一些其他的“标准”。目标是找到适合你和你的团队的流程,并坚持下去。

在我们的开发过程中,版本和里程碑是不同的。 我们的一个标准里程碑是 释放 当然,这有一个版本。 但对我来说,里程碑是未来的事情,是我必须计划的事情。一个版本与一个版本相关联,所以它是过去的东西。

我们的标准里程碑方案基于全公司的项目管理标准。我们有。。。

• S门: 明确规定
• A门: 可获得的
• V型门: 已证实的
• R门: 释放

对于迭代开发,我们基本上重复这个循环。 从A到V的门是阿尔法相,从V到R是贝塔相。对于较大的项目,我们会添加与正在完成的特定功能集相关的里程碑。

我们使用它的原因主要是所有项目都是按照这个方案报告的,以他们熟悉的方式向管理层提供信息总是很好的做法;-)

是的,这意味着你在迭代中已经完成了足够的工作,可以发布一些有用的东西。里程碑通常意味着你已经实现了比迭代结束更重要的事情。我会使用有意义的名字,是的。

你至少在谈论两件无关的事情。有源代码控制和项目里程碑。它们是相关的,但它们不是一回事。此外,还有软件开发工作本身,它与源代码和项目里程碑有关,但也有所不同。

这是一种基于Scrum的方法。它有三个无关的东西,可以编号或命名。

首先是软件开发工作。

1. 我们有冲刺来建造东西。这些可以编号,但通常有名字。诸如“批量加载第1部分”、“重构工作簿库”或“添加销售演示数据夹具”之类的名称。

2. 我们有释放的东西。这些可以编号(基于SVN版本,或基于我们内部的“兼容版本”,但它们通常有名称。“客户X的首次发布”,或“此Bug修复”或“升级到那个”或其他有意义的东西。

其次,还有源代码控制。为此,我们有一些内部版本/修订跟踪,与冲刺和发布关系不大。

1. SVN有存储库版本号。这会随着每次签入而增加。有些星期,每天都有签到。有些星期,只有几个“大”签到。

2. 我们有一个主版本号。次版本号,我们手动更新以显示兼容性。有些应用程序从1.1迁移到1.2,因为一些小的变化,但数据库和API是相同的。其他应用程序从2.3迁移到3.1,因为数据库或API(或两者)以某种不兼容的方式发生了更改,我们需要进行模式迁移,并可能通知客户REST客户端接口的更改。

第三,项目规划。

我们的项目规划 里程碑 包括我们的发布时间表。然而,项目里程碑还包括其他与软件关系不大的事情。里程碑包括“签署新的托管协议”或“获取客户X测试数据”等。这些不是版本、发布、冲刺或任何东西。

“有什么规则吗?”是的。阅读Scrum,了解一套好的规则。

这不是一件事。这是两件(或三件)事情。

版本号很方便,因为你可以立即获取任何两个版本,看看哪个是两个版本中的较新版本。这在一定程度上总是主观的,因为谁能说什么功能或bug修复是一个里程碑?

我喜欢的方案是x.y.z,其中x是主要版本号,y是次要版本号,z是内部版本号。重大发布意味着重写、大修或引入重大新功能。小版本发布意味着重大的错误修复,或一些小的功能改进或错误修复。内部版本号正是内部版本号。