贵公司如何部署其软件？答案

【问题标题】：How does your company deploy its software?贵公司如何部署其软件？
【发布时间】：2014-09-21 02:16:54
【问题描述】：

我目前正在进行一个短期研究项目。我工作的公司有一个非常繁重的发布过程，随着时间的推移变得越来越糟。我们在每个版本中遇到越来越多的问题，这开始严重影响我们的交付计划和每个版本的质量。我们提供了一个大型 SAAS 产品，该产品部署在一个非常大的网络场上的 Internet 上。我们的部署过程目前由一个专门的团队处理，开发人员参与最少。我们主要是一家 .NET 商店，但我们也有几个 Java 组件。

我正在研究如何改进 QA 和部署流程，以减少浪费并将更多流程置于我们的开发团队的掌控之下。我有兴趣了解贵公司如何将您的产品（最好是 SAAS，但不限于此类产品）部署到生产中，以及在那里进行测试的过程。我很好奇什么有效，什么无效，我相信你们中的许多人都有故事要讲。

编辑（附加 RFC）：

在我继续研究的过程中，我发现了“持续部署”的概念，这显然是由 IMVU 3d 在线社区团队率先提出的。这听起来像是一个有趣的概念，虽然可能有点复杂。我很好奇 SO 上的任何人是否有持续部署的经验？特别是对于一个包含许多部分的大型复杂项目。您不一定必须不断地部署到生产环境中……为了我们的短期需求，我们只会考虑持续部署到内部 dev/qa/perftest 环境。如果有人实施了持续部署，我也很想知道您是如何管理数据库架构和数据更改/回滚的。

谢谢！

【问题讨论】：

标签： .net

【解决方案1】：

我们将金融服务 SaaS 解决方案部署到 Amazon AWS 云环境。我们的解决方案是 100% Java，因此许多工具不适用于您，但概念应该适用。

首先，我们通过运行持续集成流程来减少发布时的意外数量。任何时候任何开发人员签入源代码，整个解决方案都会自动构建，所有单元测试都会自动运行。失败通知会通过电子邮件发送给相关开发人员和团队负责人。

AWS 是围绕虚拟机的概念构建的。我们通过创建一个虚拟机映像（亚马逊称它们为 AMI）来利用这一点，其中包含我们想要的特定版本的操作系统和应用程序（Java、DB 等）。构建过程会创建所有可部署的工件，然后将它们复制到基于该 AMI 的运行实例。对于所有环境（TEST、DEMO、PROD）来说，这都是完全相同的过程，除了封装版本差异（例如连接字符串）的单个配置项目。

QA 在 TEST 环境中测试结果。一旦他们批准了版本，我们就重复针对 PROD 的构建过程（使用完全相同的版本控制修订。请记住，每个环境之间的唯一区别是一个配置项目）。

此时，我们使用 PROD 代码库创建一个在基础 AMI 上运行的虚拟机（实例），并将其称为 STAGING。 STAGING 经历了一系列自动和手动的验收测试。这是非常好的部分......现在，我们将这个环境（基础 AMI 加上我们应用程序的新版本）刻录到 new AMI（虚拟机映像）中。然后我们基于这个新镜像创建应用服务器的新运行实例，更新负载均衡器以指向这些新实例，然后杀死旧实例。这就是使用虚拟机的美妙之处（至少，这是美妙之处之一）。

每当我们需要调整容量（高峰时段/天数）时，我们都会从同一个生产 AMI 创建新的应用服务器实例，并将它们注册到负载均衡器。当峰值结束时，我们只需将它们从负载平衡轮换中移除，然后在几分钟后终止额外的实例（以允许现有会话完成）。

【讨论】：

感谢您的详细解答。听起来帮助您的关键是使用虚拟机。我们正在评估的产品之一是 VMware Lab Manager。根据我收集到的关于 AMI 的信息，它具有相同的基本目的……基于模板的虚拟机。我想主要区别在于它将由我们在我们自己的硬件上托管。很高兴听到虚拟化已成功使用（并在云中启动！）的场景
我也问过 jamiedp 这个问题，但是你的应用程序有多大？你会把它分为小型、中型、大型还是大型？这与代码库的大小、配置数量和平均用户数量有关。谢谢！
@jrista：我想这取决于你如何定义这些尺寸，但大的声音是正确的。该应用程序相当复杂，广泛使用企业技术，并支持相当高的交易量。
大小作为代码库大小、配置量、用户数/平均负载等的一种合并。对项目整体大小的粗略估计。我想这有点难以解决，这就是为什么我让它有点随意（小/中/大/巨大）。谢谢你的信息，顺便说一句。我们对您在超虚拟化方面的成功很感兴趣，因为这是我们正在研究的关键问题之一。我们决定使用 VMWare Lab Manager 作为这项新计划的关键组件。现在我们只需要改进实际的构建和部署过程。
您可能想看看这个源于 UCSB 研究项目的倡议。它提供了一个（大部分）与亚马逊兼容的免费云环境。我们想研究它来管理开发/测试环境，但还没有时间。 eucalyptus.com

【解决方案2】：

我们有一个 SaaS 解决方案，并且基本上使用与上述 Eric 相同的流程（持续集成服务器、用于测试-暂存-生产的部署脚本），但我们使用基于 PSTools 的自定义脚本将其部署到我们自己的基础架构 (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx ) 将所有复制到场节点。

对于每次部署，我们都会评估是否允许不同节点拥有不同版本的应用程序（即没有数据完整性风险），或者我们必须让应用程序离线几秒钟以同步所有节点（通常应用程序需要大约 20 秒才能重新上线，因为它只是从一个主节点处理应用程序）；但关键是要有一个“一键式”部署过程设置。

【讨论】：

出于好奇，您的应用程序有多大？你会把它分为小型、中型、大型还是大型？谢谢。 :)
我上一条评论中的问题是关于代码库的大小、配置的数量和平均用户数。谢谢。
整个套件大约有 0.4M 行代码，分为几个组件（前端、Web 服务、dal 等），我们可以独立部署，尽管我们通常不这样做。就配置而言，所有配置更改都由我们的部署脚本管理/更改......并且基本上是对连接字符串、服务引用的更改，这些更改在主节点上准备并在每个节点上调整至于用户数，我们大约有 10,000 个注册用户，白天我们有大约 300 个活跃会话，我们总是尝试在低挑选时间部署，如果我们有 10~15 个会话
感谢您的信息。我想我会把你们归类为中等，根据你给我的数字。（我们有一个包含数千万行代码的代码库，涵盖了旧版、旧版和新版，有成千上万的并发用户......我们陷入了大/巨大的舞台。）我有点好奇到底是如何您使用 PSTools 进行部署。你能澄清一下吗？
当然：CC 服务器从适当的 prod 分支生成构建，并执行打包应用程序并将 zip 复制到从 prod 节点可见的共享网络驱动器的 nant 脚本，执行使用 psexec 在主生产节点上部署 Nant 脚本，之后，主 prod 节点将应用程序本地复制并解包到 prod 网络本地的网络共享，修改配置文件，并在每个复制的节点上执行一个 nant 脚本应用在本地，调整配置并部署到 IIS（无论是否使应用离线）希望这会有所帮助

【解决方案3】：

您不是说是什么导致您的版本出现问题吗？我们遇到了问题，因为错误的文件最终出现在我们的构建中。我们对此的回答是构建一个工具，让我们可以控制和查看构建中的所有文件。 Here 是我们构建的工具的网络广播。

【讨论】：

不完全确定具体是什么导致了问题。我们知道其中一部分与我们的构建脚本的工作方式有关，而且我们的构建脚本与源代码控制的特定文件夹结构和分支结构紧密耦合。我们认为我们遇到的另一个问题是流程过多，每个版本都需要很多人参与。我们知道我们需要精简流程……但我们没有一个基准“良好的部署流程”可供比较。
您提供的链接上的网络广播似乎已损坏。它开始播放几秒钟，然后停止。

【解决方案4】：

免责声明：我可能会出售我写的东西，但目前它是免费的（而且还没有正式发布）。

我们使用我编写的系统。

它通过与您的源代码控制和 CI 服务器集成来运行。它允许我将代码提交到 SVN，等待构建服务器上的构建，然后，通过应用程序界面，将其配置为特定构建，将其返回提交到源代码管理中，然后，在服务器上，它将更新。美妙之处在于您可以更新异步，因此所有服务器将几乎同时获得新版本。

它比这要复杂一些，并且需要某种特定的设置方式，但它在运行时确实非常漂亮（在我非常偏颇的观点中）。如果您想要一个免费的“alpha”版本，请给我发电子邮件。它的任何测试版也都是免费的。

-- 编辑：

一般流程：

提交到主干
等待来自 CI 服务器的构建，构建是“裸露的”（未为任何服务器配置）
使用工具（“dashy”）将构建部署到测试服务器
测试
对测试感到满意
将构建（相同构建）部署到实时服务器

“部署”阶段包括提交到 SVN，然后程序（也安装在您的 Web 服务器上）从 SVN 获取构建。

实际上，我在您的标准 SVN 结构中添加了一个新的“基本”级别项目。你通常有：

/trunk
/braches
/tags

用dashy，我加/releases

/trunk
/braches
/tags
/releases

【讨论】：

那么，这是一个先发制人的构建系统，它会在代码提交之前拦截签入和构建（如 TeamCity？）我不确定我是否完全理解它的作用......
谢谢。听起来不错。我很好奇你是否听说过 TeamCity？那是我正在评估的另一个 CI 产品。 TC 的有趣之处在于它会抢先拦截源代码管理的签入、构建和验证，并且只有在构建和验证成功时才将签入提交给源代码管理。否则，违规者会在闭环中收到通知，并且您不会遇到错误代码命中任何分支的问题。我不确定它支持哪种部署方案，但无论如何部署都可以由构建脚本处理。 jetbrains.com/teamcity
粗略看来，TeamCity 将与 CruiseControl 在一般 dashy 过程中的位置相同（即作为构建服务器）。几天后，我将在我的个人资料中添加一些指向 dashy 的链接，并对其工作原理进行更深入的概述（请使用 alpha 版本进行测试：）
TeamCity 与 CruiseControl、TFS Build 等其他 CI 工具之间的一个区别是，TeamCity 在代码到达源代码控制系统之前进行构建。这可以防止无法验证的代码实际上被签入并破坏从该点开始同步的所有其他人，直到构建被修复。它最大的优势和最大的卖点，就是IMO。如果您正在构建 CI 服务器，我强烈建议您研究它，因为我认为它是自动化构建的未来方式。
jrista：可以肯定的是，这不是一个坏特性，但顺便说一句，我不是在构建 CI 服务器。 dashy 将愉快地坐在 TeamCity 或 CruiseControl 或任何其他“构建”服务器之上。它与他们一起工作。