Развертывание в Live и подготовка с помощью Deploybot

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

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

Сегодня мы собираемся решить эту проблему, используя Git и Deploybot для автоматизации процесса развертывания.

Что такое автоматическое развертывание?

Базовое автоматизированное развертывание состоит из четырех частей, как показано на этой схеме.

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

Следующим шагом, который предпринимают многие разработчики, является добавление промежуточного сайта, чтобы они не модифицировали рабочий сервер напрямую. Вы можете сделать это с помощью чего-то вроде VVV или MAMP. Часто это также означает, что вы используете систему контроля версий, такую ​​как Git, для управления изменениями, которые вы вносите на свой локальный рабочий сайт.

Когда вы добавляете промежуточный сайт, вы также добавляете сложности. Как перенести изменения кода с локального рабочего сайта на тестовый сайт, где ваш клиент может увидеть изменения? Да, как я уже сказал, вы можете использовать базовый FTP-клиент, такой как FileZilla, Transmit или Forklift, для перемещения файлов по мере внесения изменений, но это чревато ошибками, и именно здесь автоматизация процесса развертывания сэкономит вам много времени.

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

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

Итак, теперь у вас есть система, которая выглядит так.

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

Как структурировать репозиторий Git

Ваш первый выбор: в каком каталоге вы будете настраивать автоматическое развертывание? Если мой клиент специально не запрашивает полный контроль над исходным кодом для своей установки WordPress, я использую каталог wp-content для настройки моей системы автоматического развертывания. Это начинается в терминале, выполнив эту команду, которая инициализирует репозиторий git.

git инициировать

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

конфиг/app_config.yml

конфиг/база данных.yml

конфиг/*.sphinx.conf

config/s3_credentials.yml

*~

*.кэш

*.журнал

*.пид

тмп/**/*

.DS_Store

БД/cstore/**

дб/сфинкс/**

документ/апи

документ/приложение

документ/плагины

документ/*.точка

покрытие/*

БД/*.sqlite3

*.tmproj

*.sw?

*.esproj

_заметки*

dwsync.xml

подкаст.xml

*.кпф

*загрузки/*

*.swp

*.идея

*.sublime-проект

*.sublime-рабочая область

*/node_modules/*

теги

*.бак

кеш/*

управлятьwp/*

мю-плагины/*

дп.php

восходящий поток/*

языки/*

db.php

плагины/wp-ракета/cache.json

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

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

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

git checkout -b постановка

Эта команда создает и проверяет новую ветку. Если вы новичок в git, вы можете найти дополнительную информацию о доступных командах в документации Git.

Теперь вам нужно отправить свой проект в систему управления версиями. Github и Bitbucket — два популярных варианта, оба из которых работают с системой автоматического развертывания, которую мы собираемся использовать, под названием Deploybot. Когда вы создаете новый репозиторий на любом сайте, они дадут вам дальнейшие указания по добавлению вашего локального репозитория в вашу онлайн-версию в Github или Bitbucket.

• Документация по настройке репозитория Bitbucket
• Документация по настройке репозитория Github

Настройка Deploybot

Когда я впервые начал более сложную работу в качестве разработчика, мой друг Дуэйн продолжал рекомендовать мне Deploybot, когда я жаловался в Интернете на беспорядок ручного развертывания FTP. Мне потребовалось несколько рекомендаций, прежде чем я, наконец, сделал то, что мне сказали, но теперь я счастливый клиент Deploybot уже много лет.

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

Чтобы начать работу, зарегистрируйте учетную запись Deploybot и подключите Github или Bitbucket к своей учетной записи. Сегодня я буду использовать свою существующую учетную запись Bitbucket. Начните с добавления нового репозитория в свою учетную запись Deploybot.

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

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

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

Когда вы закончите, нажмите кнопку « Сохранить » в нижней части страницы, чтобы перейти к конфигурации вашего сервера.

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

Введя информацию о sFTP, вы можете прокрутить вниз и сохранить ее. Затем Deploybot проверит ваше соединение, чтобы убедиться, что предоставленная вами информация работает. Теперь пришло время выполнить начальное развертывание сайта, чтобы убедиться, что все работает. Я часто добавляю файл test.txt в развертывание, чтобы убедиться, что развертывание работает правильно.

Чтобы начать развертывание в журнале среды, нажмите «Развернуть».

Теперь вы увидите страницу с вашим последним сообщением о фиксации git в качестве примечания, которое вы увидите внутри Deploybot рядом с этим развертыванием. Для больших изменений я изменю это, но если я просто изменяю CSS или что-то незначительное, сообщение фиксации может остаться. Поскольку это промежуточная версия, каждая фиксация в нашей промежуточной ветке будет развертываться автоматически, а это означает, что будут отображаться ваши сообщения фиксации. Это только начальная фиксация, которую нам нужно сделать вручную на нашем промежуточном сайте.

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

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

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

Вы можете сделать это с помощью этих команд.

мастер проверки git

постановка слияния git

мастер происхождения git push

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

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

Другие соображения по развертыванию

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

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

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

Независимо от того, что вы решите сделать, прекратите использовать FTP-клиент для развертывания клиентских файлов уже сегодня. Небольшая ежемесячная стоимость Deploybot возмещается каждый раз, когда вы не совершаете ошибок при развертывании файлов.