Современные развертывания для ваших сайтов WordPress

Если вы похожи на меня, ваш первый опыт отправки файлов на веб-сервер был либо через веб-файловый менеджер, такой как cPanel, либо через клиент протокола передачи файлов (FTP), такой как Transmit или Filezilla. Подключитесь к серверу, перетащите файлы и дождитесь завершения передачи.

Легко, верно?

Однако, как только я начал работать с чем-то более сложным, чем статические HTML-файлы, развертывание моего кода стало намного сложнее: что произойдет, если я пропущу файл, который требуется другим, или точку с запятой в глобальном включении, и это высветит белый экран весь сайт? Что, если важный шаг будет пропущен в процессе?

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

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

Отслеживание изменений с помощью контроля версий

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

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

Если вы раньше не работали с Git, не бойтесь: мы написали как введение в Git, так и статью о более сложных рабочих процессах Git.

Решить, что отслеживать

Когда мы переводим наш сайт под контроль версий, то, что мы не отслеживаем, почти так же важно, как и то, что мы делаем:

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

Например, если вы используете препроцессор CSS, такой как Sass, сгенерированные файлы CSS не должны отслеживаться системой контроля версий. Они не только легко воспроизводимы, но и трудно читаемы, а также являются частым источником конфликтов слияния, когда участвуют несколько разработчиков.

Когда дело доходит до зависимостей (библиотеки, плагины WordPress и т. д.), используйте такие инструменты, как Composer и WPackagist, а не связывайте код, за который вы не несете ответственности, в своем репозитории.

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

Структурирование вашего репозитория

При настройке репозитория Git для сайта WordPress или WooCommerce, как правило, лучше всего рассматривать wp-content/ как корень репозитория, так как обычно вы не будете касаться файлов выше этого каталога.

Плагины и темы, которые использует ваш сайт, но вы не поддерживаете код, должны быть загружены через Composer, поскольку они являются внешними зависимостями. Точно так же обработанные файлы CSS и JavaScript должны быть исключены через файл .gitignore, так как эти артефакты будут созданы для нас как часть нашего процесса выпуска.

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

Введение в CI/CD

Когда дело доходит до развертывания программного обеспечения, необходимо понимать два важных термина: непрерывная интеграция (CI) и непрерывная доставка (CD).

Эти два термина настолько тесно связаны, что их часто называют «CI/CD», и путь, по которому проходят наши изменения, таким образом, становится «конвейером CI/CD». Этот конвейер обычно принимает следующий вид:

1. Соберите релиз: установите зависимости (Composer, npm и т. д.), затем соберите артефакты (Webpack, Grunt, Sass и т. д.)
2. Тестируйте сборку: запускайте модульные тесты, проверяйте стандарты кодирования, выполняйте статический анализ кода и т. д.
3. Разверните выпуск в одной или нескольких средах

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

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

Однако непрерывная интеграция не ограничивается модульными тестами, поскольку существует ряд проверок «без кода», которые можно запускать автоматически для вашего кода, в том числе:

• Проверка стандартов кодирования (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Статический анализ кода (PHPStan, Psalm)

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

Непрерывная доставка , с другой стороны, — это идея о том, что мы должны иметь возможность «доставить» (развернуть) наш код в любой момент. Для этого у нас должен быть сценарий процесса развертывания, который одним нажатием кнопки плавно переместит наш код в производство.

Наличие сценария развертывания означает, что вы можете выполнять развертывание как регулярно , так и последовательно ; каждое развертывание должно работать так же, как и предыдущее. В результате ваша команда может выполнять развертывание более регулярно с более высоким уровнем уверенности и меньшим беспокойством о том, что кто-то пропустил шаг на этом пути. Для некоторых команд не редкость развертывание десятки (или даже сотни) раз в день!

В зависимости от вашего сайта вы можете даже заглянуть в «другой компакт-диск», Continuous Deployment ; это очень похоже на непрерывную доставку, но в этой модели каждое нажатие на ветку развертывается автоматически. Это может быть чрезвычайно полезным при использовании разветвленной схемы управления версиями (например, Github Flow), но может быть нежелательным, если вам нужно запланировать окна выпуска или выполнить всю работу в основной ветке.

Развертывание сайта WordPress или WooCommerce с CI/CD

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

В этом упражнении мы будем использовать Branch, инструмент CI/CD, разработанный с учетом потребностей разработчиков WordPress от тех же людей, что и WP Pusher. Лучше всего то, что Branch имеет встроенную поддержку для развертывания в Nexcess!

Чтобы начать работу, зарегистрируйтесь в Branch, подключив свою учетную запись GitHub, GitLab или Bitbucket, а затем создав свой первый сайт.

Далее мы хотим настроить все шаги, необходимые для создания нашего сайта. Branch предлагает ряд «рецептов» для общих действий (установка зависимостей Composer, запуск Webpack и т. д.), но также дает нам возможность добавлять любое количество пользовательских шагов.

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

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

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

Branch содержит рецепты развертывания на Nexcess (а также других крупных хостинг-провайдеров), и подключение двух платформ безболезненно:

1. Выберите свой сайт на панели инструментов Branch, нажмите «Настройки», затем получите открытый SSH-ключ вашего сайта Branch.
2. Добавьте этот открытый ключ в список ключей на портале Nexcess.

Как только Branch сможет связаться с вашим сайтом Nexcess, мы можем выбрать рецепт развертывания «Nexcess» и заполнить несколько деталей:

1. Имя хоста и имя пользователя для сайта (доступны через портал Nexcess на экране «Доступ» вашего сайта)
2. Корневой веб-сайт, на который мы развертываем. Если наш репозиторий git предназначен для использования в качестве каталога wp-content/, это значение должно быть «public_html/wp-content».
3. Файлы, которые мы хотим развернуть (обычно достаточно «*» по умолчанию)
4. Ветка git для развертывания в этой среде

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

Стоит отметить, что Branch по умолчанию использует модель непрерывного развертывания , когда конвейер запускается при каждой отправке в данную ветвь. Если вы предпочитаете более непрерывную модель доставки (где должны быть предприняты некоторые ручные действия), вы можете рассмотреть возможность сохранения «производственной» ветки, которая будет объединена только тогда, когда вы будете готовы к выпуску.

На этом этапе Branch должен быть настроен для сборки и развертывания репозитория git в Nexcess! Вы можете инициировать свое первое развертывание, нажав кнопку «Запустить развертывание» на странице «Конвейеры» вашего сайта или отправив запрос в свой репозиторий Git.

Настройка процесса выпуска

Одной из действительно приятных функций Branch является возможность настройки дополнительных шагов после успешного развертывания, таких как автоматическая очистка кэша объектов вашего сайта после развертывания. Это можно сделать с помощью рецепта WP-CLI в разделе «Другое».

Хост и имя пользователя, как правило, будут такими же, как мы использовали на этапе развертывания, и вы можете связать столько команд, сколько необходимо.

Вывод

Если вы все еще боретесь с выходками ковбойского кодирования и/или пронизанными тревогой релизами, взгляните на Branch и упростите развертывание!