我很好奇其他团队在主要版本中发布（或部署）代码之前确保什么样的标准到位。
我不是在寻找每个问题的具体答案，但这里是我想要了解的一个想法。
同样，不一定要逐行查找以上任何内容的答案。简而言之，在正式认为对您的团队“完成”之前，代码发布必须完成哪些非编码项目？
最低限度：
更好的：
最终部署到生产阶段
所有单元和集成测试都自动运行，最好在持续集成服务器上运行，例如由ant或maven完成的CruiseControl。在开发 Web 服务时，使用soapui进行测试可以正常工作。
如果使用了数据库，则在部署之前完成自动升级（例如使用liquibase）。使用外部服务时，需要进行额外的配置测试，以确保 URL 正常（来自应用程序的头部请求、数据库连接、wsdl 获取……）。在开发 webpps 时，在某些页面上进行 HTML验证会很有用。手动检查布局（例如使用浏览器截图）会很有用。
（Java 开发的所有示例链接）
最后（但并非最不重要的）：所有验收测试是否仍然通过？产品是所有者想要的吗？在继续之前与他在测试系统上进行实时审查！
我主要做网络开发，所以我的项目可能与你的不同。就在我的头顶...
还有更多，我知道还有，但我现在想不出来。
每个项目都是不同的，但根据经验，这是我在让代码投入使用之前尝试完成的核心工作。
没有特别的顺序：
1) 用户稍后可以找到的版本标识，这对于此版本必须是唯一的。（通常是与可分发、库和可执行文件相关联的“版本号”，或从“关于”对话框中可见的用户。可能是众所周知的寄存器或固件中的偏移量）
2) 用于生成发布的确切代码的快照。（单片机系统中发布的标签或分支对此有好处）
3) 必须记录和存档重新创建源所需的所有工具（如果没有这个，步骤 2 中的源将变得有限使用）
4）实际发布的存档（发布的确切安装程序的副本，谁知道在 7 年内你的工具可能无法构建它，但现在至少你有源代码和可安装在你身边用于调查目的）。
5) 此发布版本与之前的版本（即发布说明）之间的一组记录更改（我喜欢使用附加到列表的样式，以便用户可以在一个地方使用所有发布更改）。
6) 候选发布测试周期完成。使用可分发的创建负载并使用完整/经过审查的测试计划进行测试，以确保核心功能正常运行，所有新功能都存在并按预期运行。
7) 缺陷跟踪显示所有未完成的项目都被标记为 a) 已修复 b) 不是缺陷 c) 延期。
您可以根据领域或开发风格加入许多其他步骤，但我会声明大多数软件“应该”在每个版本中执行上述步骤。YMMV。
玩得开心冲进城堡。
对于网络/内部应用程序，除了其他建议之外还有一件事。
确保让运营/部署团队参与进来，这样您就不会交付需要比他们拥有更多服务器的软件（不要假设推动需求的人已经拥有）。
我们最近发布了一个主要版本，所以这在我的脑海中仍然很新鲜。我们制作了一个带有 GUI 的 Windows 应用程序，我们为其发布了二进制可执行文件，因此我的列表必然与仅 Web 版本的列表大不相同。
发布候选人前往测试团队。他们至少需要几天的时间来玩它。如果他们发现任何我们认为是阻碍因素的错误，则发布将被中止。这假设您有一个测试团队。我们仅在自构建日期起至少一周后才清除候选版本。
所有自动化测试都必须工作并通过。自动化测试被认为是对现场测试人员的补充。
任何标记为“阻止程序”的错误都必须在最终构建中解决。
宣传材料必须准备好（在我们的案例中，是网页更新和电子邮件通讯）。经销商会提前几周收到通知，以便他们也可以准备材料。这主要不是程序员关心的问题，但我们会检查营销声明的准确性。
必须更新许可以反映我们正在使用的任何复制保护。我们的测试版和发布版使用不同的许可模型，而这种变化需要编程工作。
必须更新安装程序和许可协议。由于 beta 版本有一个安装程序，这通常只是一个文本更改，但仍然由程序员实际更新安装脚本。
任何对 beta 版本的引用都需要从应用程序本身中删除。我们错过了其中的一些，令人尴尬。
帮助文件和手册必须完全更新和校对，因为它们是发布包的一部分。
如果存在无法及时修复的错误，我们至少会尝试减轻损失——例如，检测到某某错误正在发生，并通过道歉错误消息中止操作。这极大地有助于感知产品的稳定性。
很明显，主要版本的困难不是编程问题，而是管理/营销问题。其中许多事情都需要程序员的关注——帮助安装程序、校对功能列表以确保其中没有废话、校对手册的技术部分、更新许可等。主要的技术差异是从错误修复到错误缓解。