发布过程改进

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

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

这可能包括

• 二进制文件,
• JAR/战争档案,
• 默认配置文件,
• 数据库方案安装脚本,
• 数据库迁移脚本,
• 操作系统配置脚本,
• 手册/HLP页,
• HTML文档,
• PDF文档

等等。安装程序构建可以将所有这些内容塞进一个可安装的包(InstallShield、Zip、RPM或其他)中,甚至可以构建用于物理分发的CD iso。

安装程序构建的输出通常移交给测试部门。安装包(安装顶部的补丁…)中未包含的内容都是错误。挑战您的开发人员提供无故障安装程序。

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

1. 完全自动化和完整的构建。我们总是在夜间“构建”,但我们发现对于构建的构成有不同的定义。有些人会认为它是编译的,通常人们包括单元测试,有时还有其他事情。我们在内部澄清,我们的自动化构建实际上完成了从源代码控制到交付给客户所需的一切工作。自动化程度越高,流程就越好,当需要发布时,我们需要手动执行的操作也就越少(同时也减少了忘记某些事情的担忧)。例如,我们的构建版本用SVN版本号标记所有内容,用几种不同的语言编译各种应用程序部分,运行单元测试,将编译输出复制到创建安装程序的适当目录,创建实际安装程序,复制安装程序对于我们的测试网络,在测试机器上运行安装程序,并验证新版本是否已正确安装。

2. 代码完成和释放之间的延迟。随着时间的推移,我们逐渐增加了从完成特定版本的编码到该版本交付给客户之间的延迟量。这为测试人员提供了更多的专用时间来测试一个变化不大的产品,并产生更稳定的产品发布。源代码控制分支/合并在这里非常重要,因此开发团队可以在测试人员仍在处理最后一个版本的同时处理下一个版本。

3. 分支机构所有者。一旦我们将代码分支以创建一个发布分支,然后继续为下一个版本处理主干,我们就分配一个旋转的发布分支所有者,负责验证应用到分支的所有修复。每一次登记,无论大小,必须由两个开发人员审查。

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

1)安装工具包和一键式UAT部署

我们使用 NSIS (不是一个微星,它是如此复杂,我们的需要是没有必要的)。这个安装工具包做了所有必要的工作,比如停止IIS、复制文件、将配置文件放在正确的位置、重新启动IIS等。然后我们创建了一个TeamCity构建配置,它使用 psexec .

这使得我们的测试人员可以自己进行UAT部署,只要它们不包含数据库更改——但是这些更改比代码更改要少得多。

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

2)自动化数据库部署

部署数据库更改也是一个大问题。我们已经为所有的数据库更改编写了脚本,但是在知道哪些脚本已经运行,哪些脚本仍然需要运行,以及以什么顺序运行时仍然存在问题。为此,我们研究了几个工具,但最终还是使用了自己的工具。

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

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

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

3)发布分支

这听起来很基本,几乎不值得一提,但我们并不是从一开始就这么做的。合并回更改当然是一件痛苦的事情,但并没有为今天的版本和下个月的版本提供一个单一的代码库那么痛苦!我们还让在发布分支上做出最多更改的人进行合并,这有助于提醒每个人将发布分支的提交量保持在绝对最小值。

自动化的单步构建。Ant构建脚本编辑所有安装程序配置文件、需要更改的程序文件(版本控制),然后构建。不需要干预。

当安装完成后,仍然有一个脚本运行来生成安装程序,但我们将消除这一点。

CD艺术品是手动版本,也需要修复。

同意之前的意见。

这就是我工作的地方所发展的。当前的流程消除了问题中描述的“gotchas”。

我们使用Ant从SVN(按标记版本)中提取代码,并引入依赖项,并构建项目(有时也用于部署)。

每个env(dev、integration、test、prod)使用相同的ant脚本(传递参数)。

项目过程

• 将需求捕获为用户的“故事”(有助于避免对需求的解释产生争论,如果将其表述为与产品的有意义的用户交互)
• 遵循敏捷的原则,这样项目的每一次迭代(2周)都会导致当前功能的演示和一个可发布的(如果有限的话)产品
• 管理整个项目中的发布故事,以了解范围内和范围外的内容(并防止在最后一分钟修复时出现混乱)
• (重复先前的响应)代码冻结,然后仅测试(没有添加的功能)

开发过程

• 单元测试
• 代码签入
• 预定的自动生成(例如巡航控制)
• 完成集成环境的构建/部署,并运行Smoke测试
• 标记代码并与团队沟通(用于测试和发布计划)

试验过程

• 功能测试(例如硒)
• 执行测试计划和功能场景

一个人管理发布过程,并确保每个人都遵守。此外,所有版本在发布前一周进行审查。只有在以下情况下才批准发布:

发布过程

• 批准特定日期/时间的发布
• 审阅发布/回滚计划
• 使用“production deployment”参数运行ant
• 执行数据库任务(如果有的话)(同样,这些脚本可以是版本并标记为用于生产)
• 执行其他系统更改/配置
• 沟通变化

我不知道也不练习SDLC,但对于我来说,这些工具在实现顺利发布方面是必不可少的:

• maven用于构建,与 Nexus 本地存储库管理器
• 用于持续集成、发布构建、SCM标记和构建提升的Hudson
• 声纳的质量指标。
• 跟踪数据库对开发数据库模式的更改,并通过 DbMaintain 和 LiquiBase

在我工作的一个项目中,我们使用条令(php-orm)迁移来升级和降级数据库。我们遇到了各种各样的问题,因为生成的模型不再与数据库模式匹配,导致迁移完全失败。

最后,我们决定编写我们自己的超基本版本——没有什么花哨之处,只是执行SQL的上下版本。不管怎么说,效果很好(到目前为止-摸木头)。虽然我们只是通过自己的写作来重新设计方向盘,但重点是保持简单意味着我们的问题要少得多。现在,释放是一件轻而易举的事。

我想这个故事的寓意是,只要你有充分的理由,有时重新发明轮子是可以的。