问题标签 [release-management]

我见过许多列出了有关已知问题的详细信息的 API？如果存在已知问题，为什么要在修复之前将其公开？

是什么原因？死线？或者修复它会破坏其他东西？

注意：我不确定这个问题是否属于这里。因此，如果这不是一个有效的问题，请随时关闭。

我对精益/看板很陌生，但在过去的几周里，我倾注了大量的在线资源，并提出了一个我没有找到好的答案的问题。精益/看板似乎非常适合我们公司，他们已经在使用 Scrum，但在该方法中遇到了一些限制。我希望这里有人能给我一个好主意。

在我看来，Scrum 相对于 Waterfall 的最大优势之一是使用 sprint。通过每 14 天准备好一切，您可以获得较短的反馈周期并且可以经常发布。然而，正如我从阅读有关精益的文章中了解到的那样，有一些与此相关的成本（例如，花费在 sprint 计划会议、团队承诺会议上的时间以及在 sprint 结束时为每个人找到有用的东西的一些问题）。

精益/看板将消除这些浪费，但代价是不能每 14 天释放一次。还是我错过了重要的一点？因为，在看板中，您如何能够同时处理新的开发任务和发布？你如何确保你不会运送只完成一半的东西？以及如何正确测试它？

到目前为止，我最好的“解决方案/想法”是：

• 不要经常发布并允许与用完新开发任务相关的浪费。不过，这并不是真正解决问题的方法。
• 在分支中发展，然后合并到主干中。使您必须在内部连续支持至少两个分支。
• 使用一些智能自动标签系统来自动构建某些已完成的任务，而不是其他任务。

总结一下，我的问题是：当你使用精益/看板时，你能经常发布而不引入浪费吗？或者发布通常不是精益/看板的一部分？

特定于我公司的附加信息：我们使用 Team Foundation System 和源代码控制，以前在分支和合并方面有过一些不好的经历。可以通过引入该领域的一些专业知识来解决这个问题吗？

今天我的一位同事告诉我，有些项目使用了一种奇怪的、恕我直言的方式对其版本进行版本控制。如果发行版不稳定，则次要版本为奇数，例如。1.3，1.5。另一方面，稳定版本有一个更小的版本号，例如。1.2，1.4。

起初我不敢相信自己的耳朵，这似乎是不真实的。然后Wikipedia启发我，这是一种来自 Linux 内核社区的做法，尽管它似乎（？）最近被放弃了。

几个小时后，我正在阅读Programming Ruby 的序言，我看到了什么？Ruby 对版本号使用相同的约定。

你对此有何经验？您知道哪些（开源）项目/产品使用此版本控制模式？如果他们遵守这个约定，有没有一种简单的方法可以快速弄清楚？有那么受欢迎吗？我在 3 年多前就开始了软件开发，以前从未听说过这种做法。

感谢您的回复。

我们最近发生了一个事件，其中一些代码被发布到生活中，但没有计划发布。

很明显，它已经被放进后备箱了。我想这很好，因为您想“早点入住，经常入住”。

但是在这种情况下，它不应该在下一个版本中发布。

可以采取什么样的检查/策略/流程来避免代码过早发布。

在我看来，即使使用持续集成和单元测试，这也是一个人工程序问题？

——李

进一步回答我在意外发布代码到现场如何防止发生再次发生的问题。在客户 UAT 之后，我们经常让客户说他们很高兴发布部分功能，而他们希望在未来的版本中发布其他功能。

我的问题是“您如何发布 2/3（三分之二）的功能”。我会对微软等大公司如何处理类似情况感兴趣。“是的，我们只会在下一个 Word 版本中发布最初提议的功能/修复的 45/50，打包并发布”。

假设下一个版本中没有发布的这 5 个特性已经启动.. 你怎么能在发布构建和部署中忽略它们？

您如何发布 2/3 的开发功能？

如何发布可交付成果的子集？

——李

在大型组织现场安装应用程序并支付支持费用的情况下，我的公司正在努力解决维护版本与“正常”版本的问题。首先让我定义我的术语：

• 假设我们已经发布了产品的 1.0、1.1 和 1.2 版本。这些是我所说的“正常”版本，即它们是主要开发分支的下一个版本，包含所有最新和最强大的错误修复和增强功能（每个版本可能有数十个）。
• 现在想象一下 1.0 上的一些大客户报告了一个以前没有人遇到过的令人震惊的问题。这个问题在 1.2 中仍然存在，不幸的是 1.3 不会在几周或几个月后发布。因此，我们在 1.0 分支代码以创建 1.0.1“维护”版本，其中仅包含解决问题的一项更改。

这种方法让客户很高兴，因为我们在一天左右的时间内解决了他们的问题，而不是让他们等待数周直到下一个正常版本。此外，由于维护版本只包含一个小的更改，他们不需要经过广泛的 UAT 过程，而如果他们升级到下一个正常版本，可能会有几个版本，他们可能会收到 30 或 40 （在他们厌恶风险的观点中）需要大量 UAT 的产品变更。

问题是：

• 创建和支持我们软件的多个版本对我们来说成本很高
• 它允许顽固的客户远远落后于最新版本
• 它使将来最终升级这些客户的过程变得复杂，因为他们的安装与所有其他 1.0 客户略有不同（如果维护版本以某种方式对其进行了更改，则升级他们的数据库特别复杂）

所以我想知道其他人在这个问题上的立场是什么？您如何在不通过大量维护版本为您自己背锅的情况下让客户满意？例如，您是否允许某些类别的修复作为维护版本完成，但坚持其他类型的修复在下一个正常版本中完成？

澄清：编写没有错误的软件并不是一个完整的解决方案，因为上述上下文中的“问题”可能是我们产品所依赖的外部系统行为的不可预见的变化。

我与我的同事就部署文档的组成进行了持续的争论。

每个人都同意文件是必要的。并不是每个人都能找到共同点，即应该在多大程度上详细说明这一点，尤其是大版本、错误修复和增强之间的区别。

你发现什么最适合你？

想知道有经验的人是否可以解释一下。我见过的例子...

....在（void）dealloc中。

有什么区别，一个比另一个更好？什么是最好的方法？

在进行 retainCount 测试时，我个人看到 nil 将计数从 3 降至 0，但 release 仅将其从 3 降至 2。

我正在尝试为我的 Web 应用程序在 Zend 框架和 Ruby On Rails 之间做出决定。

如果我选择 ZF，我需要以下内容：

• 一种增量跟踪数据库更改的方法，如 RoR 的迁移功能（001_something.sql、002_something_else.sql）。
• 为我的软件的下一个版本放置 SQL 的地方。在我们的自定义 PHP 解决方案中，我们只有 release.sql，它会在发布时运行、存档和清空。

ZF 有 Zend_Db_Schema_Manager，它做同样的事情，但我不感兴趣，因为它不是官方的、完整的或维护的。

采埃孚是否提供了一个官方机制来做类似于我描述的事情？

编辑我最终选择了 Rails。没有什么可比的。

给定一个大型软件项目，其中包含用不同语言编写的多个组件、配置文件、配置脚本、环境设置和数据库迁移脚本——部署到生产的常见做法是什么？

有哪些困难需要考虑？可以使用 Ant 或 Maven 等工具简化流程吗？如何处理回滚和数据库管理？是否建议对生产环境使用版本控制？