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

StackOverflow https://stackoverflow.com/questions/700833

  •  22-08-2019
  •  | 
  •  

题

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

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

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

再说一遍，不一定要寻找上述任何问题的逐行答案清单。简而言之， 在正式认为您的团队“完成”之前，代码发布必须完成哪些非编码项目？

有帮助吗？

解决方案

最小值：

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

更好的：

  1. 单元测试工作
  2. 格子风格 好的
  3. 集成测试工作
  4. 指标如 杰米特 并通过了测试覆盖率
  5. 部署到测试阶段ok
  6. 测试阶段的一些手动测试

最终部署到生产阶段

所有单元和集成测试都会自动工作，最好在持续集成服务器上运行，例如 巡航控制 完成者 蚂蚁 或者 行家. 。开发 Web 服务时，使用 肥皂普 工作正常。

如果使用数据库，则会完成自动升级（使用 液体碱 例如）在部署之前。当使用外部服务时，需要额外的配置测试，以确保 URL 正常（来自应用程序的头请求、数据库连接、wsdl get，...）。开发webpps时，一个HTML 验证 在某些页面上会很有用。手动检查布局（使用 浏览器截图 例如）会很有用。

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

最后但并非最不重要）：所有验收测试仍然通过吗？产品是业主想要的吗？在进一步进行之前，与他一起对测试系统进行实时审查！

其他提示

我主要从事网络开发，因此我的项目可能与您的不同。就在我头顶上...

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

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

每个项目都是不同的，但是根据经验，这里是我在让代码投入使用之前尝试完成的核心事情。

排名不分先后：

1) 版本标识位于用户稍后可以找到的位置，这对于该版本必须是唯一的。（非常典型的是与可分发文件、库和可执行文件相关联的“版本号”，或者用户可以从“关于”对话框中看到的“版本号”。可能是众所周知的寄存器中的数字或固件中的偏移量）

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

3) 必须记录并存档重新创建源所需的所有工具（如果没有此工具，步骤 2 中的源的用途将受到限制）

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

5）此发行版与上一个发行版之间的一组记录的更改，又称发行说明（我喜欢使用附加到列表的样式，以便用户可以在一个地方使用所有发行版更改）。

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

7) 缺陷跟踪显示所有未完成的项目都被标记为 a) 已修复 b) 非缺陷 c) 已推迟。

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

尽情享受攻打城堡的乐趣。

  • 代码风格（自动）
  • 自动化测试（单元测试和集成测试）
  • 手动测试（包括测试和测试阶段）
  • 白盒渗透测试工具（自动化）
  • 黑盒渗透测试工具（自动化）
  • 推出前测试/测试阶段的手动异常/日志监控
  • 能够随时恢复到以前的版本
  • 代码审查和“非法签入”

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

确保让运营/部署团队参与进来，这样您就不会交付需要比他们拥有的更多服务器的软件（不要假设推动需求的人已经拥有）。

  • 查看清单：检查该版本计划的所有新功能、更改请求和错误修复是否已完成。
  • 构建（在构建机器中）在发布模式下编译时不会出现任何警告或错误。
  • 所有自动化单元测试都运行没有错误。
  • 所有消息和图像均已得到产品团队的批准。
  • 性能检查并不比以前的版本差。
  • 完整的（手动）测试计划已经过测试团队的检查，没有错误。
    • 该应用程序在许多可能的场景（不同的操作系统、数据库引擎、配置和第三方应用程序）中进行了测试。
    • 该应用程序的所有功能都经过测试：我们经常遇到这样的情况：一个功能的改变打破了另一个不相关的想法，糟糕的事情发生了，所以我们必须尽量减少它。
    • 设置或部署也适用于所有场景
    • 该安装程序能够升级以前的版本

我们最近发布了一个主要版本，所以这对我来说仍然很新鲜。我们制作了一个带有 GUI 的 Windows 应用程序，并为其发布了二进制可执行文件，因此我的列表必然与纯 Web 版本的列表有很大不同。

  1. 发布候选者前往测试团队。他们至少需要几天的时间来玩它。如果他们发现任何我们认为是阻碍因素的错误，发布就会中止。这假设您有一个测试团队。仅当自候选版本构建日期起至少已经过去一周后，我们才会清除该候选版本。

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

  3. 任何标记为“阻止程序”的错误都必须在最终版本中得到解决。

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

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

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

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

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

  9. 如果存在无法及时修复的错误，我们至少会尝试减轻损害 - 例如，检测到正在发生这样那样的错误，并使用抱歉的错误消息中止操作。这极大地提高了产品的稳定性。

显然，主要版本的困难不是编程问题，而是管理/营销问题。其中许多事情需要程序员的关注——帮助安装人员、校对功能列表以确保其中没有废话、校对手册的技术部分、更新许可等。主要的技术差异是从错误修复到错误缓解的转变。

  1. 没有明显的错误？好的
  2. 单元测试工作？好的（有些被忽略）哈哈好吧
  3. 确定设置。好的
  4. 错误记录？当然 ！:-) 我们需要这个！修复错误！
  5. 一切都在 Cruisecontrol.net 上，很好。
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top