发布流程改进

Question

创建新构建并将其发布到生产中的过程是SDLC中的关键步骤,但它通常是事后的想法,并且在公司与下一个公司之间存在很大差异.

我希望人们能够在他们的组织中分享他们对这个过程所做的改进,这样我们都可以采取措施"减轻痛苦".

所以问题是,指定一个痛苦/耗时的发布过程部分,你做了什么来改善它？

我的例子:在之前的雇主中,所有开发人员都在一个公共开发数据库上进 然后,当发布时,我们使用Redgate的SQL Compare从Dev和QA数据库之间的差异生成一个巨大的脚本.

这种方法运作得相当好,但这种方法的问题是: -

1. 包括Dev数据库中的所有更改,其中一些可能仍在"正在进行中".
2. 有时开发人员会做出相互矛盾的更改(在发布生产之前没有注意到)
3. 创建和验证脚本是一个耗时且手动的过程(通过验证我的意思是,尝试清除问题1和问题2).
4. 当脚本出现问题时(例如,运行事物的顺序,例如创建依赖于脚本中但尚未运行的外键记录的记录),需要时间来"调整"它以使其顺利运行.
5. 这不是持续集成的理想方案.

所以解决方案是: -

1. 必须编写对数据库进行所有更改的策略.
2. 命名约定对于确保脚本的正确运行顺序非常重要.
3. 创建/使用工具在发布时运行脚本.
4. 开发人员有他们自己的数据库副本确实反对(所以没有更多'踩到彼此的脚趾')

我们开始这个过程之后的下一个版本更快,问题更少,实际上发现的唯一问题是由于人们违反了规则,例如没有创建脚本.

一旦发布到质量保证的问题得到解决,当发布到生产时,它就非常顺利.

我们应用了一些其他更改(如引入CI),但这是最重要的,总体而言我们将发布时间从大约3小时减少到最多10-15分钟.

Answer 1

尽可能自动化您的发布过程。

正如其他人所暗示的，使用不同级别的构建“深度”。例如，开发人员构建可以直接从存储库生成用于在开发计算机上运行产品的所有二进制文件，而安装程序构建可以组装所有内容以便在新计算机上安装。

这可能包括

• 二进制文件，
• JAR/WAR 档案，
• 默认配置文件，
• 数据库方案安装脚本，
• 数据库迁移脚本，
• 操作系统配置脚本，
• 手册/帮助页面，
• HTML 文档，
• PDF文档

等等。安装程序构建可以将所有这些内容填充到可安装包（InstallShield、ZIP、RPM 或其他）中，甚至构建用于物理分发的 CD ISO。

安装程序构建的输出通常会移交给测试部门。安装包中未包含的任何内容（安装顶部的补丁......）都是一个错误。挑战您的开发人员提供无故障的安装过程。