问题标签 [release-management]

我想使用类似以下命令来创建要部署的 tarball：

当我单独运行它时，内部 git diff 命令会生成一个包含相对路径的文件列表。

我遇到了两个问题，我需要能够在输出中自动转义空格，所以 tar 不会抱怨包含空格的文件，并且当 tar 确实被创建时，所有文件都有一个重复的“隐藏文件”前面有一个“。” 不会出现在 ls -al中。这些是 kch 所指出的 OSX 特定的元文件。

无论如何，有没有人知道这些问题的解决方案，或者是否有一种更简单的方法来编写脚本？

您是否必须在发布时使用编译来部署 .pdb 文件？

无论如何，当您进行发布构建时，为什么它甚至会编译 .pdb？

我正在使用“Inspector.aspx”在我的调试版本中进行一些测试。在发布版本中（更重要的是在创建安装程序时），我从项目中手动排除页面（及其相关的 C# 文件）。

有没有办法自动排除 ASP.NET 项目中选定解决方案配置中的文件？

C++ 项目可以控制每个配置的每个文件的排除/包含

我是一家制造公司的内部开发人员。我们为制造过程制作软件，而不是真正的控制软件，更像是流程。

我们正在使用 Scrum 流程来开发软件，尽管它是为适应我们的团队和环境而量身定制的，而且效果很好。我们即将结束 sprint，软件正处于产品所有者想要部署它的阶段。

以前，即在 Scrum 之前，我们会部署软件。现在我觉得我们已经开发了软件，我们已经通过了所有用户定义/同意的发布测试，并用模拟器向 PO 演示了软件，我们已经实现了我们的目标。我们已准备好提供部署支持，但我认为部署不应该是我们的责任。

其他人的经历是什么？开发团队应该进行部署，还是我们应该将完成的软件交给 PO 并提供支持？

加起来

很多很好的回应，谢谢。这个问题可能看起来像是我试图摆脱工作或责任，也许我有点;o）我更感兴趣的是其他人的过程。我们在这里面临的问题是，如果开发团队部署了软件，那么我们最终会为软件的生产提供 24/7 的支持。没有问题，除了我们只有两个人。因此，为了让我们能够回到开发软件而不是一直提供支持，我认为让“IT”团队参与开发过程可能会有所帮助。希望这将获得“支持”，然后允许他们部署并提供第一级支持。我们在墨西哥也有一家工厂，开发团队很难去那里部署，当地支持这样做更有意义，

只是为了让您知道，IT 工程师确实在开发人员的指导/建议下部署了该软件。它进展顺利，客户很高兴——他的软件增值了，这不就是全部吗？

我很好奇其他团队在主要版本中发布（或部署）代码之前确保什么样的标准到位。

我不是在寻找每个问题的具体答案，但这里是我想要了解的一个想法。

• 对于基于服务器的应用程序，您是否确保监控到位？到什么程度......只是它响应 ping，它可以在任何给定时刻命中其所有依赖项，应用程序实际服务的逻辑是合理的（例如，计算 2+2 的服务实际上返回“4 ")
• 在发布代码之前是否需要自动构建脚本？意思是，任何开发人员都可以走到一个新盒子上，从源代码控制中拉出一些东西，然后开始开发？当然，考虑到操作系统和 IDE 之类的东西。
• 对于基于服务器的应用程序，自动化部署脚本怎么样？
• 您需要什么级别的文档才能“完成”项目？
• 如果它是基于服务器的，您是否确定您对系统的所有主要组件都有完整的备份计划？
• 您是否执行代码质量标准？考虑用于 .NET 或圈复杂度评估的 StyleCop。
• 单元测试？集成测试？性能负载测试？
• 对于如何处理应用程序的错误日志记录，您有标准吗？错误通知呢？

同样，不一定要逐行查找以上任何内容的答案。简而言之，在正式认为对您的团队“完成”之前，代码发布必须完成哪些非编码项目？

我有一个我们之前使用 nAnt 脚本构建的 NSIS 安装程序，它复制一些文件并通过 exec 任务运行 makensis.exe 来构建安装程序 exe。在 nant 脚本完成后，我有了 CD 的完整结构和下载。

我只是从 sourcesafe 获取到一个未使用的桌面并将其用作构建框，在那里编译。有时我们会检查几个文件来修复一些关键问题。在这些情况下，我会去构建框，并且非常有选择地只获取那些文件，以避免获取我们尚未准备好发布的其他已更改文件。基本上，我能够允许开发继续并有选择地将某些更改的文件包含到安装程序中以供发布。

现在我们不再有免费的盒子，需要从我们的服务器构建。所以我正在设置 CI 工厂，以便开发人员可以在不远程连接到服务器的情况下启动构建。我正在努力解决的一个问题是继续允许这种选择性变更控制发生的最佳方式。CI Factory 实现的默认 CI 概念非常适合内部开发“负责人”。但是，我还想为这种“公开发布”类型的构建设置一个仅通过强制构建按需运行的 CCNet 项目。

到目前为止，这就是我的头脑风暴，但不确定它的效果如何，如果有的话（仍在弄清楚 CCNet 和 CI 工厂的全部内容）。将设置“公开发布”CCNet 项目配置/构建，使其不会最新。修改不会触发构建。由于另一个 CCNet 项目使用默认的 CI 方法（我们将其称为“CI 项目”）在检测到更改时获取最新信息，因此这两个项目不能共享同一个工作目录。所以“公开发布”需要一个不同的工作副本，这样当 CI 项目的构建被触发时，它的文件就不会被更新。开发人员需要远程访问服务器，一个 VSS，有选择地进入“公共发布”的工作副本，然后通过 CI 工厂强制构建。

我看到的缺点是
1) 必须远程访问才能有选择地进行获取。
2) 我不知道如何允许单个 CI 工厂项目拥有 Product 文件夹的两个不同工作副本，以便每个项目配置块都有自己的。
3）我担心这可能会导致什么样的奇怪。我还不太确定如何在 CCNet 项目配置块中指定源代码控制块，但要防止它在构建时执行最新操作。我仍在逐渐弄清楚脚本中的内容，并且可以在不破坏其他内容的情况下轻松取出，而不是那些不应该被弄乱和/或不可配置的东西。

如果您有类似的情况，我真的很想听听其他人如何处理选择性发布更改的问题。我受限于 VSS，所以我迫切需要考虑到这一点来解决这个问题，但同时我很想听听您如何使用其他源代码控制系统来管理这个问题。我猜你可能会有一个分支是你最新的开发分支，然后在你想发布它们时将更改合并到主干中？我真的不相信 VSS 进行分支/合并，我认为分支概念对于这家商店来说可能有点过多的开销和学习曲线。就像我说的那样，其他源代码控制系统的故事对我来说是有用的未来知识。

提前致谢。

我和我的同事对发布/SCM 系统中标签的价值和使用存在争议。我们期待 StackOverflow 社区提出他们的想法，以帮助我们解决问题。

一方面声称标签是发布管理的一个有价值的补充。它们的使用示例：我们做了一个 Maven 版本，它创建了一个新标签（称为 1.0），这是用于此版本的代码快照。这个标签应该是一个 READONLY 分支。当需要修复错误时，我们可以将标签复制到新分支中（称为 1.1）。错误修复在那里。这些修复可以合并回主干，以便主开发分支获得错误修复。最后，发布 1.1 并自动创建一个 Tag 1.1。这个循环继续。Tag 的主要好处是，如果您出于任何原因需要重新发布 1.0 版，您可以放心地发布 Tag 1.0，因为它从未被任何人更改过。此外，说“Release Tag 1.0”比说“Release revision 1 of branch 1.0 which is original 1.0”更干净。

另一方声称标签没有提供任何有价值的好处，尤其是在像 Subversion 这样具有全局修订的系统中，它就像 CVS 中的标签一样。另外，Subversion 只在提交标签时给出警告；它实际上并没有阻止它。他们的方法是在 Trunk 中开发，发布后你会创建一个名为 1.0 的分支。您将继续在 Trunk 中修复错误，如果您需要将这些错误修复重新发布到生产环境，您可以将它们合并到 1.0 分支并重新发布 1.0。在某个时候，也许在 Trunk 中的主要修复或功能之后，您会发布并制作 Branch 1.1。循环继续。如果您需要发布原始 1.0 版本，则必须查看 Branch 1.0 修订版 1。

显然这两种方法都有效。我想听听社区对首选哪种方法以及原因的看法。

编辑：我有点担心“最佳”方式取决于底层的 SCM 系统。要么选择 Subversion 来寻找答案，要么尽可能让它与 SCM 无关。

我正在设置 Hudson 以使用批处理任务插件向我们的内部存储库执行 Maven 发布。我正在通过以下方式进行：

我对人们使用的其他方法以及这些方法的优缺点感兴趣。此外，人们遇到的任何问题。

我们正在接近我们公司新产品的初始版本，我正在尝试确定管理所有不同组件版本的最佳方法，并将这些组件与我们软件的营销部门版本进行交叉引用。由于各种原因，营销部门已确定我们产品的初始版本为 10.1，但所有组件最初都将从 1.0.0 开始。通过正常的 bug 修复和补丁以及持续的开发工作，不同的组件将不再具有相同的版本号，所以当市场部决定是 10.2 版本时，它可能包含 1.1.54、1.2.32、1.8.2、等等。显然，我可以使用一个简单的电子表格，但这并不是最用户友好的方法，

是否有更“专业”的方法，或者简单的电子表格是最佳选择？

当您对现有的业务线应用程序进行增强时，您认为将更改批量更改为不太频繁的较大版本，还是在较小的版本中不断发布新功能更好？假设有硬件升级或数据库升级，您是在版本中也进行这些更改，还是将它们分开？

将所有内容一起发布的优点是对业务的干扰更少，涉及的工作时间更少，但是您以后遇到的任何问题都可能是由于数据库升级、硬件或任何数量的软件更改造成的。

很少发布并且通常可以更容易地跟踪发布导致的任何问题，但会导致更多的中断和更多的回归测试时间。

哪个更好？