Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress
Code

Как автоматизировать и оптимизировать разработку и тестирование WordPress в Pantheon

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called How to Use Pantheon to Set Up and Maintain a Production-Safe WordPress Site.
How to Use Pantheon to Set Up and Maintain a Production-Safe WordPress Site
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Russian (Pусский) translation by Sergey Zhuk (you can also view the original English article)

В моем предыдущем учебном пособии я рассказал вам, как начать работу с созданием и безопасным с точки зрения производства сайтом WordPress, используя трехмерную среду «Dev-Test-Live» на Pantheon. В такой конфигурации вы всегда обновляете свой код в среде Dev, затем тестируете его в тестовой среде, и только после того, как все выглядит хорошо, выкладываете его на Live сервер.

Хотя это значительное улучшение по сравнению с запуском установки WordPress в одной только среде и загрузкой изменений прямо на сервер в реальном времени, мы можем добиться большего!

«Просить экспертов делать скучные и повторяющиеся, но вместе с тем технически сложные задания - это самый верный способ обеспечить человеческую ошибку, о которой мы можем думать, лишая себя сна».

Эта цитата из Дэвида Фарли подводит итог этой проблемы с нашей текущей установкой: имея три среды и процесс их использования, мы все еще выполняем всю работу вручную, что может легко привести к ошибкам.

В этом учебном пособии, чтобы помочь устранить эту проблему в максимально возможной степени, я сначала покажу вам, как вы можете выполнять некоторые повторяющиеся задачи быстрее, используя инструменты командной строки Pantheon, а затем посмотрим на автоматизацию. Более конкретно, мы рассмотрим автоматизацию ваших приемочных тестов с использованием сервера непрерывной интеграции и платформы тестирования Behat.

После завершения учебного курса вы получите полное представление о принципах разработки и создания надежного и легкого в обслуживании сайта WordPress в Пантеоне. Вы также будете иметь много идей о том, как сделать вашу конфигурацию еще лучше, делая небольшое улучшение за раз.

Давайте начнем!

1. Использование инструмента командной строки Terminus для управления сайтом Pantheon

В то время как Pantheon's Web Dashboard дает вам ясное визуальное представление о том, что происходит на ваших трех серверах, и отличные инструменты для управления ими, бывают случаи, когда вы предпочитаете инструмент командной строки.

Это может быть экономия времени: когда вы работаете на своем сайте, вы скоро заметите, что время, потраченное на выполнение простой, но повторяющейся задачи, например, фиксация изменений или развертывание их в тестовой среде, накапливается и становится важной частью, которую вы делаете каждый день. Или это может быть просто потому, что вам нравится работать в командной строке. Или, может быть, вы хотите создать скрипт, который связывает несколько действий, таких как передача вашего кода, развертывание его в Test и очистка кеша в одной команде.

Инструмент командной строки Pantheon, Terminus, позволяет делать все это - и многое другое.

Шаг 1. Установка Terminus

Прежде чем вы сможете начать использовать Terminus, вам необходимо установить его на свой компьютер.

Инструкции по установке и использованию, представленные в этом руководстве, предназначены для Unix-систем (таких как Mac OS X или Linux). Если вы работаете в Windows, команды немного отличаются - обратитесь к официальным инструкциям по установке Terminus за дополнительной информацией.

Terminus имеет следующие системные требования, поэтому перед началом работы убедитесь, что у вас установлены следующие компоненты:

Хотя это и не обязательно для Terminus, я рекомендую вам также установить Composer для завершения урока. Я также предполагаю, что вы уже используете Git, о чем мы говорили в предыдущем уроке.

Существует несколько способов установки Terminus (подробности см. В инструкциях по установке), но давайте рассмотрим простой пример, который не требует много дополнительных инструментов для запуска.

В окне консоли введите:

Команда устанавливает Terminus в /usr/local/bin/terminus на вашем компьютере.

По завершении установки вы можете протестировать его, выполнив следующую команду:

Должен появиться один из нескольких различных логотипов ASCII. Вот значок кулака молнии Terminus, например:

When you see the logo you know Terminus was installed successfully

Шаг 2. Войдите в Terminus.

Прежде чем вы сможете использовать Terminus для управления вашей учетной записью Pantheon и связанными с ней сайтами, вам нужно будет войти в систему.

Это можно сделать двумя способами: вы можете войти в систему, используя свой адрес электронной почты и пароль Pantheon, или использовать машинный токен, чтобы идентифицировать компьютер, на котором вы выполняете вход.

Мы подойдем к подходу машинного токена, поскольку он обеспечивает дополнительный уровень безопасности. Если ваш компьютер скомпрометирован и вам нужно отключить логин для него, вы можете отозвать маркер машины, и никто больше не сможет получить доступ к вашей учетной записи с этого компьютера. Машинные токены также полезны, если вы запускаете Terminus на нескольких машинах и автоматизированных сценариях, например, на сервере непрерывной интеграции.

Каждый созданный вами токен дает пользователям машины тот же доступ к вашей учетной записи Pantheon, какой есть у вас. Поэтому обязательно отмените любые токены, которые вы больше не используете.

Чтобы создать свой первый машинный токен, войдите в свою учетную запись Pantheon. Затем на вкладке Account выберите пункт меню Machine Tokens.

Machine Tokens

Нажмите Создать маркер. Затем на следующем экране введите описательное имя и нажмите «Создать токен».

Create New Token

Затем вы увидите всплывающее окно с отображением только что созданного токена вместе с командой для его сохранения в Terminus на вашем компьютере.

Your new machine token is ready

Скопируйте команду Terminus и запустите ее в командной строке.

Как только команда завершится, Terminus готов к использованию на вашем компьютере.

Давайте посмотрим, что вы можете с ним сделать!

Шаг 3. Обзор команд Terminus

В оставшейся части руководства мы будем использовать команды Terminus здесь и там, где мы настроили автоматическое тестирование вашего сайта WordPress. А теперь давайте взглянем на некоторые из команд и как вы можете узнать о них больше.

Таким образом, как только вы закончите обучение, у вас появятся указатели, которые вы можете использовать, чтобы узнать больше и улучшить свой рабочий процесс в соответствии с вашими предпочтениями.

Вы можете найти обновленный список команд Terminus в Terminus Wiki.

Список не содержит документации для команд, поэтому, когда вы видите команду, которую вы, возможно, захотите использовать, используйте инструмент Terminus, чтобы узнать больше об этом, набрав:

Если вы не укажете <subcommand>, Terminus покажет вам список подкоманд, доступных для указанной команды.

Теперь давайте взглянем на некоторые полезные команды, которые вы можете использовать для выполнения действий из предыдущего учебника непосредственно в командной строке.

Управление вашими сайтами

Чтобы просмотреть список всех ваших сайтов в Пантеоне, введите:

Существуют также команды для создания нового сайта (terminus sites create) и импорта сайта (terminus sites import) без использования личного кабинета. Это может быть полезно, если вы являетесь агентством и часто создаете новые сайты. Для остальных из нас приборная панель отлично подойдет.

Еще одна полезная команда terminus sites mass-update  это массовое обновление конечных сайтов, которое вы можете использовать, чтобы обновить все ваши dev-сайты с помощью доступного upstream-обновления (в нашем случае - новой версии WordPress).

Выкатывание и развертывание ваших изменений

Большая часть работы при разработке нового сайта - это написание, развертывание и тестирование кода. Таким образом, независимо от того, работаете ли вы в режиме Git или SFTP, вы будете постоянно это делать. Именно поэтому это также одна из областей, в которой вы больше всего выиграете от использования интерфейса командной строки, вместо использования веб-панели.

Эти действия сгруппированы под командой site - вы можете увидеть полный список, набрав:

Поскольку именно здесь происходит большинство действий в Pantheon, вы увидите, что есть много подкоманд. Потратьте время, чтобы изучить их, когда вы работаете на своем сайте, но сейчас давайте посмотрим на некоторые из самых полезных.

Если вы работаете в режиме SFTP, как мы это делали в большинстве предыдущих уроков, вам придется зафиксировать изменения в управлении версиями, чтобы хранить их и иметь возможность развёртывать их в тестовые и живые среды.

Вы можете сделать это через CLI, используя следующую команду:

Замените <site> идентификатором вашего сайта (например, tutorial-example-site) и <message> с описательным сообщением о фиксации.

Вы также можете использовать команду site code для других функций, связанных с контролем версий. Дополнительную информацию см. На странице справки команды.

После того как вы зафиксировали свои изменения (или перенесли их прямо в систему управление версиями, если вы находитесь в режиме Git), вы можете развернуть их в Test and Live среду, используя команду site deploy:

С помощью этой команды вы можете выполнить развертывание от Dev до Test или Test to Live. Чтобы указать, что вы делаете, установите для атрибута --env правильное значение (test или live). При развертывании в Test у вас также есть возможность автоматически клонировать данные из Live-среды (--sync-content) - оставьте этот флаг, если вы не хотите синхронизировать данные. Если вы укажете флаг --cc, Pantheon очистит кеш после развертывания. Если вы хотите добавить примечание развертывания, вы можете сделать это, используя параметр --note.

Чтобы обновить восходящий поток одного сайта (в нашем случае, базовую установку WordPress) до его последней версии, вы можете использовать команду:

Выберите любой list, чтобы просто перечислить обновления или apply, чтобы фактически заставить их произойти.

В дополнение к этим действиям вы можете использовать команду terminus site для выполнения многих других задач, таких как запуск резервных копий, очистка кеша вручную, клонирование содержимого между средами и работа с средами Multidev. Проверьте страницу справки для получения полного списка команд и параметров.

Управление сайтом WordPress

Для разработчиков WordPress, таких как вы и я, большая часть возможностей Terminus заключается в том, что они позволяют нам запускать команды WP-CLI в целевой среде. Таким образом, вы можете, например, установить и обновить плагины на своих сайтах клиентов, не посещая панель инструментов WordPress вообще.

Команда запуска команды WP-CLI на сервере Pantheon Dev:

Так, например, чтобы вносить изменения в конфигурацию из WP-CFM на Dev в Git, а затем в среду тестирования (отличный пример повторяющейся задачи, ожидающей автоматизации) с помощью Terminus, вы можете использовать следующие команды:

Замените tutorial-example-site фактическим идентификатором сайта и site_options идентификатором набора параметров, который вы создали на WP-CFM.

Продолжая работать с Pantheon и Terminus, я уверен, что вы найдете все больше и больше способов использовать интерфейс командной строки для ускорения и автоматизации вашей работы.

Так что, продолжайте экспериментировать!

2. Начало работы с тестированием сайта WordPress

В предыдущем уроке вы видели, как вы можете использовать среду тестирования для тщательного тестирования вашего кода, прежде чем перейти на Live-сервер для использования. Хотя это отличная идея, убедитесь, что вы проверили все - это работа, которая включает контрольные списки и многократные прокликивания. Другими словами, это очень вероятное место для промахов.

Вот почему это идеальный шаг в вашем процессе для некоторой автоматизации!

В оставшейся части урока мы создадим простую тестовую установку с использованием инструмента тестирования Behat и заставим его автоматически запускаться каждый раз, когда вы разворачиваете свой код из Dev в Test на Pantheon. Для этого мы будем использовать комбинацию скриптового инструмента Quicksilver на сервере Pantheon и сервер непрерывной интеграции, работающий в облаке.

Мы начнем с настройки тестов и запуска их на вашем компьютере.

Шаг 1. Создайте новый проект для проведения тестов Behat.

Behat - это свободно распространяемая среда разработки с открытым исходным кодом для PHP, которая позволяет вам писать тестовые примеры для проверки того, что фактический пользовательский интерфейс соответствует тому, что вы ожидаете.

Давайте начнем с настройки Behat в новом каталоге, который мы позже можем развернуть на сервере непрерывной интеграции. Тесты Behat будут запускаться локально (позже на сервере CI), тестируя сайт Pantheon, запущенный в вашей тестовой среде.

Мы начнем настройку Behat, загрузив шаблон быстрого запуска из GitHub, а затем настроив его для наших нужд. В подходящем каталоге на вашем компьютере выполните следующие команды для загрузки пакета:

При распаковке пакета создается новый каталог WordPress-Behat-Quickstart-master. Переименуйте директорию на то, что лучше соответствует нашему использованию:

Затем перейдите в этот каталог:

В этом каталоге вы найдете несколько шаблонов конфигурации и две функции для старта, которые вы можете построить, чтобы создать свои тесты Behat.

Но прежде чем мы посмотрим на них, давайте закончим установку. Установка выполняется с помощью Composer, поэтому, если у вас еще нет установленного Composer, загрузите и установите его перед продолжением.

Поскольку пакет быстрого запуска уже содержит конфигурацию composer.json и composer.lock для установки Behat, все, что вам нужно сделать, - это ввести следующую команду в командной строке:

Composer загрузит необходимые пакеты и сохранит их в нужном месте. Когда установка запустится и, наконец, завершится, вы увидите что-то вроде этого:

Behat installation

Чтобы запустить Behat, вам понадобятся два файла конфигурации: behat.yml и behat.local.yml.

Проект быстрого запуска уже содержит файлы по умолчанию для обоих, но файл для behat.local.yml хранится как behat.local.yml.sample, чтобы запретить вам передавать вашу локальную конфигурацию (например, пароли) в Git. Проект также содержит файл .gitignore с именем behat.local.yml.

Скопируйте образец конфигурации:

Вы можете использовать этот файл для хранения любой среды или пользовательской конфигурации, которые не должны быть привязаны к фактическому файлу behat.yml. В этом уроке наши тесты настолько просты, что нам нужно только убедиться, что файл присутствует.

Далее, давайте посмотрим на второй файл конфигурации, behat.yml.

Измените файл, заменив URL, указанный с идентификатором base_url, URL-адресом тестовой среды. В конце файл должен выглядеть следующим образом: http://test-tutorial-example-site.pantheonsite.io - URL-адрес тестового сервера:

После того, как вы обновили конфигурацию, проверьте, что все работает, перечислив тестовые сценарии, доступные в каталоге:

Вы увидите длинный список регулярных выражений, описывающих тестовые сценарии из каталога ваших функций:

Output for binbehat -dl

Далее давайте более подробно рассмотрим тесты и запустим их на ваш тестовый сервер.

Шаг 2. Запустите свой первый тест

Тесты в Behat называются features  и, как я кратко упомянул выше, они хранятся в текстовых файлах в каталоге features - по одному файлу на каждую тестируемую функцию.

Если вы посмотрите в каталоге, вы найдете две функции, указанные в пакете быстрого запуска: homepage_works.feature и blog.feature. Вы можете использовать их в качестве отправной точки для ваших тестов, а затем добавить столько, сколько захотите, при создании полного набора тестов для вашего сайта WordPress.

Начнем с homepage_works.feature, быстрого теста, который проверяет, может ли посетитель, прибывающий на ваш сайт, загрузить домашнюю страницу:

Функции Behat написаны в формате Gherkin, который, как вы можете видеть из этого фрагмента, выглядит как простой английский - чуть более тщательно сформулированный, чем заметка между нами двумя. Или, как говорится в документации Behat, «форма, понятная для бизнеса и разработчиков».

В этом уроке я не буду углубляться в объяснение того, как использовать Behat для создания тестов. Для этого я рекомендую прочитать документацию по началу работы Behat.

Для наших потребностей на данный момент достаточно понять, что feature состоит из одного или нескольких сценариев, которые описывают, как пользователь действует и что должно произойти в результате. Это выглядит как волшебство, это не так. За кулисами Behat использует регулярные выражения для сопоставления шагов сценария с функциями PHP, определенными либо в вашем наборе тестов (см. features/bootstrap), либо в библиотеке, такой как Mink, которую мы используем для моделирования пользователя, просматривающего Интернет.

Например, строка «I am on the homepage» переводит функцию iAmOnHomepage() в библиотеку Mink и переводит виртуальный браузер Mink в корень веб-сайта, указанный в файле behat.yml-ваш тестовый сервер.

Теперь давайте настроим тест так, чтобы он прошел на вашем тестовом сервере. На данный момент тест предполагает найти текст «Test with Robots» на вашей домашней странице. Другими словами, если у вас нет текста, написанного там, тест не будет выполнен.

Поэтому замените этот фрагмент предложением, которое вы знаете на первой странице (например, названием своего сайта) и сохраните изменения.

Затем запустите следующую команду, чтобы запустить все тесты, помеченные @smoke. В этом случае просто этот тест.

Вы должны увидеть тест:

First Behat test completed successfully

Теперь вы настроили тест, который успешно проходит на вашей машине разработки, тестируя сайт WordPress в среде Pantheon Test.

Набор тестов по-прежнему очень ограничен, и для реального сервера это только начало. Итак, после завершения учебного курса, вернитесь к этому шагу и углубитесь в Behat, чтобы создать тесты, которые действительно поставят ваш сервер на проверку, проверив все те мелочи, которые вы бы проверили сами, проверяя сайт вручную.

Но теперь перейдем к следующему шагу в нашем пути к автоматическому приемочному тестированию и пробному запуску в облаке.

3. Выполнение тестов Behat в облаке

Непрерывная интеграция (CI) - это практика разработки программного обеспечения, где код объединяется с основной веткой несколько раз в день и автоматически проверяется при каждом нажатии. Сегодня это обычно означает, что у вас есть непрерывный интеграционный сервис, работающий в облаке, следящий за вашим репозиторием Git. Затем, каждый раз, когда вы вставляете новый контроль в версию, служба CI запускается, вытягивает код из Git и строит и тестирует его.

В этом учебном курсе мы будем использовать части этого подхода для разработки установки, которая лучше подходит для трех рабочих процессов среды Pantheon: вместо запуска тестов при каждом git push мы запустим их, когда новый код будет развернут на тестовом сервере.

Мы будем использовать Circle CI в качестве нашего сервера непрерывной интеграции, поскольку он имеет свободный уровень, который достаточно силен для удовлетворения потребностей учебника и API, который мы можем вызвать из Пантеона, чтобы начать сборку. В вашей собственной реализации вы также можете использовать другой сервер непрерывной интеграции, такой как Travis CI или Jenkins, с некоторыми изменениями в процессе, описанном в учебнике.

Шаг 1: выложите ваши тесты на Git

Большинство услуг непрерывной интеграции в облаке тесно связаны с контролем версий, поддерживая либо Bitbucket, либо GitHub. Некоторые поддерживают оба. Но если вы не настроите свой собственный сервер CI, например, используя Jenkins, вам придется поддерживать репозиторий отдельно от вашей учетной записи Pantheon для установки непрерывной интеграции.

Одним из вариантов является поддержка всего сайта в GitHub или Bitbucket и развертывание его с сервера непрерывной интеграции в Pantheon с использованием Terminus. Хотя это было бы ближе к идеалу непрерывной интеграции, это также довольно сложная настройка и, на мой взгляд, нарушает идею рабочего процесса Pantheon.

Именно поэтому в нашей настройке мы храним только тестовую установку в репозитории GitHub, связанную с сервисом CI, и поддерживаем код сайта в Pantheon, как мы это делали до сих пор.

Сначала зарегистрируйтесь в GitHub и создайте новый репозиторий:

Create a new Github repository

Затем в каталоге wp-pantheon-behat инициализируйте Git и зафиксируйте изменения:

Обратите внимание, что файлы, установленные Composer, не хранятся в git. Они будут автоматически установлены на сервере CI в составе тестового скрипта.

Затем переместите данные в новый репозиторий GitHub:

Теперь ваша тестовая установка доступна на GitHub. Давайте подключим его к серверу непрерывной интеграции!

Шаг 2. Настройка сервера непрерывной интеграции

Сначала зарегистрируйтесь для бесплатной учетной записи Circle CI, используя учетную запись GitHub.

После того, как вы войдете в систему, Circle предложит вам выбрать проект из вашей учетной записи GitHub для сборки. Например, здесь вы можете увидеть проект wp-pantheon-behat в верхней части списка справа.

Add a project

Нажмите кнопку «Создать проект» рядом с проектом.

Кружок CI немедленно начинает сборку. Он клонирует проект из Git, устанавливает все зависимости Composer - в этом случае - инструменты тестирования Behat, - а затем запускает тесты.

Build started

В вашей первой сборке Circle CI вызовет ошибку:

An error occurred during composer install

По умолчанию Circle CI запускает PHP версию 5.3.10, которая слишком стара для некоторых библиотек, используемых Behat. К счастью, это легко исправить.

В каталоге wp-pantheon-behat создайте новый файл circle.yml. Этот файл будет содержать любые настройки, которые мы хотим внести в нашу конфигурацию Circle CI.

В файле введите следующее:

Зафиксируйте файл в Git и вставьте его в репозиторий GitHub.

Затем вернитесь в Circle CI, где вы увидите, что система непрерывной интеграции снова запустила тест.

На этот раз шаг Composer должен выполняться успешно. Но еще есть какая-то конфигурация: пока сборка прошла, Circle CI не нашёл наши тесты!

No tests found

Чтобы исправить это, давайте расскажем Circle, как запускать наши тесты Behat.

В circle.yml добавьте новый раздел test прямо под конфигурацией версии PHP, которую мы только что создали:

Давайте взглянем на фрагмент.

Во-первых, в предварительном разделе мы сообщаем Circle CI создать файл конфигурации behat.local.yml с использованием шаблона до того, как он попытается запустить тесты.

Затем в разделе, отмеченном override, мы определяем последовательность действий, которые Circle CI должен выполнять, когда пришло время запускать тесты.

Команда Behat немного отличается от того, что мы использовали при локальном выполнении тестов. Это потому, что мы хотим напечатать результаты тестов в формате JUnit-подобного XML, который может быть проанализирован сервером CI. Переменная $CIRCLE_TEST_REPORTS является ссылкой на каталог, в котором Circle CI ожидает найти отчеты об испытаниях.

Зафиксируйте и снова нажмите изменения и вернитесь в Circle CI, чтобы проверить, что тесты теперь успешно запущены.

The tests were run successfully

4. Использование Quicksilver для запуска тестов при развертывании времени

Теперь, когда вы настроили свои тесты Behat и запустили их на сервере непрерывной интеграции, последний оставшийся шаг - это подключение этой установки к рабочему процессу Pantheon, заставляя Pantheon запускать новую сборку на Circle CI каждый раз, когда вы развертываете свои изменения в Test Окружающая среда.

Мы сделаем это, используя Pantheon Quicksilver Platform Hooks, систему, которая дает разработчикам возможность связывать скрипты с событиями в рабочем процессе Pantheon.

Запуск новой сборки на Circle CI - это лишь один из примеров того, что вы можете достичь, используя хуки Quicksilver, поэтому я рекомендую вам изучить ее документацию и примеры и придумать больше собственных методов, как только это будет сделано с учебником.

Шаг 1. Определение действия Quicksilver

Quicksilver уже установлен в среде Pantheon, поэтому вы можете начать использовать его, только определив свое первое действие Quicksilver.

Конфигурация Quicksilver на сайте Pantheon состоит из конфигурационного файла pantheon.yml, размещенного в корневом каталоге сайта code, и реальных скриптов, написанных на PHP.

Вы можете загрузить эти файлы с помощью SFTP, как мы это делали в предыдущем уроке, или использовать режим Git.

Чтобы выполнить изменения в режиме Git, сначала установите режим подключения сайта в Git:

Set the connection mode to Git

Нажмите Git Connection Info, чтобы скопировать команду для клонирования вашего git-репозитория и запустить ее в подходящем каталоге в командной строке:

Как только команда clone завершится, добавьте файл pantheon.yml в каталог, используя ваш любимый текстовый редактор, со следующим содержимым:

В этом файле конфигурации вы перечислите все скрипты, которые вы хотите перехватить в своих рабочих процессах Pantheon, определяя, хотите ли вы запускать скрипт до или после этого события. Для любого события вы можете добавить столько скриптов, сколько вам нужно.

В настоящее время доступны следующие рабочие процессы для подключения к:

  • deploy: запускается, когда ваш код развертывается в Test или Live. Скрипты запускаются в целевой среде.
  • sync_code: запускается при выкладывании кода через Git или в Pantheon Dashboard. Сценарии выполняются в среде, к которой применяется commit.
  • сlone_database: запускается, когда данные клонируются между средами. Скрипты запускаются в целевой среде.
  • сlear_cache: запускается при очистке кеша. Сценарии выполняются в очищенной среде.

Каждый сценарий или действие состоит из type (в настоящее время поддерживается только webphp, что означает поддержку PHP-кода в целевой среде), description и script, путь к файлу сценария относительно вашего репозитория кода.

Итак, посмотрев файл pantheon.yml выше, вы увидите, что мы хотим запустить скрипт, private/scripts/circle_ci_notify.php, сразу после события deploy.

Шаг 2. Создание сценария PHP для вашего действия Quicksilver

Чтобы функционировать, наш хук действий Quicksilver по-прежнему нуждается в скрипте.

Наш скрипт вызовет новое действие сборки Circle CI API для повторного запуска тестов. Для этого нам нужно безопасным образом получить и сохранить учетные данные API-интерфейса Circle CI в среде Pantheon Test.

На панели инструментов Circle CI нажмите «Настройки учетной записи» в меню слева, а затем выберите вкладку «Токены API», чтобы создать новый токен API.

Введите новый токен описательного имени и нажмите «Создать новый токен».

Create a new API token

Теперь у вас есть токен API, который вы можете использовать, чтобы поговорить с Circle CI API.

Передача секретов API или других конфиденциальных данных для контроля версий считается плохой практикой. Поэтому давайте использовать более безопасный способ передать учетные данные API в свой сценарий, создав файл конфигурации и загрузив его в безопасное место на тестовом сервере.

В каталоге вне экспортируемого репозитория кода создайте файл с именем secrets.json. В этот файл поместите следующее содержимое:

Затем загрузите его в тестовую среду в каталоге с именем files/private, используя SFTP. Обратите внимание, что файловая система (каталог files на вашем сервере) отделена от кода, а файлы в ней никогда не переходят в управление версиями.

Командна Terminus site connection-info выводит информацию для подключения к вашей среде на основе метода сайта, среды и подключения, который вы передаете в качестве параметров.

Итак, чтобы подключиться к файловой системе вашей тестовой среды с использованием SFTP, вы можете использовать эту команду - как небольшой трюк, окружающий команду символами backtick (`) запускает команду print out вместо того, чтобы просто показывать ее вам (естественно, вы можете Также используйте ваш любимый SFTP-клиент):

Теперь, когда вы подключены к серверу, пришло время загрузить файл конфигурации:

Учетные данные уже установлены. Давайте создадим скрипт.

В вашем репозитории кода создайте каталог private/scripts, а внутри него добавьте новый скрипт PHP circle_ci_notify.php.

Это обычный PHP-скрипт, который запускается в целевой среде события - в случае события deploy - либо Test, либо Live.

Давайте пройдем по сценарию построчно.

В строках 2-5 сценарий проверяет, что он запускается в тестовой среде.

Затем в строке 8 он считывает параметры API из файла JSON, который вы только что загрузили в файловую систему, с помощью вспомогательной функции _get_secrets, указанной в конце файла, в строках 37-50.

Затем в строках 10-22 скрипт выдает HTTP-запрос Circle CI API для инициализации сборки.

Наконец, в строках 24-28 скрипт проверяет ответ от вызова API и выводит простое сообщение об успешном завершении. Если хотите, это хорошее место для дальнейшего развития: вы могли бы, например, сделать скрипт, отправляющий уведомление каналу Slack вашей команды!

Теперь все готово. Зафиксируйте и вставьте свои изменения в репозиторий Git.

Как только выполнение git push завершится, вы увидите следующий результат: Pantheon сообщит вам, что он обнаружил ваш вновь созданный файл pantheon.yml и применил его действия к среде Dev.

Однако, как я упоминал ранее, задача deploy запускается в целевой среде. Поэтому перед запуском нашего скрипта нам необходимо развернуть изменения в Test.

Давайте сделаем это, используя интерфейс командной строки Terminus (вы также можете использовать Web Dashboard, если хотите):

Наш скрипт Quicksilver теперь доступен в тестовой среде.

Чтобы увидеть его в действии, внесите изменения в кодовую базу среды разработки (например, установив новый плагин или изменив свою дочернюю тему) и зафиксируйте и развесьте свои изменения в Test.

Когда вы заходите в панель управления Circle CI, вы увидите, что новая сборка была запущена и запущена, проверяя, что первая страница вашего тестового сайта может быть загружена в порядке.

Вы также можете использовать Terminus для проверки правильности работы сценария. Для этого перед развертыванием изменений в командной строке выполните команду:

Теперь, когда развертывание завершится, вы увидите нечто подобное, рассказывая о вашем действии Quicksilver:

Заключение

Теперь установка автоматизированного тестирования завершена: всякий раз, когда вы развертываете код из среды Pantheon Dev для тестирования, новая сборка запускается на Circle CI и запускает тесты Behat для вашей тестовой среды. Если что-то пойдет не так, Circle отправит вам сообщение по электронной почте о сломанной сборке, чтобы вы могли исправить это и попробовать еще раз.

Но это только начало.

Во-первых, вам нужно будет написать больше тестов. Подумайте обо всех вещах, которые вы проверяете, чтобы убедиться, что ваш сайт работает правильно, а затем напишите функции Behat для их тестирования. Затем подумайте о том, как ваши посетители и клиенты могут использовать сайт, и напишите тесты для этих прецедентов.

Вы также можете улучшить конфигурацию Circle CI, например, добавив уведомление Slack об успешном тестировании. Таким образом, вы будете знать, что ваши автоматические тесты проходят и могут сделать окончательную проверку, прежде чем нажать изменения вживую. Позже, когда вы почувствуете уверенность в своих тестах, вы можете даже подумать об изменении вашего circle.yml, чтобы использовать Terminus для автоматического развертывания кода из Test to Live после успешной сборки!

Однако возможности здесь не заканчиваются! Вы также можете использовать Quicksilver для добавления автоматизированных сценариев в свой рабочий процесс. Взгляните на некоторые примеры от инженеров Pantheon. И создайте свои собственные!

Постепенно, когда вы автоматизируете свой процесс тестирования и разработки, вы создаете все более безопасный рабочий процесс.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.