今天，我们将在关于 jelastic 的 devops 方法实施的博客系列中继续讨论项目的交付自动化（如果您刚刚加入我们，您将需要熟悉 本指南的第一部分 – 它会让您深入了解我们的工作）。简而言之，我们的目标是在其所有阶段实现应用程序生命周期管理的完全自动化，从而能够完全专注于新项目功能的开发过程，而不是费心控制它进一步的部署、测试、转移到合适的硬件等。

之前，我们已经为这个任务准备了背景（分配给每个团队的不同硬件集，配置了jenkins持续集成服务器和一些用于部署行为管理的脚本），现在我们已经具备了继续进行所需的一切。因此，让我们继续并配置所需的 jenkins 作业，以便随后将所有这些作业组合成一个连续的流程。

创建詹金斯工作

我们将从配置一组作业开始，它代表了我们自动化的核心。它们中的每一个都将专门用于特定的操作，需要在项目生命周期的相应阶段运行。提醒一下——这里是建议的流程链：

创建环境 > 构建和部署 > 开发测试 > 迁移到质量检查 > 质量检查测试 > 迁移到生产环境

我们将一一添加所有这些工作。因此，一些初始步骤对所有这些步骤都是相似的：

单击左侧菜单中的 新项目 选项。

在出现的表格中，指定 项目名称 并使用相应的单选按钮选择适当的项目类型（这些设置将在下面的每个作业中详细描述）：

然后单击 “确定” 继续配置相应的项目。

创造环境

create environment – freestyle project ，根据指定的安装脚本创建一个新环境。

找到 构建 部分，展开 添加构建步骤 列表并在那里选择 执行 shell 选项。然后在出现的字段中输入以下命令：

echo “run build $(date)” >> /opt/tomcat/demo/ build.log

/bin/bash /opt/tomcat/demo/ install.sh {dev_user}@example.com {密码}

在哪里

/opt/tomcat/demo/ – 上面创建的脚本文件夹的路径（这是我们用作示例的那个，如果不同，您应该用自己的路径替换它）

注意： 相同的路径将用于所有其他作业，因此我们将在接下来的说明部分中跳过这一点——请不要忘记在所有相应的命令中指定它

{dev_user}@example.com – 您的开发团队帐户的登录名（电子邮件地址）

{password} – 相应用户的密码

注意： 如果您的帐户名包含任何特殊字符，则应使用 url 编码 替换它们。

保存 以创建作业。

构建和部署

build and deploy – maven project ，它将构建您的源代码并通过已添加的 maven 节点部署应用程序。

找到 源代码管理 部分，选择项目的 vcs 类型（我们在本教程中使用 git repo 和一个简单的 helloworld 应用程序）并在扩展字段中指定 存储库 url 。

稍微低一点，在 构建环境 部分， 通过文件选项勾选设置环境变量 ，并键入为此目的创建的相应文件的路径（在 上 一个 jenkins 容器配置说明的最后一步） 指导 ）。

然后，向下滚动以 发布步骤 并单击 添加构建后步骤 可扩展列表，您需要在其中选择 调用顶级 Maven 目标 选项。

在 maven 版本 列表中的建议变体中，选择您在 jenkins 配置期间创建的变体（在我们的例子中命名为 maven ），并使用以下命令填写 目标 字段：

全新安装 jelastic:deploy

注意： 这样做是因为我们项目的 pom.xml 文件已经包含了 jelastic maven 插件 ，旨在将已经构建的 .war 文件自动部署到我们的环境中。您可以使用链接的指南以相同的方式调整您自己项目的部署，或者，如果您想测试自动化本身，只需分叉我们的 repo 并修改主 maven 配置文件中的以下字符串（即上面提到的 pom.xml ）根据您的数据：

• {dev_user} @example.com – 开发 用户 帐户的登录名（电子邮件地址）
• {password} – 上面指定的用户密码
• {cloud_domain} – 您的 jelastic 平台的域名

点击 保存 完成。

开发测试

开发测试 —— 自由式项目 ，旨在运行第一组测试，仍处于开发阶段。

在 构建 部分中选择 执行 shell 选项并声明以下命令：

echo “运行测试 $(date)” >> /opt/tomcat/demo/ build.log

/bin/bash /opt/tomcat/demo/runtest.sh

保存 以添加此作业。

迁移到质量检查

迁移到 qa – freestyle 项目 ，这会将您的环境的所有权传递给 qa 团队，并将其实际移动到他们的专用硬件集。

滚动到 构建 部分，再次选择 执行 shell 选项并在出现的字段中输入以下命令：

echo “run build $(date)” >> /opt/tomcat/demo/ build.log

/bin/bash /opt/tomcat/demo/transfer.sh {dev_user}@example.com {password} {qa_user}@example.com

/bin/bash /opt/tomcat/demo/ migrate.sh {qa_user}@example.com {密码} {destination_hn_group}

在哪里

• {dev_user}@example.com – 您的开发团队帐户的登录名（电子邮件地址）
• {qa_user}@example.com – 与 qa 团队帐户相同
• {password} – 相应用户的（在此之前指定的）密码
• {destination_hn_group} – 硬件集的唯一名称，迁移应该执行到（可以在您的 jca > cluster > regions 部分看到）

保存 完成。

质量检查测试

qa 测试 – 自由式项目 ，用于在测试阶段运行自动化应用程序检查。

注意 ：在我们的例子中，这项工作的配置与 开发测试 完全相似。然而，在真正的开发过程中，这些测试集可能会有所不同——在这种情况下，您需要在此处指定另一个专用的 bash 脚本。

迁移到生产环境

migrate to production – freestyle 项目 ，类似于 migrate to qa one，它将环境所有权从 qa 转移到生产团队，并将其物理迁移到相应的硬件集。

伟大的！现在一切都准备好了，因此我们可以检查我们的方案是否正常。

ñ连续的人工检查

让我们看看我们添加的每个 jenkins 作业是如何工作的。为此，我们将根据下面提到的流程一一运行它们：

创建环境 > 构建和部署 > 开发测试 > 迁移到质量检查 > 质量检查测试 > 迁移到生产环境

要执行特定项目，请单击它旁边的三角形图标，然后在显示的上下文菜单中选择 立即构建 选项：

可以通过 jenkins 输出（特定构建的上下文菜单中的 控制台输出 选项）或使用 jenkins 容器中的适当 日志文件 来跟踪处理每个作业的进度。

在下面，您将找到使用我们的脚本后的预期结果列表：

创造环境

等到该过程完成并检查您的 开发用户 帐户。

如您所见，新环境已与已经运行的 jenkins 项目一起成功创建。

构建和部署

在此阶段，maven node 基于源构建 .war 文件，提供 vcs repo 链接。

注意： 在第一次启动时会下载所需的依赖项，因此此部署可能需要一些时间。

结果，您的项目将成功构建并部署到环境中。

开发测试

在我们的示例中，此作业只是模拟一些活动以实现正确的工作流表示，但是在运行真实测试时，可以通过 控制台输出 部分查看它们的结果（可通过仍在处理或最后完成的特殊菜单访问）手术）。

我们的 qa 测试 结果与这些类似，并且可以用相同的方式进行跟踪，因此我们将跳过下面的这一步。

迁移到质量检查

等到该过程完成并登录到您的 质量检查团队 帐户。

你会看到你的环境出现在它的仪表板上，自动从 开发用户的 帐户转移（由于使用的脚本不需要手动确认）并同时物理地重新定位到 测试 硬件（根据区域标签，在图像中圈出）多于）。

迁移到生产环境

最后一步是将经过完善、全面测试和随时可用的项目交付给客户。

与之前的迁移操作类似，分两步完成：转移所有权和将项目移动到相应的生产硬件上。

一旦我们确保所有步骤都成功执行而没有任何错误，就可以通过将所有作业链接到一个自动化的工作流程中来进一步改进整个过程。为了更方便，我们将使用一个特殊的作业启动触发器，它在每个项目提交操作时执行——这将有助于完全排除依赖于人为的延迟并加快每个新发布周期的通过。

devops 方法自动化

正如我们上面所指出的，持续集成假定完整的流程自动化，不涉及任何手动步骤。在我们的案例中，这将导致在对您的项目进行每次重大更改时创建一个新环境，并伴随检查，它是否按预期工作并立即交付给目标受众。

因此，为了实现如此紧密的操作集成，所有这些都构成了 devops 管道，让我们将我们的工作组合成一个序列。

我们链中的第一个元素是 创建环境 ，因此展开它的上下文菜单并选择 配置 选项。

在打开的框架中，向下滚动到页面末尾，然后在 构建后操作 部分中选择 构建其他项目 选项：

在出现的字段中，说明我们链的下一个元素（即在这种情况下 构建和部署 ）。

对所有其余作业重复这两个步骤（显然，除了最后一个 迁移到生产的 作业），直到创建周期。提醒一下，这是我们建议的工作流程：

创建环境 > 构建和部署 > 开发测试 > 迁移到质量检查 > 质量检查测试 > 迁移到生产环境

构建链后，剩下要做的最后一件事就是定义启动我们循环的起始点。

为此，首先您需要获取 创建环境 作业调度程序的 url——右键单击相应的图标并选择 复制链接地址 选项。

我们将使用接收到的值来设置适当的 githook ，绑定到提交操作。因此，打开你的 vcs 项目的设置（在我们的例子中放置在 github 上）并导航到 webhook 部分（或类似的部分，根据使用的存储库存储）。

在这里，你需要：

• 将复制的链接粘贴到 有效负载 url 字段
• 在 内容类型 下拉列表中选择 application/x-www-form-urlencoded 选项
• 删除 秘密 （如果有说明）
• 在事件部分选择 让我选择单个事件 项并勾选 提交注释 行

使用下面的 添加 webhook 按钮完成。

最后，一切都已设置好并进行了最大限度的优化！现在，只需对您的项目进行任何更改并享受新构建过程的完全自动化过程，该过程从环境创建开始，到生产阶段已经运行的新应用程序结束。

请继续关注 jelastic，以免错过 devops 文章系列的下一部分，我们将在其中揭示如何实现更多自动化并只需单击几下即可实施上述所有步骤！如果您想成为我们重要的合作伙伴之一并从所描述的方法中获益，请先 评估我们的演示平台 或 注册免费的两周试用期 ，然后在全球范围内提供的数十种 jelastic 安装中进行选择。