释放过程改进

Question

创建一个新的构建并将其发布到生产中的过程是SDLC中的一个关键步骤，但它通常是事后考虑的，而且每个公司都有很大的差异。

我希望人们能够分享他们在组织中对这个过程所做的改进，这样我们就可以采取措施来“减轻痛苦”。

因此，问题是，在发布过程中指定一个痛苦的/耗时的部分，您做了什么来改进它？

我的示例:在以前的雇主中，所有开发人员都对一个公共开发数据库进行了数据库更改。然后，当谈到发布时间时，我们使用Redgate的SQL比较来从Dev和QA数据库之间的差异中生成一个巨大的脚本。

这个方法运作得相当好，但问题是：

1. Dev数据库中的所有更改都包括在内，其中一些可能仍然是“正在进行中的工作”。
2. 有时，开发人员会做出冲突的更改(直到发行版开始生产时才会被注意到)。
3. 创建和验证脚本是一个耗时的手工过程(我的意思是，尝试排除问题1和问题2)。
4. 当脚本出现问题时(如运行的顺序，例如创建一个依赖于脚本中的外键记录，但尚未运行的记录)，需要时间来“调整”它，使其顺利运行。
5. 这并不是持续集成的理想场景。

所以解决办法是：-

1. 强制执行数据库所有更改的策略，必须编写脚本。
2. 命名约定对于确保脚本的正确运行顺序非常重要。
3. 创建/使用工具在发布时运行脚本。
4. 开发人员有他们自己的数据库副本，确实是针对的(因此没有更多的“互相踩脚”)。

在我们开始这个过程之后的下一个版本更快，问题更少，实际上唯一发现的问题是人们“违反规则”(如没有创建脚本)。

一旦解决了向QA发布的问题，到了发布到生产的时候，就会非常顺利。

我们应用了一些其他的更改(比如引入CI)，但这是最重要的，总的来说，我们将发布时间从大约3小时降到了最大的10-15分钟。

Answer 1

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

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

这可能包括

• 双星，
• JAR/WAR档案，
• 默认配置文件，
• 数据库方案安装脚本，
• 数据库迁移脚本，
• 操作系统配置脚本，
• man/hlp页面
• HTML文档，
• PDF文档

诸若此类。安装程序构建可以将所有这些填充到可安装的包中(InstallShield、ZIP、RPM或其他任何东西)，甚至可以构建用于物理分发的CD ISO。

安装程序构建的输出通常交给测试部门。安装包中没有包含的内容(安装顶部的补丁.)是个窃听器。挑战您的开发人员交付一个无故障安装过程。

Answer 2

在过去的一年中，我们做了一些事情来改进我们的构建过程。

1. 全自动和完整的构建。我们一直有一个夜间的“构建”，但我们发现，对于什么构成构建，有不同的定义。有些人会认为它是编译的，通常包括单元测试，有时还包括其他东西。我们在内部澄清说，我们的自动化构建实际上完成了从源代码管理到交付给客户的一切所需的工作。我们对各个部分的自动化程度越高，这个过程就越好，在发布的时候，我们需要手动完成的工作就越少(并且对忘记一些东西的担忧也越少)。例如，我们的构建版本用svn修订号标记所有内容，编译用几种不同语言完成的各种应用程序部件，运行单元测试，将编译输出复制到创建安装程序的适当目录，创建实际安装程序，将安装程序复制到测试网络，在测试机器上运行安装程序，并验证新版本是否正确安装。
2. 代码完成和发布之间的延迟。随着时间的推移，我们逐渐增加了从完成特定版本的编码到该版本到达客户之间的延迟量。这为测试人员提供了更多的时间来测试一个变化不大并产生更稳定的生产版本的产品。源代码管理分支/合并在这里非常重要，因此开发团队可以在下一个版本上工作，而测试人员仍在处理最后一个版本。
3. 分行老板。一旦我们将代码分支到创建发布分支，然后继续为下面的发行版工作主干，我们将指定一个旋转的发布分支所有者，负责验证应用到该分支的所有修复。每一个签入，无论大小，都必须由两个开发人员进行检查。

Answer 3

我们已经使用TeamCity (一个优秀的持续集成工具)来进行构建，其中包括单元测试。提到了三大改进：

1)安装工具包和单击UAT部署

我们使用NSIS (而不是MSI )将我们的应用程序打包成一个安装工具包(这比我们的需要复杂得多，也没有必要)。这个安装工具包完成了一切必要的工作，比如停止IIS、复制文件、将配置文件放在正确的位置、重新启动IIS等等。然后我们创建了一个TeamCity构建配置，它使用psexec在测试服务器上远程运行安装工具包。

这允许我们的测试人员自己进行UAT部署，只要它们不包含数据库更改--但这些更改要比代码更改少得多。

当然，生产部署涉及得更多，我们无法实现如此多的自动化，但我们仍然使用相同的安装工具包，这有助于确保UAT和生产之间的一致性。如果有任何东西丢失或没有复制到正确的地方，它通常是在UAT捡到的。

2)自动化数据库部署

部署数据库更改也是一个大问题。我们已经在编写所有DB更改的脚本，但在知道哪些脚本已经运行、哪些脚本仍然需要运行以及按什么顺序运行方面仍然存在问题。我们看了几个这样的工具，但最后却是自己的工具。

DB脚本是按发布号组织在目录结构中的。除了脚本开发人员还需要将脚本的文件名添加到文本文件中，每一行一个文件名，这指定了正确的顺序。我们编写了一个命令行工具，它处理这个文件并对给定的DB执行脚本。它还记录了在DB中的特定表中运行了哪些脚本(以及何时)，下一次没有再次运行这些脚本。这意味着开发人员可以简单地添加DB脚本，将其名称添加到文本文件中，并针对UAT运行该工具，而无需询问其他人他们最后运行的脚本。我们在生产中使用了相同的工具，但当然每个版本只运行一次。

真正使此工作良好的额外步骤是将DB部署作为构建的一部分运行。我们的单元测试针对的是一个真实的DB (一个非常小的DB，数据最少)。构建脚本将从上一个版本恢复DB的备份，然后运行当前版本的所有脚本，并进行新的备份。(实际上，这有点复杂，因为我们也有补丁版本，备份只为完整的版本完成，但是这个工具足够聪明来处理这个问题。)这确保了在每次构建时都会对DB脚本进行测试，并且如果开发人员进行了冲突的模式更改，它将很快被捕获。

惟一的手动步骤是在发布时:我们增加了构建服务器上的发布号，并复制了“当前DB”备份，使其成为“最后一个版本”备份。除此之外，我们不再需要担心构建所使用的DB。UAT数据库仍然偶尔不得不从备份中恢复(例如。因为系统无法撤销对已删除的DB脚本的更改)，但这是相当罕见的。

3)发布的分支

这听起来基本，几乎不值得提及，但我们并没有这样做的开始。将更改合并起来当然是一种痛苦，但不像今天和下个月发布的代码库那样痛苦！我们还得到了在发布分支上进行最多更改的人来进行合并，这有助于提醒每个人保持他们的发布分支提交的绝对最小。