11

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

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

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

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

4

8 回答 8

5

最低限度:

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

更好的:

  1. 单元测试工作
  2. 检查样式没问题
  3. 集成测试工作
  4. 通过jmeter和测试覆盖率等指标
  5. 在测试阶段部署好
  6. 测试阶段的一些手动测试

最终部署到生产阶段

所有单元和集成测试都自动运行,最好在持续集成服务器上运行,例如由antmaven完成的CruiseControl。在开发 Web 服务时,使用soapui进行测试可以正常工作。

如果使用了数据库,则在部署之前完成自动升级(例如使用liquibase)。使用外部服务时,需要进行额外的配置测试,以确保 URL 正常(来自应用程序的头部请求、数据库连接、wsdl 获取……)。在开发 webpps 时,在某些页面上进行 HTML验证会很有用。手动检查布局(例如使用浏览器截图)会很有用。

(Java 开发的所有示例链接)

最后(但并非最不重要的):所有验收测试是否仍然通过?产品是所有者想要的吗?在继续之前与他在测试系统上进行实时审查!

于 2009-05-20T19:02:43.460 回答
4

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

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

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

于 2009-03-31T13:15:35.387 回答
4

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

没有特别的顺序:

1) 用户稍后可以找到的版本标识,这对于此版本必须是唯一的。(通常是与可分发、库和可执行文件相关联的“版本号”,或从“关于”对话框中可见的用户。可能是众所周知的寄存器或固件中的偏移量)

2) 用于生成发布的确切代码的快照。(单片机系统中发布的标签或分支对此有好处)

3) 必须记录和存档重新创建源所需的所有工具(如果没有这个,步骤 2 中的源将变得有限使用)

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

5) 此发布版本与之前的版本(即发布说明)之间的一组记录更改(我喜欢使用附加到列表的样式,以便用户可以在一个地方使用所有发布更改)。

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

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

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

玩得开心冲进城堡。

于 2009-05-23T21:49:53.257 回答
1
  • 代码风格(自动)
  • 自动化测试(单元和集成测试)
  • 手动测试(包括测试和 beta 阶段)
  • 白盒渗透测试工具(自动)
  • 黑盒渗透测试工具(自动化)
  • 在推出之前对测试/beta 阶段进行手动异常/日志监控
  • 随时恢复到以前版本的能力
  • 代码审查和“非法签入”
于 2009-05-25T07:52:15.820 回答
1

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

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

于 2009-05-25T12:53:09.317 回答
1
  • 查看清单:检查是否已完成为该版本计划的所有新功能、更改请求和错误修复。
  • 构建(在构建机器中)在发布模式下编译没有任何警告或错误。
  • 所有自动化的单元测试都运行没有错误。
  • 所有消息和图像均已获得产品团队的批准。
  • 性能检查并不比以前的版本差。
  • 完整的(手动)测试计划已经过测试团队的检查,没有错误。
    • 该应用程序在许多可能的场景(不同的操作系统、数据库引擎、配置和第三方应用程序)中进行了测试。
    • 应用程序的所有功能都经过测试:很多次发生在我们身上,一个功能的更改破坏了另一个认为不相关的功能,发生了糟糕的事情,所以我们必须将其最小化。
    • 设置或部署也适用于所有场景
    • 该设置能够升级以前的版本
于 2009-05-25T19:07:43.967 回答
1

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

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

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

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

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

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

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

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

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

  9. 如果存在无法及时修复的错误,我们至少会尝试减轻损失——例如,检测到某某错误正在发生,并通过道歉错误消息中止操作。这极大地有助于感知产品的稳定性。

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

于 2009-05-26T10:20:28.833 回答
0
  1. 没有可见的错误?行
  2. 单元测试工作?好的(有些被忽略)哈哈好吧
  3. 设置你确定。行
  4. 错误记录?当然 !:-) 我们需要这个!修复错误!
  5. 所有在 Cruisecontrol.net 上都很好。
于 2009-05-19T12:10:06.607 回答