WordPress, SSH и GIT: рабочий процесс поддержания сайта

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

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

Требования

Я не готовил формального технического задания, но основные требования для себя сформулировал достаточно четко:

  • Контроль версий. Однажды освоив современные инструменты контроля версий, представить себе разработку без их использования просто невозможно. Даже в случае, если разработчик всего один, сайт обновляется и видоизменяется несколькими способами (через интерфейс сайта и в результате прямого редактирования кода разработчиком), хочется как минимум четко отделять эти изменения друг от друга, не говоря уже о логическом объединении связанных изменений (что при обычном регулярном бэкапе полностью теряется). Без VCS никуда.
  • Проверка изменений перед публикацией. Любые обновления, редактирование кода, изменение стилей и т.п. должны сначала проверяться на тестовой версии сайта, максимально приближенной к «боевой», чтобы изменения, сработавшие там, можно было без опасений применять к основному сайту. WAMP на локалхосте слишком отличается от реального хостинга.
  • Быстрая синхронизация рабочей станции с сервером. Раз уж мы сначала заливаем все изменения на тестовый сайт, почему бы не делать это как можно чаще? Ведь основной сайт это затрагивать не будет, а ошибки будут выявляться раньше.
  • Быстрая публикация проверенных изменений. Внесенные в тестовую версию и проверенные изменения должны легко и быстро переноситься на основную версию сайта прямо из тестовой, чтобы на основной версии не приходилось вносить изменения заново.
  • База данных тоже должна быть частью VCS. Иначе мы рискуем получить ситуацию несоответствия базы данных и кода (пример: откатились к старой версии сайта, а база осталась новая). Это может привести к самым разнообразным затейливым артефактам, на расковыривание которых потребуются часы и дни.

Концепция

WPgit-00-Concept

Данное решение позволяет реализовать все сформулированные требования.

  1. Хостинг — WebFaction. Лучший хостинг из всех, что мне известны.
  2. Основной и тестовый сайты будут физически находиться на одном и том же сервере, но в разных папках. Конфигурации будут идентичны за исключением имени папки (и, соответственно, URL сайта) и реквизитов доступа к БД. Далее под понятиями «основной сайт» и «тестовый сайт» будут пониматься эти две копии соответственно.
  3. Система управления версиями — git. Не требует выделенного сервера, не требует рутового доступа, или постоянно работающего демона. Мгновенное создание новых веток и многие другие фишки прилагаются. В интернетах есть хорошая подборка инструкций и учебников по GIT, там многое на русском языке.
  4. База данных хранится прямо в git в текстовом формате. Перед каждым коммитом (сохранением очередной версии в git) выгружается в файл при помощи mysqldump, после чекаута — загружается при помощи mysql. Таким образом, каждая версия проекта самодостаточна: содержит все скрипты, картинки, прочие файлы и полную копию базы данных на момент сохранения версии.
  5. Синхронизация выполняется при помощи rsync. Это работает очень быстро. После начальной синхронизации, последующие синхронизации перекачивают только изменившиеся кусочки файлов, что в большинстве случаев происходит за считанные секунды.
  6. Сайт настраивается таким образом, чтобы его можно было без каких-либо изменений копировать с основного сайта на тестовый и обратно. Это, пожалуй, самый хитрый пункт. Во-первых, для нормальной работы «красивых» ссылок в корневой папке сайта используется файл .htaccess, в котором прописаны конкретный URL сайта (в директивах mod_rewrite) и папка на сервере. Во-вторых, в конфигурационных файлах Wordpress прописываются реквизиты доступа к БД, которые не совпадают у основного и тестового сайтов. В-третьих, в самой БД в целом ряде мест содержится URL сайта. WordPress не будет корректно работать, если URL, с которого он открывается, не совпадает с тем, который прописан в базе.Все три проблемы удалось решить:
    • Небольшая regexp-магия в .htaccess позволяет одному и тому же файлу корректно работать из разных папок, доступных по разным URL (на собственном хостинге можно вообще отказаться от использования .htaccess и настроить для каждой папки свою конфигурацию).
    • Конфигурационные файлы составлены таким образом, чтобы определять, из какой папки запущен WordPress и, в зависимости от этого, подставлять разные значения реквизитов доступа к БД.
    • Одна и та же БД точно не может работать на двух разных версиях блога: URL сайта жестко прописан в нескольких местах, не говоря уже о внутренних ссылках в постах и на страницах. Чтобы решить эту проблему, я написал пару скриптов для выгрузки и загрузки БД, которые «на лету» заменяют данные, считываемые из SQL-дампа, или записываемые в него. Файл на диске всегда хранится в таком виде, как будто он выгружен с основного сайта. Но при выгрузке БД из тестовой версии, все вкрапления тестового URL «на лету» заменяются на основной URL. А при загрузке из файла в БД — наоборот, основной URL заменяется на тестовый. У этого решения есть одно существенное ограничение, о нём ниже.
  7. Т.к. на десктопе у меня Windows, пришлось установить Cygwin для работы rsync и всех скриптов автоматизации. Я использую 64-битную версию пакета. Важно правильно настроить языковые переменные, иначе имена файлов, содержащие русские буквы, будут изувечены до неузнаваемости. Можно было бы использовать виндовую реализацию rsync (cwRsync, DeltaCopy и т.д.), а скрипты переписать под cmd/PowerShell. Но Cygwin — более универсальный вариант. Функциональнее, чем cmd; не такой непривычный, как PowerShell; работает под разными ОС.

Недостатки, ограничения и умолчания

  1. Если поддержанием сайта занимается более 1-2 человек, или сайт часто обновляется/комментируется, rsync-синхронизации явно будет недостаточно. В этом случае можно поднять git-репозиторий в папке основного сайта, создать там несколько веток для разработчиков и одну для изменений, вносимых через интерфейс (на ней репозиторий будет находиться по умолчанию). В ветку по умолчанию будут входить все изменения, вносимые пользователями и администраторами сайта. В ветки разработчиков каждый из них будет отправлять свои изменения. И кто-то должен будет играть роль менеджера интеграции, объединяя изменения из девелоперских веток в основную ветку.
    Тестовый сайт каждому разработчику потребуется свой, можно их разместить в однотипных папках, например /dev123/, /dev124/ и т.д. Синхронизация с тестовым сайтом будет выполняться rsync-ом, в этой части ничего не меняется.
    Использование git на сервере несложно, команды там каждый раз одни и те же, для каждой можно создать локальный скрипт, который будет решать требуемую задачу одним кликом в меню любимой IDE без запуска интерактивной ssh-сессии (командами типа ssh -l username -i /my/private/key web.server.com "cd /home/username/webapps/production/service/merge_changes_from_dev_branch.sh"). Но для одиночного разработчика оно мне показалось избыточным, а воспринимается такая схема как-то менее прозрачно.
  2. Количество символов в URL основной и тестовой версий сайта должно совпадать (например, http://site.com/myblog и http://site.com/devblg). WordPress хранит часть данных плагинов в сериализованном виде, поэтому замена текста на текст другой длины приведёт к повреждению данных! Если нет никакой возможности сделать URL одинаковой длины, придется как-то прикручивать корректную обработку сериализованных данных при фильтрации. Это нетривиальная задача. Существующие скрипты поиска и замены данных в БД с учетом сериализации — достаточно объемные (для осознания масштабов катастрофы можно ознакомиться с исходниками плагина WP Migrate DB). Я решил, что проще сделать URL одинаковой длины.
  3. Я не рассматриваю настройку сайта, работающего по протоколу HTTPS. Это может быть как очень простой, так и довольно муторной задачей, в зависимости от того, каким хостингом вы пользуетесь. Если планируете использовать HTTPS — сначала настройте его на своём сайте и только потом приступайте к настройкам, которые я здесь привожу. Для перевода уже настроенного по моим рекомендациям сайта с HTTP на HTTPS потребуется много возни.

Памятка пользователям Windows

  1. Не забывайте про CRLF! Огромное количество проблем возникает из-за того, что текстовые редакторы в Windows по умолчанию ставят в конце каждой строчки сочетание CRLF, вместо принятого UNIX-стандарта LF. Включите в настройках своего текстового редактора UNIX-формат строк!
  2. Пути к файлам в UNIX используют прямые слеши (/). Cygwin превращает Windows-пути в UNIX-пути, добавляя в начале /cygdrive/<буква_диска> и преобразуя обратные слеши в прямые. Таким образом, c:\Users\username превращается в /cygdrive/c/Users/username.

Реализация

Для нормального восприятия написанного требуется понимать, как работает git, что такое commit, branch, stash, merge. Остальное, скорее всего, можно понять из контекста.

Хостинг

Прежде всего, надо подготовить хостинг: создать основной и тестовый сайты. Каждый хостинг-провайдер предлагает свои инструменты для этих целей. Я буду давать пояснения на примере WebFaction; если кто-то пришлёт инструкции для других хостингов — добавлю в пост.

WebFaction

Приложения

WebFaction предлагает концепцию приложений: каждое веб-приложение — это папка на диске плюс индивидуальные настройки веб-сервера для этой папки (версия PHP, например). Каждое приложение может обслуживать определённые папки на сайте (или нескольких сайтах).

Нам понадобится два приложения: основное и тестовое. Если нужен редирект из корневой папки сайта (http://mysite.com), понадобится третье приложение. Если используется HTTPS, понадобится четвёртое приложение на HTTP-сайте, чтобы редиректить все запросы на HTTPS-сайт, содержащий все наши остальные приложения.

Создаем основное приложение:

WebFaction Control Panel (CP) → Domains/Websites → Applications → Add new application:

WP-SSH-git Workflow: Add Application

Выбираем категорию — WordPress, тип приложения — последнюю доступную версию. Все приложения будут лежать в подпапке webapps вашей домашней папки (/home/<имя_пользователя>/webapps/<имя_приложения>). Имена приложений никак не связаны с теми URL, по которым они будут доступны пользователям вашего сайта! Эти имена предназначены только для владельца сайта.

Аналогично создаем тестовое приложение. Называем оба приложения понятными именами без пробелов и других спец. знаков (можно использовать подчеркивание). Я буду использовать production для основного сайта и development для тестового.

Не забываем о том, что все *nix-системы (90% вероятности, что на вашем хостинге Linux, или FreeBSD) различают прописные и строчные буквы в именах файлов, соответственно, production, Production и PrOdUcTiOn — это три разных имени. Во избежание лишних заморочек рекомендую использовать только строчные буквы.

При установке WordPress средствами WebFaction, автоматически создаются базы данных (в нашем случае — username_production_wp и username_development_wp, хотя из-за ограничения в 16 символов на длину имени БД, скорее всего, выглядит это примерно как username_product и username_develop; если ваше имя пользователя длиннее 5-6 символов, выберите более короткие имена приложений, например prd и dvl). Автоматически создаются и пользователи для доступа к БД (username_production и username_development, которые будут также обрезаны до 16 символов и, скорее всего, совпадут с именами БД), которым выдаются полные права доступа к соответствующим БД. Пароли этих пользователей можно посмотреть в свойствах созданных приложений, в поле Extra info. Этот же пароль является паролем пользователя admin.

Приложения для редиректа создаем с параметрами: категория — Static, тип — Static/CGI/PHP-5.5.

WP-SSH-git Workflow: Add Redirect Application

Пока достаточно создать приложение. Делать сам редирект мы его научим позже.

Сайт

Теперь создаем сайт:

WebFaction Control Panel (CP) → Domains/Websites → Websites → Add new website:

WP-SSH-git Workflow: Add WebsiteНабираем имя нашего домена (он должен быть уже зарегистрирован на хостинге), нажимаем Add an application → Reuse an existing application. В первую очередь выбираем приложение для обслуживания корневой папки (у нас это redirect):

WP-SSH-git Workflow: Reuse Application

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

WP-SSH-git Workflow: Reuse Application 2

WP-SSH-git Workflow: Reuse Application 3

WP-SSH-git Workflow: Reuse Application 4

Сохраняем. Применение настроек на сервере обычно занимает несколько минут.

Немного подождав, открываем в браузере

http://mysite.com/:

WP-SSH-git Workflow: Freshly Installed Redirect

http://mysite.com/myblog:

WP-SSH-git Workflow: Freshly Installed WordPress 1

http://mysite.com/devblg:

WP-SSH-git Workflow: Freshly Installed WordPress 2

Если вместо этого вы видите сообщение WebFaction Site Not Configured — значит, надо подождать ещё немного, изменения ещё не применились на сервере. Минут за пятнадцать точно должно заработать, в противном случае надо обращаться в техподдержку.

“Hello, world” на пустом экране — это index.html, созданный по умолчанию. Сейчас самое время вместо этого настроить редирект на /myblog, чтобы потом этим не заморачиваться.

Редирект

Для редиректа из корня в блог создаем в папке приложения следующие файлы:

На самом деле, в index.html можно вообще ничего не писать, лишь бы сам файл присутствовал. Я, тем не менее, стараюсь делать файлы минимально осмысленными — это облегчает отладку, если что-то идёт не так. Редирект будет происходить только в случае обращения к корневой папки сайта, при указании конкретного файла редиректа не будет. Можно положить в папку этого приложения какие-нибудь статические файлы, которые должны быть доступны по короткому адресу. Например, favicon.ico — всякие там RSS-ридеры при выборе иконки для вашего фида часто смотрят только в корневую папку сайта (http://mysite.com/favicon.ico). Если ваш блог должен быть доступен через RSS — учтите.

WordPress

Установки WordPress я касаться не буду. В случае с WebFaction (и многими другими хостингами) основную работу по установке выполняет сам хостинг. Инструкциями по самостоятельной установке завален весь интернет. Я предполагаю, что на данный момент мы имеем две свежеустановленные копии WordPress с настройками по-умолчанию, расположенные в разных папках и подключенные к разным БД.

Все файлы одной копии (например, development) нужно сразу удалить (чтобы не было каких-нибудь накладок). От неё нам понадобится только БД (и то, всё содержимое перезапишем). Вторую копию (production) мы настроим таким образом, чтобы она сохраняла работоспособность при переносе её файлов и БД поверх первой.

Обновление и базовые настройки

Заходим пользователем admin в систему. Открываем Dashboard. При необходимости меняем пароль, заданный (сгенерированный) при установке на нормальный. Обновляем WordPress, темы, плагины.

WP-SSH-git Workflow: Update WordPress

Устанавливаем необходимые нам плагины. Настраиваем всё, что настраивается через админский интерфейс.

Включаем пермалинки на странице настроек (Settings → Permalinks). Данная инструкция проверялась с форматом пермалинков Day and Name (/%year%/%monthnum%/%day%/%postname%/), но должна работать и с другими вариантами.

.htaccess

После включения пермалинков, WordPress автоматически создает в своей корневой папке файл .htaccess. Его надо будет полностью заменить файлом следующего содержания (во всех регулярных выражениях, конечно, надо заменить myblog|devblg на адреса ваших приложений — основного и тестового соответственно):

В файле упоминается папка /service — в ней у нас будут храниться всякие полезные скрипты, которые должны вызываться локально на машине разработчика, или на сервере по ssh. Они не должны быть доступны через web, поэтому при попытке открыть ссылку, содержащую адрес этой папки, будет происходить редирект на главную страницу блога.

Этот файл будет корректно работать из обеих наших папок. Если тестовых папок несколько для разных разработчиков, во всех регулярных выражениях надо добавить соответствующие изменения (myblog|devblgmyblog|dev001|dev002|dev003, например).

wp-config.php

Основной конфигурационный файл WordPress надо изменить совсем незначительно. Достаточно вместо:

прописать примерно следующее:

Скрипт проверяет совпадение начальной части запрошенного URL с адресом тестового приложения и подставляет правильные значения реквизитов доступа к БД.

Также рекомендую добавить в самое начало wp-config.php следующие строчки:

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

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

Серверные скрипты

Создаем на сервере папку service (/home/username/webapps/production/service), в которую сложим скрипты для сохранения и выгрузки БД с автоматической загрузкой URL.

Скрипты:

Как это работает?

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

init.sh определяет, в зависимости от того, в какой папке он находится, реквизиты доступа к БД.

db-store.sh делает дамп БД в файл, заменяя на ходу параметры тестового сайта на параметры основного. db-restore.sh восстанавливает БД из дампа, заменяя параметры основного сайта на параметры тестового при необходимости.

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

Обращаю внимание на опцию --skip-extended-insert. При её использовании каждая запись в БД выгружается в виде отдельного оператора INSERT, в результате файл получается гораздо больше. Однако, изменения между версиями будут гораздо меньше, а сравнение между двумя версиями БД при помощи git будет гораздо проще: изменения в БД будут показаны как вставка и удаление отдельных строчек.

Помимо URL сайта и имени БД данные скрипты заменяют название сайта. Это вовсе необязательно и соответствующую строчку можно убрать. Однако, я нашел удобным, что при работе в тестовой версии сайта это чётко видно в заголовке. Иначе легко можно забыть, в боевой, или тестовой версии вносились изменения, в результате будут потеряны данные.

Не забудьте сделать chmod +x на все скрипты, иначе система не позволит их запускать.

Проверка работоспособности

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

Убедимся, что тестовый сайт не работает (вы же удалили из его папки все файлы?) и адрес http://mysite.com/devblg ничего внятного не показывает.

WP-SSH-git Workflow: Nothing to see here

Логинимся на сервер по SSH (Putty, Cygwin/ssh).

WP-SSH-git Workflow: Putty 1

Сохраняем базу основного сайта:

Копируем все файлы в тестовую версию и восстанавливаем БД из сохраненной копии уже в тестовой версии:

WP-SSH-git Workflow: Putty 2

Тестовый сайт должен заработать и быть идентичен основному, за исключением заголовка, который должен превратиться из “My blog” в “TEST ENVIRONMENT”.

WP-SSH-git Workflow: Risen from Ashes

Особенно тщательно проверьте правильность ссылок: если попытка открыть единственный имеющийся пока пост (“Hello, world!”, созданный по умолчанию) перебрасывает вас на основной сайт — значит, URL сайта корректно не заменяется скриптом при загрузке. В случае возникновения проблем подобного рода внимательно изучайте и корректируйте параметры sed.

Cygwin

Для работы скриптов автоматизации и rsync нам понадобится UNIX-совместимая среда. Для Windows наиболее оптимальный вариант — установить Cygwin.

Помимо базового набора, выделенного по умолчанию, нам понадобятся пакеты Net/openssh и Net/rsync. Инсталлятор Cygwin — на самом деле, что-то типа менеджера пакетов. Можно его потом запускать повторно, чтобы установить обновления, удалить, или откатить к более старой версии любой пакет, или группу пакетов и т.п.:

WP-SSH-git Workflow: Cygwin

Ключи SSH

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

После того, как ключи созданы и добавлены на сервере, обязательно проверяем при помощи ssh из-под терминала Cygwin:

При первом запуске ssh предложит добавить сервер в список доверенных. Надо ответить yes.

WP-SSH-git Workflow: SSH

Rsync

Скачаем основную копию сайта в локальную папку на диске при помощи rsync и ssh:

Потом не помешает зайти на сервер по ssh и дать права на запуск скриптов в папке service.

git

Устанавливаем git, если его у нас нет. Настраиваем в соответствии с документацией.

Запускаем git Bash, создаем пустой репозиторий в папке, в которую скачали наш сайт (допустим, это d:\temp\site):

Теперь самое время настроить .gitignore. Создаем файл следующего содержания:

Последние две строчки можно не включать, если вы не пользуетесь IDE от JetBrains (PhpStorm/IntelliJ IDEA и т.д.).

Теперь можно и первый коммит сделать:

Не тему того, как работать с git написаны целые тома, здесь я рассматривать этот вопрос не буду.

Сценарии использования

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

Вспомогательные скрипты

С целью облегчения и ускорения работы я использую ряд локальных скриптов. Для удобства, я их складываю в ту же папку service, но предваряю знаком - (минус), чтобы не перепутать со скриптами, предназначенными для запуска на сервере.

Скрипты запускаются под Cygwin:

Удобно добавить их в качестве внешних инструментов в вашу IDE.

Несколько простых вспомогательных скриптов, полезных для реализации приведенных далее сценариев:

Плюс четыре аналогичных скрипта (-prod-pull.sh, -prod-store-db-and-pull.sh, -prod-push.sh, -prod-push-and-restore-db.sh) для основной копии сайта (вместо /development/ везде путь /production/).

Скрипт -***-pull.sh забирает изменения с сервера (тестового, или основного сайта). -***-store-db-and-pull.sh сначала заставляет сервер выгрузить БД в файл, потом забирает изменившиеся файлы на локальную машину.

Используются эти скрипты, чтобы забрать изменения с сайта. Редактирование постов, комментирование, установка новых плагинов, автоматические обновления. В большинстве случаев надо использовать -***-store-db-and-pull.sh, чтобы вместе с изменением файлов забрать с сервера актуальную версию БД. Перед использованием необходимо убедиться, что все локальные изменения сохранены в git! Тогда, стянув изменения с сервера, можно в удобной форме diff-ов увидеть, что конкретно поменялось и интегрировать эти изменения в локальную копию.

Скрипт -***-push.sh отправляет изменения на сервер (тестовый, или основной сайт). -***-push-and-restore-db.sh сначала отправляет изменения на сервер, а потом заставляет его загрузить .sql файл в БД.

При использовании этих скриптов важно убедиться, что на сайте не произошло никаких существенных изменений, т.к. они будут перезаписаны! Более того, ключ –delete заставит rsync удалить на сервере любые файлы, которых нет в локальной копии. Пользоваться надо очень аккуратно. Если изменения на сервере происходят очень быстро (пока загружаешь данные с сервера, интегрируешь изменения и готовишься отправить их обратно на сервер, пользователи сто комментариев могут написать, которые будут перезаписаны), эти скрипты плохо подходят, требуются более умные варианты синхронизации.

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

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

Интеграция повседневных изменений

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

Последовательность действий, которую я использую:

  1. git add --all
  2. git commit / git stash (в зависимости от стадии готовности локальных изменений)
  3. git checkout content (ветка, которую я использую для интеграции повседневных изменений)
  4. -prod-store-db-and-pull.sh
  5. git add -all
    git commit -m "Content integration date +%F_%H-%M-%S"
    git checkout master
    git merge content
  6. Если делали git stash, то вытаскиваем изменения при помощи git stash pop, смотрим диффы, применяем, продолжаем работать.

Существенные обновления средствами WordPress

Под существенными изменениями я подразумеваю обновление ядра системы, тем оформления и плагинов. Интегрируются аналогично повседневным, но я, при этом:

  • Сначала проверяю корректность работы обновлений на тестовом сайте.
  • Интегрирую все контентные изменения с основного сайта (см. предыдущий пункт).
  • Применяю обновление.
  • Ещё раз забираю контентные изменения с сайта, но использую другую ветку git (upstream вместо content). Интегрирую обе ветки в master (чтобы content всегда содержал актуальную версию основного сайта).

Интеграция локальных правок кода

  • В процессе написания и отладки постоянно синхронизируюсь с тестовым сайтом, проверяю работу каждого изменения.
  • Когда изменения отлажены, делаю коммит в основную ветку (ветка content остается в том состоянии, в котором она была при последней интеграции
  • Делаем коммит с отлаженными изменениями в основную ветку.
  • Вытаскиваем и применяем текущие изменения (см. предыдущий пункт).
  • Заливаем получившееся на тестовый сайт.
  • Если всё ок — заливаем то же самое на основной.

В будущих обновлениях

  1. Инструкции для разных хостингов (присылайте!).
  2. Подробное описание схемы с git на основном сайте.
  3. Картинки, иллюстрирующие передачу изменений между сайтами и разными ветками git.
  4. Использование SFTP в Total Commander.
  5. Доработанные скрипты (принимаю пожелания и замечания).
  6. Техника безопасности при работе с rsync (в текущей конфигурации довольно просто что-нибудь поломать при неправильном использовании).
  7. Использование Jetpack в данной конфигурации (есть подводные камни).
  8. Разбиение blog.sql на отдельные файлы с постами, комментариями и т.д. для более понятного отражения изменений.
  9. Прячем тестовый сайт от поисковых систем и любопытных глаз посторонних.

Дополнительные материалы

Наверх ↑

Если раньше работать с системами управления версиями не приходилось, настоятельно рекомендую прочитать хотя бы статью в Википедии. Суть в следующем: каждое изменение сохраняется в специальной базе данных. В любой момент можно вернуться к любой из предыдущих версий проекта целиком, отдельных файлов и даже отдельных участков кода. Можно использовать несколько независимых веток разработки, разделяя и соединяя их при необходимости. Можно синхронизировать свои ветки с ветками других разработчиков, обмениваясь изменениями. Можно делать столько разных крутых штук! Жизнь программиста без использования VCS — не жизнь, а прозябание.
Типичная IDE со встроенным [S]FTP-клиентом, конечно, имеет функцию синхронизации. Но в большинстве случаев это чудовищно медленно! Приходится хитрить, не выполнять полную синхронизацию после каждого изменения, полагаться на собственную память, или IDE, чтобы закачивать только те файлы, в которые внесены изменения, рассчитывая на то, что эти файлы не изменились на сервере, пока ты их редактировал локально.
Хостинг заточен под разработчиков веб-приложений. Очень быстро актуализируют версии всего серверного ПО, «из коробки» есть весь необходимый инструментарий (тот же git). Всевозможные скриптовые языки, базы данных, предустановленные основные фреймворки — одновременно несколько версий для максимальной совместимости (например, Python имеется всех версий от 2.6 до 3.4). Производительность отличная; после Bluehost, на котором WordPress последней версии ползал, как дохлая муха — просто фантастика (при том, что там он работал по HTTP, а здесь — по HTTPS). Удобно смотреть логи: они все лежат в одной папочке, аккуратно разложенные по приложениям. Служба техподдержки реагирует на запросы очень быстро и реально помогает (помогли мне установить SSL-сертификат буквально через полчаса после обращения). Первый хостинг, о котором не удалось найти ни одного плохого отзыва.Если заинтересовало — пожалуйста, воспользуйтесь моей ссылкой. Вам всё равно, а мне чуток капнет на оплату хостинга, если вы оплатите там что-нибудь.
IDE я здесь и далее употребляю в узком смысле, подразумевая интегрированную среду разработки с графическим интерфейсом. Лично мне больше всего нравятся IDE от JetBrains (IntelliJ IDEA и производные).
WebFaction не предоставляет веб-интерфейса для работы с файлами (хотя можно установить свой в качестве приложения). Вместо этого можно воспользоваться FTP/SFTP/SCP-клиентом (Total Commander умеет в SFTP при помощи плагинов), или залогиниться на сервер по SSH (под Windows рекомендую Pytty) и воспользоваться любым консольным текстовым редактором — vim, nano, встроенный редактор mc, echo "text" >> filename.ext… :-)
Apache mod_rewrite многим кажется черной магией. Мне тоже так казалось, до тех пор, пока я не изучил вот это:

Ценность информации по ссылкам трудно переоценить. Магия превращается в науку, прыганье с бубном — в целенаправленную аналитическую работу.

Кто пользуется PhpStorm — там в настройках внешних инструментов есть опция Open Console — при её включении вывод всех команд перенаправляется в интегрированное служебное окошко, а не в открываемое поверх всего новое окно.