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

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

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

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

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

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

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

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

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

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

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

Средство командной строки Pantheon, Terminus , позволяет вам делать все это и даже больше.

Шаг 1: Установите Terminus

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

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

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

• Версия PHP 5.5.9 или новее
• PHP-CLI
• PHP-CURL

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

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

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

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

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

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

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

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

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

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

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

Чтобы создать свой первый компьютерный токен, войдите в свою учетную запись Pantheon. Затем на вкладке « Учетная запись » выберите пункт меню « Жетоны компьютеров» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете сделать это через 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 параметра --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. Для этого мы будем использовать комбинацию серверного скриптового инструмента Pantheon Quicksilver и сервера непрерывной интеграции, работающего в облаке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы должны увидеть тестовый проход:

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

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

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

3. Запуск ваших тестов Behat в облаке

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

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

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

Шаг 1: отправь свои тесты в Git

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

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

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

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

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

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

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

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

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

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

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

Нажмите на кнопку Build project рядом с проектом.

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим на фрагмент.

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

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

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

Выполните фиксацию и снова внесите изменения и вернитесь к Circle CI, чтобы убедиться, что тесты теперь успешно выполнены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для работы нашей хуку Quicksilver все еще нужен скрипт.

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

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

Дайте вашему новому токену описательное имя и нажмите « Создать новый токен» .

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

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

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

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

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

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

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

Учетные данные теперь на месте. Давайте создадим сценарий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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