continuous-integration - 如何处理CI

Question

我正在从头开始建立公司(Tomcat + Spring Rest + Java)，因此我们有能力做正确的事情(或者列表中不要重复过去的错误)，我们想要实现的目标之一是自动构建，测试(单元，集成)和部署的能力。

我们的平台由一个静态HTML/JS接口(interface)站点和NGiNX服务以及一些API服务器(不同的应用程序)构建而成，其中一些服务器是公开的，而某些服务器只能由公开的API应用程序从服务器场中访问。

我已经选择TeamCity作为CI服务器，因为我对它有些熟悉，并且到目前为止，我对Jetbrain的所有产品都拥有出色的经验。

到目前为止，我已经定义了两个构建配置

开发健全性:从git中 checkout ，运行DB脚本以准备数据库，执行全新安装的maven目标(因此我们的testng套件正在执行)，执行代码覆盖率和静态代码分析
此配置正在执行并且很棒。

集成:从git中 checkout ，运行DB脚本以准备数据库，执行全新安装的maven目标(因此我们的testng套件正在执行)

现在我已经到了有问题的部分，在我们的集成测试开始之前，我们的配置需要将多个.war文件部署到不同的机器上，我也希望以此方式构建它，以便能够添加第三个配置一旦集成通过，它将部署到实时生产中，因此它基本上与第二个配置相同，但是增加了一些功能，例如，将应用程序正常部署后，将其关闭并放回在线状态，我已经看到了几种方法这
来自Maven cargo ， shell 脚本，织物等...

有没有建议的方法，可以根据您过去的经验来处理此图纸？
我也不清楚，最好的运行集成测试的最佳方法是什么，该测试涉及要部署的多个应用程序，我已经看到了许多嵌入式码头等示例。但这仅适用于一个应用程序或需要时非常简单的配置在开始测试之前要部署的3-4个应用程序，最好的方法是什么？添加另一个专用于集成测试的项目，并在部署完成后使用特定的配置文件执行另一个maven目标？

BTW-部署到AWS

谢谢你们 。

Answer 1

首先，我强烈建议您阅读持续交付(Jez Humble，David Farley)，它提供了很多有关此方面的信息。有一个sample chapter here。

自从阅读本文以来，我已经开始构建一个构建管道，其中每个对svn的提交都贯穿管道的每个阶段，随着构建的进行，环境逐渐变得更像生产。我们为此使用 Jenkins 。

提交阶段-开发健全性-编译，单元测试和一些指标。这
初始阶段还会构建其余版本所需的二进制文件
管道

集成阶段-该文件与
上一阶段(不是新结帐)，并在
内存

自动化验收测试阶段-从
提交阶段并部署到我们运行 Selenium 测试的服务器

QA阶段-由qa部署，他们只需单击一个按钮即可拉出
无论他们想要什么构建，它都会再次部署二进制文件
从提交阶段到质量检查服务器

UAT -与质量检查相同，但更像生产环境，我们也进行性能测试

生产-将二进制文件从提交阶段部署到生产。

这些阶段中的每个阶段都充当“质量门”-在达到一定阈值之前，不允许构建进一步进行-测试失败，度量标准％s等。某些阶段会自动流过，其他阶段则是手动触发的。每种环境所需的任何配置更改都可以通过解压缩原始二进制文件，更改设置，再次打包来完成-理想情况下，我想将配置与应用程序二进制文件分开，但尚未找到实现此目的的方法。

自动化验收测试阶段仅更新服务器上的现有应用程序-qa阶段完成了停止，卸载，安装和启动操作。每个脚本都运行不同的脚本-ant和python的组合。

Here's使用构建管道插件在jenkins中的管道是什么样子。

[编辑]

实际上，您不必一口气实现此步骤的每个阶段，每个阶段都有占位符很容易，而无需进行任何实际操作就可以直接进入下一个阶段。如果您映射当前流程，则应该能够使流程的一部分自动化并逐步移向管道。

提交阶段最容易完成，基本上就是您要设置普通的CI服务器，创建项目，将其挂接到版本控制，编译，执行测试以及运行所有来自ant/maven任务的统计信息。这需要5分钟多一点的时间才能运行。

stats任务花费的时间太长(超过15分钟)，因此我在提交时运行了一个子集，并且每晚进行一次运行，它运行了很多Findbugs，PMD，Checkstyle和Cobertura。我宁愿在提交时运行所有这些，但这将需要更多的硬件和工作来建立某种构建网格。

Selenium测试目前不在一个单独的项目中，但它们打包为一个单独的jar，可以通过jenkins的“复制工件”插件提供给自动验收测试阶段-ant/python脚本打包了WAR文件并部署到容器中，然后 Ant 解压并运行Selenium测试(通过junit)。目前只有少量的“烟雾测试”，它们与主要的WAR无关，尽管我可能会看到这种变化。我实际上不喜欢为代码和测试创建单独的项目的想法-构建脚本只是打包了主项目中每个模块所需的类和库-对于您的情况(很快，就是我们的情况)，您可能必须要做一些事情不同-如何用所需的配置启动一两个VM并部署到该虚拟机。 (有关此信息，请参见“持续交付”书中的很多信息)

Jenkins 通过插件支持很多这样的情况是一件好事-我们从Atlassian Bamboo移走了，因为我们想要的大多数东西都不可用，并且现有的插件要么不起作用，要么与Bamboo版本不兼容。我已经有一段时间没有使用Team City了，所以我不知道它是否支持这种'pipeline' [aparently not]的想法。 “构建管道”插件是一个相当新的插件，具有一些粗糙之处，但仍处于积极开发中-我认为可以通过Jenkins的“高级构建”和试金石构建来做到这一点，但尚未尝试过。如果您有足够的资源(钱!)，您可能需要看看 Go