Разработка, тестирование и выпуск

10

Как вы разрабатываете, тестируете и разворачиваете свои Wordpress-сайты?

Я всегда нахожу что-то вроде ошибки, особенно когда речь идет о базах данных - в основном из-за того, что для сайта тестирования требуется развернуть целую новую базу данных, которая иногда может быть ТОЧНО одинаковой, за исключением того, что все ссылки изменяются на URL сайта тестирования, вместо живого сайта.

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

Как это делают другие? Ты просто миришься с фаффом? Используете ли вы умные системы контроля версий, которые помогают?

Спасибо

testing Томас Клейсон
источник
Если вы заставляете систему вращаться вокруг изменения файла hosts , то вам никогда не придется копаться в вашей тестовой БД. ( wordpress.stackexchange.com/a/10943/9142 )
Александр Берд

Ответы:

12

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

  1. Вот аналогичный вопрос, который имеет много объяснений.
  2. Для развертывания контента вы можете воспользоваться плагином Crowd Favorite RAMP .
  3. WP Hackers - отличная тема для поиска полезной информации о развертываниях.

Лично я удостоверяюсь, что никогда не кодирую абсолютные URL-адреса в своих темах. Используйте bloginfo () или код относительно URL. Я использую много условных выражений в моем файле wp-config.php. Вот ванильная версия моих изменений в wp-config.

switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

Я работаю на многих сайтах, которые следуют

  • локальный (персональный взлом на моем ноутбуке)>
  • dev (тестирование на клиентском сервере)>
  • stage (стабильный источник для QA - редактирование контента)>
  • производство (живой сайт)

Наконец, я бы посоветовал вам использовать инструмент управления версиями, чтобы помочь в ваших развертываниях, таких как GIT или SVN. Это значительно облегчает процесс и поддерживает целостность источника между средами. Обязательства к вашему местному легко обновляются через командную строку на стадии и производстве. Во время обнаружения лучше всего определить, какой контроль версий вы и клиент будете использовать с самого начала, если у них есть разработчики, работающие над проектом. Я лично использую GIT для контроля версий. Тем не менее, если клиент использует SVN, я делаю смесь из двух на своем локальном компьютере, поэтому я поддерживаю репо для себя, в то же время фиксируя его репо.

У нас редко бывают проблемы с миграцией из одной среды в другую. Мы делаем поиск / замену в БД, чтобы соответственно изменить URL-адрес для встроенного носителя и т. Д.

Брайан Фегтер
источник
Это очень полезно! :) Большое спасибо. Таким образом, каждый раз при развертывании на каждом из разных серверов вы дублируете базу данных с живого сайта? Вы говорите, что развертываетесь на промежуточном сервере (stage.domain.com) для проверки качества и редактирования контента. Что произойдет, если база данных изменится во время работы сценического сервера на работающем сайте? т.е. вы или ваш клиент заходите на сцену и обновляете некоторый контент, но в то же время участник публикует новую статью на живом сайте? Вы просто вносите изменения в контент СНОВА на живом сайте? Как вы справляетесь с изменениями структуры базы данных?
Томас Клэйсон
Извините за все вопросы! Я очень благодарен за ваше время и помощь.
Томас Клэйсон
На новый набор функций, вы можете вытащить из prod> stage. Добавьте содержимое для новой функции, затем нажмите back stage> prod. Отсюда, stage - это высококачественная копия prod, и вы можете выбрать stage> dev. Не часто мы вытаскиваем БД из сцены. Большинство обменов с БД происходит от этапа к продукту, если функция не меняет архитектуру БД.
Брайан Фегтер
Если вы хотите использовать stage для развертывания контента и никогда не трогать prod, вы можете проверить плагин RAMP, который я выложил ранее.
Брайан Фегтер
+1 все выше, при условии, что некоторые раздражающие плагины настаивают на хранении URL-адресов в сериализованных массивах, которые могут испортить перемещение объектов из одной базы данных env в другую. Проблема заключается в том, что в сериализованных массивах хранятся длины строк, и они изменяются при изменении длины. Таким образом, я бы рекомендовал сохранять доменные имена env такими же, если это возможно, например, dev.example.com, tst.example.com, www.example.com и т. Д.
webaware