您的团队对主要版本代码部署执行哪些标准？

Question

我很好奇其他团队在主要版本发布代码（或部署）之前确定了哪种标准。

我不是在寻找每个人的具体答案，但这里有一个关于我想要了解的内容的想法。

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

同样，不要寻找上述任何事情的答案的逐行打孔列表。简而言之，代码发布必须完成的非编码项目才能在您的团队正式被视为“完成”之前完成？

Answer 1

最小化：

1. 单元测试工作
2. 集成测试工作
3. 在测试阶段部署ok
4. 测试阶段的手动简短检查

更好：

1. 单元测试工作
2. checkstyle确定
3. 集成测试工作
4. 指标jmeter和测试覆盖率已通过
5. 在测试阶段部署ok
6. 测试阶段的一些手动测试

最终部署在生产阶段

所有单元和集成测试都会自动运行，最好是在CruiseControl或ant完成的maven等持续集成服务器上运行。在开发Web服务时，使用soapui进行测试可以正常工作。

如果使用了数据库，则在部署之前完成自动升级（例如liquibase）。使用外部服务时，需要进行额外的配置测试，以确保URL正常（来自应用程序的头请求，数据库连接，wsdl get，...）。 在开发webpps时，某些页面上的HTML validation将非常有用。手动检查布局（例如使用browsershots）将非常有用。

（Java开发的所有示例链接）

最后（但并非最不重要）：所有验收测试是否仍在通过？产品是主人想要的吗？在进一步探讨前，在测试系统上与他进行实时审查！

Answer 2

我主要做网络开发，所以我的项目可能与您的不同。就在我的头顶......

• 确保所有网络服务都是最新的
• 确保已将所有数据库脚本/更改/迁移部署到生产服务器
• 最小化所有js和css文件。
• 确保所有单元/功能/集成/ Selenium测试都通过（我们的目标是在开发过程中达到95％以上的测试覆盖率，因此这些通常在确定问题时非常准确）

还有更多，我知道有，但我现在想不到。

Answer 3

每个项目都是不同的，但是根据经验，这里是我尝试在让代码出现之前所做的核心事情。

没有特别的顺序：

1）用户稍后可以找到的版本标识，此版本必须是唯一的。 （通常是可分发，库和可执行文件关联的“版本号”，或“约”对话框中可见的用户。可以是众所周知的寄存器中的数字或固件中的偏移量）

2）用于生成发布的确切代码的快照。 （SCM系统中发布的标签或分支对此有利）

3）必须记录和存档重建源所需的所有工具（如果没有这个，步骤2中的来源将变得有限使用）

4）实际版本的存档（已发布的确切安装程序的副本，谁知道7年后你的工具可能无法构建它，但现在至少你有源代码和可安装在你身边用于调查目的）。

5）此发行版本与前一版本发行说明之间的一组记录更改（我喜欢使用附加到列表的样式，以便所有发布更改在一个位置为用户提供）。

6）候选人释放测试周期完成。使用可分发的创建负载并使用完整/审查测试计划进行测试以确保核心功能正常运行，所有新功能都存在并按预期运行。

7）缺陷跟踪显示所有未完成的项目被标记为a）固定b）不是缺陷c）延迟。

您可以根据域或开发风格进行许多其他步骤，但我会说大多数软件“应该”在每个版本上执行上述步骤。 YMMV。

有趣地冲进城堡。

Answer 4

• Codestyle（自动化）
• 自动化测试（单元和集成测试）
• 手动测试（包括测试和测试阶段）
• Whitebox渗透测试工具（自动化）
• Blackbox渗透测试工具（自动化）
• 在部署前的测试/测试阶段进行手动例外/记录监控
• 随时恢复到以前版本的能力
• 代码审核＆amp; '非法登记'

Answer 5

对于网络/内部应用程序，除了其他建议之外还有一件事。

确保参与操作/部署团队，这样您就不会提供需要更多服务器的软件（不要假设人们已经推动了已有的要求）。

Answer 6

• 查看核对清单：检查所有针对该版本计划的新功能，变更请求和错误修复是否已完成。
• 构建（在构建机器中）在发布模式下编译时没有任何警告或错误。
• 所有自动单元测试都可以正常运行。
• 所有消息和图片均已获得产品团队的批准。
• 性能检查并不比以前的版本差。
• 测试团队已经检查完整（手动）测试计划，没有错误。
  • 在许多可能的场景（不同的操作系统，数据库引擎，配置和第三方应用程序）中测试应用程序。
  • 应用程序的所有功能都经过测试：很多时候我们发现某个功能的变化打破了另一个被认为无关的功能，因为我们必须尽量减少它。
  • 设置或部署也适用于所有场景
  • 该设置可以升级以前的版本

Answer 7

我们最近做了一个重要的发布，所以在我看来这仍然很新鲜。我们制作了一个带有GUI的Windows应用程序，我们发布了一个二进制可执行文件，因此我的列表必然会与仅限Web的版本大不相同。

1. 发布候选人会去测试团队。他们需要至少几天的时间来玩它。如果他们发现任何我们认为是show-stoppers的错误，就会中止发布。这假设你有一个测试团队。如果发布候选人自构建日期起至少已过去一周，我们只会清除候选版本。

2. 所有自动化测试都必须工作并通过。自动测试被认为是现场测试人员的补充。

3. 任何标记为“拦截器”的错误都必须在最终版本中解决。

4. 宣传材料必须准备好（在我们的例子中，是网页更新和电子邮件简报）。经销商会收到提醒，提前几周发布，以便他们也能准备好材料。这主要不是程序员关注的问题，但我们会检查营销声明的准确性。

5. 必须更新许可以反映我们正在使用的任何版权保护。我们的测试版和发行版使用不同的许可模式，这种变化需要编程工作。

6. 必须更新安装程序和许可协议。由于beta版本有一个安装程序，这通常只是一个文本更改，但程序员仍然需要实际更新安装脚本。

7. 需要从应用程序本身删除对beta版本的任何引用。我们错过了其中一些，令人尴尬。

8. 帮助文件和手册必须完全更新并校对，因为它们是发布包的一部分。

9. 如果存在无法及时修复的错误，我们至少会尝试减轻损坏 - 例如，检测到发生了这样的错误，并使用道歉的错误信息。这极大地促进了产品的稳定性。

远远地，主要版本的困难不是编程问题，而是行政/营销问题。这些事情中的许多都需要程序员注意 - 帮助安装人员，校对功能列表，以确保这些都不是废话，手册的校对技术部分，更新许可等。主要的技术差异是从修复bug以减轻错误。

Answer 8

1. 没有明显的错误？确定
2. 单元测试工作？好的（有些被忽略了）哈哈，好吧
3. 设置你肯定。确定
4. 错误记录？当然 ！ :-)我们需要这个！修复错误！
5. all on cruisecontrol.net nice。