12

创建新版本并将其发布到生产环境的过程是 SDLC 中的关键步骤，但它通常是事后才想到的，并且从一家公司到另一家公司差异很大。

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

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

我的例子：在以前的雇主那里，所有开发人员都在一个通用开发数据库上进行了数据库更改。然后到了发布时间，我们使用 Redgate 的 SQL Compare 从 Dev 和 QA 数据库之间的差异中生成了一个巨大的脚本。

这工作得相当好，但这种方法的问题是： -

  1. 开发数据库中的所有更改都包括在内，其中一些可能仍在“进行中”。
  2. 有时开发人员会做出相互冲突的更改（直到发布投入生产时才注意到）
  3. 创建和验证脚本是一个耗时且手动的过程（通过验证我的意思是，尝试清除问题 1 和 2 之类的问题）。
  4. 当脚本出现问题时（例如，运行的顺序，例如创建依赖于脚本中但尚未运行的外键记录的记录）需要时间来“调整”它以便顺利运行.
  5. 这不是持续集成的理想场景。

所以解决方案是： -

  1. 强制执行对数据库的所有更改的策略必须编写脚本。
  2. 命名约定对于确保脚本的正确运行顺序很重要。
  3. 创建/使用工具在发布时运行脚本。
  4. 开发人员拥有自己的数据库副本进行开发（因此不再有“互相踩脚”）

我们开始这个过程后的下一个版本更快，问题更少，确实发现的唯一问题是由于人们“违反规则”，例如没有创建脚本。

一旦发布到 QA 的问题得到解决，当发布到生产时，它就非常顺利了。

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

4

7 回答 7

3

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

1) 安装套件和一键式 UAT 部署

我们使用NSIS将我们的应用程序打包为安装工具包（不是 MSI，这对于我们的需求来说更加复杂和不必要）。这个安装工具包做了所有必要的事情，比如停止 IIS、复制文件、将配置文件放在正确的位置、重新启动 IIS 等。然后我们创建了一个 TeamCity 构建配置，它使用psexec在测试服务器上远程运行该安装工具包。

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

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

2) 自动化数据库部署

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

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

真正使这项工作顺利进行的额外步骤是将数据库部署作为构建的一部分运行。我们的单元测试针对的是一个真实的数据库（一个非常小的数据库，数据最少）。构建脚本将从先前版本恢复数据库备份，然后运行当前版本的所有脚本并进行新备份。（实际上它有点复杂，因为我们也有补丁版本，并且只对完整版本进行备份，但该工具足够智能来处理这个问题。）这确保了 DB 脚本在每次构建时都经过测试，并且如果开发人员进行了相互冲突的架构更改，它将很快被采纳。

唯一的手动步骤是在发布时：我们在构建服务器上增加发布号并复制“当前数据库”备份以使其成为“最后发布”备份。除此之外，我们不再需要担心构建使用的数据库。UAT 数据库仍然偶尔需要从备份中恢复（例如，因为系统无法撤消已删除数据库脚本的更改），但这种情况相当罕见。

3) 分支发布

这听起来很基本，几乎不值得一提，但我们一开始并没有这样做。合并更改肯定会很痛苦，但不如为今天的版本和下个月的版本拥有一个单一的代码库那么痛苦！我们还让对发布分支做出最多更改的人进行合并，这有助于提醒每个人将发布分支的提交保持在绝对最低限度。

于 2010-05-05T00:21:04.757 回答
3

在过去一年左右的时间里，我们做了一些事情来改进我们的构建过程。

  1. 完全自动化和完整的构建。我们一直都有一个夜间“构建”，但我们发现对于构建的构成有不同的定义。有些人会认为它是编译的，通常人们包括单元测试，有时还有其他东西。我们在内部澄清说，我们的自动化构建确实完成了从源代码控制到我们交付给客户的一切所需的一切。我们对各个部分进行的自动化越多，流程就越好，在发布时我们必须手动执行的操作就越少（并且更少担心忘记某些内容）。例如，我们的构建版本使用 svn 修订号标记所有内容，编译以几种不同语言完成的各种应用程序部分，运行单元测试，将编译输出复制到适当的目录以创建我们的安装程序，

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

  3. 分店老板。一旦我们将代码分支以创建发布分支，然后继续在主干上为下一个版本工作，我们会分配一个轮换发布分支所有者，负责验证应用于分支的所有修复。每次签到，无论大小，都必须由两名开发人员审核。

于 2010-04-23T02:25:47.147 回答
2

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

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

这可能包括

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

等等。安装程序构建可以将所有这些内容放入一个可安装的包（InstallShield、ZIP、RPM 或其他），甚至构建 CD ISO 以进行物理分发。

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

于 2010-05-06T08:04:53.920 回答
1

自动单步构建。ant 构建脚本编辑所有安装程序配置文件，需要更改（版本控制）的程序文件，然后构建。无需干预。

完成后仍然会运行一个脚本来生成安装程序，但我们将消除它。

CD 插图是手动版本的；这也需要修复。

于 2010-04-23T02:19:33.623 回答
1

同意之前的评论。

这是我工作的地方发生的变化。当前的流程消除了您在问题中描述的“陷阱”。

我们使用 ant 从 svn 中提取代码（按标签版本）并引入依赖项并构建项目（有时也进行部署）。

每个环境（开发、集成、测试、产品）使用相同的 ant 脚本（传递参数）。

项目流程

  • 将需求捕获为用户“故事”（当被表述为有意义的用户与产品的交互时，有助于避免对需求解释的争论）
  • 遵循敏捷原则，以便项目的每次迭代（2 周）产生当前功能的演示和可发布（如果有限）的产品
  • 管理整个项目的发布故事以了解范围内和范围外的内容（并防止在最后一刻修复时出现混淆）
  • （重复之前的回复）代码冻结，然后只测试（没有添加功能）

开发流程

  • 单元测试
  • 代码签入
  • 预定的自动化构建（例如巡航控制）
  • 完成构建/部署到集成环境，并运行冒烟测试
  • 标记代码并与团队沟通（用于测试和发布计划）

测试过程

  • 功能测试（例如硒）
  • 执行测试计划和功能场景

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

发布流程

  • 批准特定日期/时间的发布
  • 查看发布/回滚计划
  • 使用“生产部署”参数运行 ant
  • 执行数据库任务（如果有的话）（此外，这些脚本可以是版本并标记为生产）
  • 执行其他系统更改/配置
  • 沟通变化
于 2010-05-05T02:58:48.437 回答
0

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

最后，我们决定编写我们自己的超级基本版本——没有什么花哨的，只是执​​行 SQL 的 up's 和 down's。无论如何，它的效果很好（到目前为止 - 触摸木头）。尽管我们通过编写自己的方法来稍微重新发明轮子，但重点是保持简单，这意味着我们遇到的问题要少得多。现在发布是小菜一碟。

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

于 2010-05-09T11:24:49.490 回答
0

我不了解或不实践 SDLC，但对我来说，这些工具对于实现顺利发布是必不可少的：

  • 用于构建的 Maven，带有Nexus本地存储库管理器
  • Hudson 用于持续集成、发布构建、SCM 标记和构建推广
  • 用于质量指标的声纳。
  • 跟踪数据库对开发数据库模式的更改，并通过DbMaintain和LiquiBase管理对 qa 和发布的更新
于 2010-05-05T03:25:00.897 回答