在上一教程中 ，我指导您完成了使用Pantheon上的“ Dev-Test-Live”三环境设置创建和维护可安全生产的WordPress网站的步骤。 在这样的配置中，您总是在开发环境中更新代码，然后在测试环境中对其进行测试，只有当一切看起来都很好时，才将其推送到Live服务器。

尽管与运行单环境WordPress安装并将更改直接上传到实时服务器相比，这是一个重大改进，但我们可以做得更好！

“让专家去做无聊且重复的，但技术要求很高的任务，是确保我们能想到的人为失误，缺乏睡眠剥夺或教sleep的最肯定的方法。”

David Farley的这段话概括了当前设置的问题：虽然拥有三个环境，并且使用它们的过程有所帮助，但我们仍然手动进行所有工作，这很容易导致错误。

在本教程中，为帮助您尽可能地消除此问题，我将首先向您展示如何使用Pantheon的命令行工具更快地执行一些重复性任务，然后我们将探讨自动化。 更具体地说，我们将研究使用持续集成服务器和Behat测试框架自动执行您的验收测试。

完成本教程后，您将对在Pantheon上开发和设置可靠，易于维护的WordPress网站的原理有深刻的了解。 您还将获得许多有关如何使您的配置变得更好的想法，一次可以进行一次小改进。

让我们开始吧！

1.使用Terminus命令行工具控制您的Pantheon网站

虽然Pantheon的Web仪表板为您提供了三个服务器上正在发生的事情的清晰可视化呈现以及用于管理它们的出色工具，但有时您会更喜欢使用命令行工具。

这可能是为了节省时间：在您的网站上工作时，您很快就会注意到，花在一个简单但重复的任务上的时间（例如，提交更改或将其部署到测试环境中）会累积起来，并成为该过程的重要组成部分。你每天做什么。 或者可能只是因为您喜欢在命令行上工作。 或者，也许您想创建一个脚本，将多个操作捆绑在一起，例如提交代码，将其部署到Test以及在一个命令中清除缓存。

Pantheon的命令行工具Terminus允许您完成所有这些以及更多操作。

步骤1：安装总站

在开始使用Terminus之前，您需要在计算机上安装它。

本教程中介绍的安装和使用说明适用于基于Unix的系统（例如Mac OS X或Linux）。 如果您使用的是Windows，则命令会有所不同-请查看官方的Terminus安装说明以获取更多信息。

总站具有以下系统要求，因此在继续之前请确保已安装它们：

• PHP版本5.5.9或更高版本
• PHP-CLI
• PHP-CURL

尽管Terminus不需要它，但我建议您也安装Composer来完成本教程。 我还假设您已经在使用上一个教程中提到的Git。

有几种不同的安装Terminus的方法（有关详细信息，请参见安装说明），但让我们开始一个简单的方法，它不需要运行许多其他工具。

在控制台窗口中，键入：

$ curl https://github.com/pantheon-systems/terminus/releases/download/0.11.1/terminus.phar -L -o /usr/local/bin/terminus && chmod +x /usr/local/bin/terminus

该命令将Terminus安装到计算机上的/usr/local/bin/terminus 。

安装完成后，可以通过发出以下命令进行测试：

$ terminus art

应显示几种不同的ASCII艺术徽标之一。 例如，这是总站闪电拳头图标：

步骤2：登录总站

您需要先登录，然后才能使用Terminus来管理您的Pantheon帐户和与其链接的网站。

有两种方法可以执行此操作：您可以使用电子邮件和万神殿密码登录，也可以使用计算机令牌来标识正在登录的计算机。

我们将使用机器令牌方法，因为它可以为您提供额外的安全性。 如果您的计算机受到感染，并且需要禁用其登录名，则可以撤消计算机令牌，并且没有人可以再从该计算机访问您的帐户。 如果您在多台计算机和自动化脚本上（例如，在连续集成服务器上）运行Terminus，则计算机令牌也很有用。

您创建的每个机器令牌都会为机器用户提供与您的Pantheon帐户相同的访问权限。 因此，请确保撤消不再使用的所有令牌。

要创建您的第一个机器令牌，请登录您的Pantheon帐户。 然后，在帐户标签上，选择菜单选项机器令牌 。

点击创建令牌 。 然后，在下一个屏幕上，输入描述性名称，然后点击生成令牌 。

接下来，您将看到一个弹出窗口，其中显示新创建的令牌以及用于将其存储到计算机上的Terminus的命令。

复制Terminus命令并在命令行上运行它。

$ terminus auth login --machine-token=TOKEN

命令完成后，就可以在计算机上使用Terminus了。

让我们来看看您可以用它做什么！

步骤3：总站命令概述

在本教程的其余部分中，当我们为您的WordPress网站设置自动测试时，我们将在各处使用Terminus命令。 但是，这只是表面上的问题，因此，在开始之前，我们先来看一些命令以及如何了解它们的更多信息。

这样，完成本教程后，您将拥有可以用来查找更多信息并进一步改善工作流程以匹配您的首选项的指针。

您可以在Terminus Wiki中找到Terminus命令的最新列表。

该列表不包括这些命令的文档，因此，当您看到可能要使用的命令时，请使用Terminus工具通过键入以下内容来查找有关该命令的更多信息：

$ terminus help <command> <subcommand>

如果省略<subcommand> ，Terminus将为您显示可用于指定命令的子命令列表。

现在，让我们来看一些有用的命令，您可以使用这些命令直接在命令行上执行上一教程中的操作。

管理您的网站

要查看万神殿上所有站点的列表，请输入：

$ terminus sites show

还有一些命令可用于创建新站点（ terminus sites create ）和导入站点（ terminus sites import ）而无需访问仪表板。 如果您是代理机构并且经常创建新网站，这些功能将非常有用。 对于我们其他人，仪表板可以正常工作。

如果您运行多个站点，另一个有用的命令是terminus sites mass-update ，您可以使用该命令通过可用的上游更新（在我们的情况下为新的WordPress版本）来更新所有开发站点。

推动和部署变更

开发新站点时，大部分工作是编写，部署和测试代码。 因此，无论您是在Git还是SFTP模式下工作，您都会做很多事情。 这就是为什么它也是您将从命令行界面而不是通过Web仪表板执行所有操作中受益最多的领域。

这些操作在site命令下分组-您可以通过键入以下内容查看完整列表：

$ terminus help site

由于这是万神殿上大多数动作的发生地，您将看到有许多子命令。 在您处理网站时，请花一些时间探索它们，但是现在，让我们看一些最有用的。

如果您在SFTP模式下工作，则就像我们在上一个教程的大部分步骤中所做的那样，您必须将所做的更改提交到版本控制中，以存储它们并将其部署到Test and Live环境中。

您可以使用以下命令通过CLI进行操作：

$ terminus site code commit --site=<site> --message=<message>

将<site>替换为您站点的ID（例如， tutorial-example-site ），并将<message>替换为描述性的提交消息。

您还可以将site code命令用于与版本控制相关的其他功能。 查看命令的帮助页面以获取更多信息。

提交更改后（如果处于Git模式，则将其直接推送到版本控制中），然后可以使用site deploy命令将其部署到Test and Live中：

$ terminus site deploy --site=<site> --env=<test|live> [--sync-content] [--cc] [--note=<note>]

使用此命令，您可以从Dev部署到Test或从Test到Live。 要指定要执行的操作，请将--env属性设置为正确的值（ test或live ）。 在部署到Test时，您还可以选择从实时环境中自动克隆环境的数据（ --sync-content ）—如果您不想同步数据，则将其标记掉。 如果指定--cc标志，则Pantheon将在部署后清除缓存。 如果要添加部署说明，则可以使用--note参数来完成。

要将单个站点的上游（在本例中为基本的WordPress安装）更新为最新版本，可以使用以下命令：

$ terminus site upstream-updates <list|apply> --site=<site>

选择任一list以仅列出更新或apply以使更新生效。

除了这些操作之外，您还可以使用terminus site执行许多其他操作，例如运行备份，手动清除缓存，在环境之间克隆内容以及使用Multidev环境。 查看帮助页面以获取命令和参数的完整列表。

控制您的WordPress网站

对于像您和我这样的WordPress开发人员，Terminus的强大功能很大一部分在于它使我们能够在目标环境上运行WP-CLI命令。 这样，您可以例如在客户站点上安装和更新插件，而无需访问WordPress仪表板。

在您的Pantheon开发服务器上运行WP-CLI命令的命令是：

$ terminus wp <commands>... [--site=<site>]

因此，例如，要使用Terminus将配置更改从Dev上的WP-CFM推送到Git，然后推送到测试环境（一个重复的任务，只是等待自动化的一个很好的例子），您可以使用以下命令：

$ terminus wp 'config push site_options' --site=tutorial-example-site --env=dev$ terminus site code commit --site=tutorial-example-site --env=dev --message="Pushed configuration changes to site_options.json"$ terminus site deploy --site=tutorial-example-site --env=test --cc --note="Deploy code for options.json configuration"$ terminus wp 'config pull site_options' --site=tutorial-example-site --env=test

用您的实际站点ID替换tutorial-example-site ，并用您在WP-CFM中创建的选项捆绑包的ID site_options 。

当您继续使用Pantheon和Terminus时，我相信您会找到越来越多的使用命令行界面来加速和自动化工作的方法。

因此，请继续尝试！

2.测试您的WordPress网站入门

在上一教程中 ，您了解了如何使用测试环境对代码进行彻底测试，然后再将代码发送到实时服务器供所有人使用。 尽管这是个好主意，但确保您已检查所有内容，这是一项涉及核对清单并一遍又一遍地单击内容的工作。 换句话说，这是很容易滑倒的地方。

这就是为什么它是您进行某些自动化过程的完美步骤！

在本教程的其余部分中，我们将使用测试工具Behat创建一个简单的测试设置，并在每次将代码从Dev部署到Pantheon上的Test时使其自动运行。 为此，我们将结合使用Pantheon的服务器上脚本工具Quicksilver和在云中运行的持续集成服务器。

我们将从设置测试并使它们在您的计算机上运行开始。

步骤1：创建一个新项目以进行Behat测试

Behat是用于PHP的开放源代码的行为驱动开发框架，它使您可以编写测试用例，以检查实际的用户体验是否符合您的期望。

让我们从在新目录中设置Behat开始，我们以后可以将其部署到持续集成服务器中。 Behat测试将在本地运行（稍后在CI服务器上运行），以测试在您的测试环境中运行的Pantheon站点。

通过从GitHub下载快速入门模板，然后根据需要对其进行自定义，我们将开始进行Behat设置。 在计算机上合适的目录中，运行以下命令以下载软件包：

$ curl https://codeload.github.com/ari-gold/WordPress-Behat-Quickstart/zip/master > WordPress-Behat-Quickstart.zip$ unzip WordPress-Behat-Quickstart.zip$ rm WordPress-Behat-Quickstart.zip

解压缩软件包时，将创建一个新目录WordPress-Behat-Quickstart-master 。 将目录重命名为更适合我们使用的目录：

$ mv WordPress-Behat-Quickstart-master wp-pantheon-behat

然后转到该目录：

$ cd wp-pantheon-behat

在该目录中，您将找到一些配置模板和两个可用于创建Behat测试的入门功能 。

但是在查看它们之前，让我们完成安装。 安装是使用Composer完成的，因此，如果尚未安装Composer，请先下载并安装它，然后再继续。

由于快速入门软件包已经包含用于安装Behat的composer.json和composer.lock配置，因此您所需要做的就是在命令行中键入以下命令：

$ composer install

Composer将下载所需的软件包并将其存储在正确的位置。 在安装运行并最终完成时，您应该看到类似以下内容：

要运行Behat，您将需要两个配置文件： behat.yml和behat.local.yml 。

快速behat.local.yml项目已经包含了两者的默认文件，但是behat.local.yml的文件存储为behat.local.yml.sample以防止您将本地配置（例如，可能包含密码）提交给Git。 该项目还包含一个带有behat.local.yml的.gitignore文件。

复制样本配置：

$ cp behat.local.yml.sample behat.local.yml

您可以使用此文件来存储不应提交给实际的behat.yml文件的任何环境或特定于用户的配置。 在本教程中，我们的测试是如此简单，以至于我们需要确保该文件存在。

接下来，让我们看第二个配置文件behat.yml 。

通过用测试环境的URL替换以id base_url指定的URL来修改文件。 最后，该文件应如下所示，其中http://test-tutorial-example-site-pan.pantheonsite.io是您的测试服务器的URL：

# behat.ymldefault:extensions:Behat\MinkExtension\Extension:base_url: http://test-tutorial-example-site.pantheonsite.io/goutte: ~selenium2: ~show_cmd: "/Applications/Firefox.app/Contents/MacOS/firefox %s"imports:- behat.local.yml

更新配置后，通过在目录中列出可用的测试方案来测试一切是否正常：

$ bin/behat -dl

您将在features目录中看到一长串描述测试场景的正则表达式：

接下来，让我们仔细看一下测试，然后在测试服务器上运行一个。

步骤2：进行首次测试

Behat中的测试称为功能 ，正如我在上文中简要提到的，它们存储在features目录中的文本文件中（每个功能要测试一个文件）。

如果您在目录中查找，则会在快速blog.feature包中找到两个指定的功能： homepage_works.feature和blog.feature 。 您可以将它们用作测试的起点，然后在为WordPress网站构建一套完整的测试时随意添加更多。

让我们从homepage_works.feature开始，这是一项快速测试，检查到达您站点的访问者是否可以加载主页：

@smokeFeature: As a visitor I should be able to load the home pageScenario: Home page loadsGiven I am on the homepageThen I should see "Test with Robots"

Behat功能以一种称为Gherkin的格式编写，正如您从本摘要中看到的那样，它看起来像普通的英语-比我们两个人之间的注解更加精心编写。 或如Behat文档所述，“业务和开发人员都可以清楚地理解的形式”。

在本教程中，我不会深入解释如何使用Behat来构建测试。 为此，我建议阅读Behat的入门文档 。

就目前的需求而言，足以理解一项功能由一个或多个场景组成 ，这些场景描述了用户的行为方式以及应该发生的情况。 如果这看起来像魔术，那不是。 在幕后，Behat使用正则表达式将场景步骤映射到在测试套件（请参阅features/bootstrap ）或诸如Mink之类的库中定义的PHP函数，该库用于模拟用户浏览Web。

例如， "I am on the homepage" iAmOnHomepage()转换为Mink库中的函数iAmOnHomepage() ，并将Mink的虚拟浏览器导航到behat.yml您的测试服务器）中指定的网站的根目录。

现在，让我们充分定制测试，以使其通过您的测试服务器。 目前，该测试希望在您的主页上找到文本"Test with Robots" 。 换句话说，除非您在其中写有该文字，否则测试将失败。

因此，将该片段替换为您知道会在首页上找到的句子（例如，网站标题）并保存更改。

然后运行以下命令以运行所有标记有@smoke测试。 在这种情况下，仅此一项测试。

$ bin/behat --tags=smoke

您应该看到测试通过：

现在，您已经设置了可以在开发计算机上成功运行的测试，并在万神殿测试环境中测试了WordPress网站。

测试的收集仍然非常有限，对于真实的服务器，这仅仅是开始。 因此，在完成本教程之后，回到这一步，并深入研究Behat以创建真正将您的服务器置于测试中的测试，检查所有这些小事情，如果您手动测试站点，您会检查自己。

但是现在，让我们继续进行自动验收测试并使测试在云中运行的下一步。

3.使您的Behat测试在云中运行

持续集成 （CI）是一种软件开发实践，每天将代码几次合并到主分支中，并在每次推送时自动进行测试。 如今，这通常意味着您有一个持续集成服务在云中运行，以监视您的Git存储库。 然后，每次将新提交提交到版本控制时，CI服务都会启动，从Git中提取代码，然后进行构建和测试。

在本教程中，我们将使用这种方法的片段来开发一个更好地适应Pantheon三个环境工作流程的设置：我们不会在每次git push上运行测试，而是在将新代码部署到Test服务器时运行它们。

我们将使用Circle CI作为我们的持续集成服务器，因为它具有免费级别，可以满足教程的需求，并且功能强大，可以从Pantheon调用以初始化构建。 在您自己的实现中，您还可以使用其他连续集成服务器，例如Travis CI或Jenkins，并对教程中说明的过程进行一些更改。

步骤1：将测试推向Git

大多数基于云的持续集成服务都与版本控制紧密相连，从而支持Bitbucket或GitHub。 一些都支持。 但是，除非您设置自己的CI服务器（例如使用Jenkins），否则您将必须与Pantheon帐户维护一个独立的存储库以进行连续集成设置。

一种选择是将整个站点维护在GitHub或Bitbucket上，并使用Terminus将其从持续集成服务器部署到Pantheon。 尽管这将更接近于持续集成的理想，但它也是一个相当复杂的设置，并且我认为这打破了Pantheon工作流程的想法。

这就是为什么在我们的设置中，我们仅将测试设置存储在链接到CI服务的GitHub存储库中，并按照到目前为止的操作在Pantheon上维护站点的代码。

首先，注册到GitHub并创建一个新的存储库：

然后在wp-pantheon-behat目录中，初始化Git并提交更改：

$ git init$ git add .gitignore behat.yml composer.json composer.lock features$ git commit -m "First commit"

请注意，Composer安装的文件未存储在git中。 它们将作为测试脚本的一部分再次自动安装在CI服务器上。

然后，将数据推送到新的GitHub存储库：

$ git remote add origin https://github.com/jarkkolaine/wp-pantheon-behat.git$ git push -u origin master

您的测试设置现已在GitHub上可用。 让我们将其连接到持续集成服务器！

步骤2：设置持续集成服务器

首先，使用您的GitHub帐户注册一个免费的Circle CI帐户。

登录后，Circle会要求您从GitHub帐户中选择一个项目进行构建。 例如，在这里，您可以在右侧列表的顶部看到wp-pantheon-behat项目。

单击项目旁边的“ 生成项目”按钮。

Circle CI立即开始构建。 它从Git克隆项目，安装所有Composer依赖项（在本例中为Behat测试工具），然后运行测试。

在您的第一个版本中，Circle CI会遇到错误：

默认情况下，Circle CI运行PHP 5.3.10版本，对于Behat使用的某些库而言，该版本太旧了。 幸运的是，这很容易解决。

在wp-pantheon-behat目录中，创建一个新文件circle.yml 。 该文件将包含我们要对Circle CI配置进行的任何自定义。

在文件中，插入以下内容：

machine:php:version: 5.5.11

将文件提交到Git并将其推送到您的GitHub存储库。

$ git add circle.yml$ git commit -m "Added PHP version requirement"$ git push origin master

然后跳回到Circle CI，您将在其中看到持续集成系统再次开始运行测试。

这次，Composer步骤应该成功运行。 但是仍然有一些配置要做：在构建通过的同时，Circle CI找不到我们的测试！

要解决此问题，让我们告诉Circle如何运行Behat测试。

在circle.yml ，在我们刚刚创建的PHP版本配置的下面添加新的部分test ：

machine:php:version: 5.5.11test:pre:- mv behat.local.yml.sample behat.local.ymloverride:- mkdir $CIRCLE_TEST_REPORTS/behat- ./bin/behat --format junit --out $CIRCLE_TEST_REPORTS/behat --tags=smoke

让我们看一下代码片段。

首先， pre一节中，我们告诉Circle CI在尝试运行测试之前使用模板创建behat.local.yml配置文件。

然后，在标记为override的部分中，我们定义了Circle CI每当需要运行测试时应采取的操作顺序。

Behat命令与我们在本地运行测试时使用的命令有些不同。 这是因为我们要以类似于JUnit的XML格式打印测试结果，并且CI服务器可以解析该格式。 $CIRCLE_TEST_REPORTS变量是对Circle CI希望在其中找到测试报告的目录的引用。

再次提交并推送更改，然后返回Circle CI以验证测试现在可以成功运行。

4.使用Quicksilver在部署时启动测试

现在，您已经设置了Behat测试并在连续集成服务器上运行它们，剩下的最后一步是，每次将更改部署到测试上时，让Pantheon在Circle CI上触发新的构建，从而将该设置与Pantheon工作流联系起来。环境。

我们将使用Pantheon的Quicksilver Platform Hooks进行此操作，该系统使开发人员能够将脚本链接到Pantheon工作流中的事件。

在Circle CI上触发新构建只是使用Quicksilver挂钩可以实现的一个示例，因此，我建议您查看其文档和示例 ，并在完成本教程后想出更多自己的用法。

步骤1：定义Quicksilver动作

Quicksilver已安装在您的Pantheon环境中，因此您只需定义第一个Quicksilver操作即可开始使用它。

Pantheon站点的Quicksilver配置由放置在站点code目录根目录中的配置文件pantheon.yml和用PHP编写的实际脚本组成。

您可以像上一教程一样使用SFTP上传这些文件，也可以使用Git模式。

要在Git模式下进行更改，请首先将站点的“ 连接模式”设置为Git ：

单击Git Connection Info以复制用于克隆git存储库的命令，然后在命令行上的适当目录中运行它：

$ git clone ssh://codeserver.dev.XXX@codeserver.dev.XXX.drush.in:2222/~/repository.git tutorial-example-site

克隆命令完成后，使用您喜欢的文本编辑器在目录中添加pantheon.yml文件，其内容如下：

api_version: 1workflows:deploy:after:- type: webphpdescription: Initiate a new build at Circle CIscript: private/scripts/circle_ci_notify.php

在此配置文件中，您将列出要与Pantheon工作流挂钩的所有脚本，定义是否要在该事件之前或之后运行该脚本。 对于任何事件，您都可以根据需要添加任意数量的脚本。

当前，以下工作流可用于挂接：

• deploy ：在将代码部署到Test或Live时触发。 脚本在目标环境上运行。
• sync_code ：通过Git推送代码或在万神殿仪表板中提交代码时触发。 脚本在承诺环境上运行。
• clone_database ：在环境之间克隆数据时触发。 脚本在目标环境上运行。
• clear_cache ：清除缓存时触发。 脚本在清除的环境中运行。

每个脚本或动作webphp一种type （当前仅支持webphp ，这意味着支持在目标环境上运行的PHP代码），一个description和一个script ，一个相对于代码存储库的脚本文件路径组成。

因此，查看上面的pantheon.yml文件，您将看到我们想在 部署事件之后立即运行脚本private/scripts/circle_ci_notify.php 。

步骤2：为您的Quicksilver操作创建PHP脚本

要运行，我们的Quicksilver动作挂钩仍需要脚本。

我们的脚本将调用Circle CI API的新构建动作，以使测试再次运行。 为此，我们需要在万神殿测试环境中以安全的方式检索和存储Circle CI API凭据。

在Circle CI仪表板中，单击左侧菜单上的“ 帐户设置” ，然后选择“ API令牌”标签以创建新的API令牌。

给您的新令牌一个描述性名称，然后单击“ 创建新令牌” 。

现在，您有了一个API令牌，可以用来与Circle CI API对话。

将API机密或其他敏感数据提交给版本控制被认为是不好的做法。 因此，通过创建配置文件并将其上传到测试服务器上的安全位置，让我们使用一种更安全的方法将API凭据传递给脚本。

在导出的代码存储库之外的目录中，创建一个名为secrets.json的文件。 在该文件中，放置以下内容：

{ "username":"YOUR USER NAME", "project":"wp-pantheon-behat", "token":"YOUR API KEY" }

然后，使用SFTP将其上传到测试环境中的目录files/private 。 请注意，文件系统（服务器上的files目录）与代码是分开的，并且其中的文件永远不会进入版本控制。

Terminus命令site connection-info根据您作为参数传入的站点，环境和连接方法，打印出用于连接到您的环境的信息。

因此，要使用SFTP连接到测试环境的文件系统，可以使用此命令—作为一个小技巧，将命令用反引号 （ ` ）引起来   字符运行打印出的命令，而不只是显示给您（自然地，您也可以使用自己喜欢的SFTP客户端）：

$ `terminus site connection-info --env=test --site=tutorial-example-site --field=sftp_command`

现在您已连接到服务器，是时候上传配置文件了：

sftp> cd filessftp> mkdir privatesftp> put secrets.jsonsftp> exit

凭据现已到位。 让我们创建脚本。

在代码存储库中，创建一个目录private/scripts ，然后在其中添加一个新的PHP脚本circle_ci_notify.php 。

这是一个常规的PHP脚本，可在事件的目标环境上运行-对于deploy事件，则为Test或Live。

<?php// Check environmentif ( ! isset( $_ENV['PANTHEON_ENVIRONMENT'] ) || $_ENV['PANTHEON_ENVIRONMENT'] !== 'test' ) {die( 'Automatic tests should only be run on the Test environment' );}// Load a secrets file$secrets = _get_secrets('secrets.json');// Use a curl POST request to trigger the Circle CI API action$url = 'https://circleci.com/api/v1/project/';$url = $url . $secrets['username'] . '/' . $secrets['project'] . '?circle-token=' . $secrets['token'];$curl = curl_init( $url );// Declare request as a post and setup the fieldscurl_setopt( $curl, CURLOPT_POST, true );// All parameters are optional, so we can send an empty arraycurl_setopt( $curl, CURLOPT_POSTFIELDS, json_encode( array() ) );// Execute the request $response = curl_exec( $curl );if ( $response ) {echo "Build Queued";} else {echo "Build Failed";}/*** Get secrets from secrets file.** @param string $file path within files/private that has your json*/function _get_secrets( $file ) {$secrets_file = $_SERVER['HOME'] . '/files/private/' . $file;if ( ! file_exists( $secrets_file ) ) {die( 'No secrets file found. Aborting!' );}$secrets_json = file_get_contents( $secrets_file );$secrets = json_decode( $secrets_json, 1 );if ( $secrets == FALSE ) {die( 'Could not parse json in secrets file. Aborting!' );}return $secrets;}

让我们逐行浏览脚本。

在第2-5行，脚本验证它是否正在测试环境中运行。

然后，在第8行 ，使用第37-50行在文件末尾指定的辅助函数_get_secrets从刚上传到文件系统的JSON文件中读取API参数。

然后，在第10-22行 ，该脚本对Circle CI API进行HTTP调用以启动构建。

最后，在第24-28行上 ，脚本检查来自API调用的响应并打印出简单的成功消息。 如果愿意，这是进一步开发的好地方：例如，您可以使脚本将通知发布到您团队的Slack频道！

现在，您已准备就绪。 提交更改并将其推送到Git存储库。

git push完成后，您将注意到以下输出，Pantheon会让您知道它检测到新创建的pantheon.yml并将其动作应用于Dev环境。

remote: remote: PANTHEON NOTICE:remote: remote: Changes to `pantheon.yml` detected.remote: remote: Successfully applied `pantheon.yml` to the 'dev' environment.remote: remote:

但是，正如我前面提到的， deploy任务在目标环境上运行。 因此，在脚本运行之前，我们需要将更改部署到Test。

让我们使用Terminus命令行界面（如果需要，您也可以使用Web仪表板）进行操作：

$ terminus site deploy --site=tutorial-example-site --env=test --sync-content --note="Added Quicksilver event for Circle CI"

我们的Quicksilver脚本现在可以在“测试”环境中使用。

要查看它的实际效果，请更改开发环境的代码库（例如，通过安装新插件或修改子主题），然后将更改提交并部署到Test。

当您访问Circle CI仪表板时，您会看到一个新的构建已触发并正在运行，测试可以正确加载“测试”站点的首页。

您也可以使用Terminus来检查脚本是否正确运行。 为此，在部署更改之前，请在命令行上运行以下命令：

$ terminus workflows watch --site=tutorial-example-site

现在，当部署完成时，您将看到类似这样的内容，告诉您有关Quicksilver操作的信息：

[2016-05-19 13:01:24] [info] Finished workflow b532f7fe-1dc1-11e6-9914-bc764e10b0ce Deploy code to "test" (test) at 2016-05-19 13:01:10id: 'b532f7fe-1dc1-11e6-9914-bc764e10b0ce'description: 'Deploy code to "test"'env: 'test'time: '2016-05-19 13:01:10'[2016-05-19 13:01:26] [info] ------ Operation: Initiate a new build at Circle CI finished in 3s (test) ------{"compare" : null,"previous_successful_build" : {"build_num" : 9,"status" : "success","build_time_millis" : 55657},...

结论

自动化测试设置现已完成：每当您将代码从Pantheon Dev环境部署到Test时，Circle CI上都会触发一个新的构建，并针对您的Test环境运行Behat测试。 如果出现问题，Circle会向您发送一封电子邮件，告知您构建失败，因此您可以修复它，然后重试。

但这仅仅是开始。

首先，您需要编写更多测试。 考虑一下要检查的所有内容以确保您的站点正常运行，然后编写Behat功能进行测试。 然后，考虑您的访问者和客户如何使用该网站，并为这些用例编写测试。

您还可以通过例如添加有关成功测试的Slack通知来改进Circle CI配置。 这样，您将知道自动化测试已通过，并且可以在进行更改之前进行最终检查。 以后，一旦您对测试充满信心，甚至可以考虑修改您的circle.yml以使用Terminus在成功构建后自动将代码从Test部署到Live！

但是，可能性并没有就此结束！ 您还可以使用Quicksilver将更多的自动化脚本添加到您的工作流程中。 看一下万神殿工程师的一些例子 。 然后创建自己的一些！

随着测试和开发流程的自动化，您将逐渐创建一个越来越安全的工作流程。

翻译自: https://code.tutsplus.com/tutorials/how-to-automate-and-optimize-your-wordpress-development-and-testing-on-pantheon--cms-26551