улучшить нашу стратегию развертывания

У нас есть приложение для электронной коммерции, которое мы разрабатываем в нашей компании. Это довольно стандартное приложение LAMP, которое мы разрабатываем около 3 лет. Мы разрабатываем приложение в тестируемом домене, добавляем новые функции, исправляем ошибки и т. Д. Наше отслеживание ошибок и разработка функций управляются в рамках размещенного решения Subversion (unfuddle.com). Как сообщается об ошибках, мы делаем эти исправления в тестируемом домене, а затем фиксируем изменения в svn, когда мы рады, что ошибка была исправлена. Мы следуем той же процедуре с добавлением новых функций.

Здесь стоит указать общую архитектуру нашей системы и приложений на наших серверах. Каждый раз, когда разрабатывается новая функция, мы распространяем это обновление на все сайты, использующие наше приложение (всегда сервер, которым мы управляем). Каждый сайт, использующий нашу систему, по существу использует одни и те же файлы для 95% кодовой базы. У нас есть несколько папок на каждом сайте, которые содержат файлы, предназначенные для этого сайта - css файлы / изображения и т. Д. Кроме того, различия между каждым сайтом определяются различными параметрами конфигурации в базе данных каждого сайта.

Это касается самого фактического развертывания. Когда мы готовы развернуть какое-либо обновление, мы запускаем команду на сервере, на котором находится сайт тестирования. Это выполняет команду копирования (cp -fru / testsite / / othersite /) и проходит через каждую силу vhost, обновляя файлы на основе даты изменения. У каждого дополнительного сервера, на котором мы размещаем, есть виртуальный хост, к которому мы производим синхронизацию рабочей кодовой базы, и затем мы повторяем процедуру копирования на всех сайтах на этом сервере. Во время этого процесса мы удаляем файлы, которые мы не хотим перезаписывать, возвращая их обратно после завершения копирования. Наш сценарий развертывания выполняет ряд других функций, таких как применение команд SQL для изменения каждой базы данных, добавление полей / новых таблиц и т. Д.

Мы становимся все более обеспокоенными тем, что наш процесс недостаточно стабилен, не отказоустойчив, а также является методом грубой силы. Нам также известно, что мы не наилучшим образом используем Subversion, поскольку у нас есть положение, при котором работа над новой функцией не позволит нам выкатить важное исправление ошибки, поскольку мы не используем ветви или теги. Также кажется неправильным, что у нас так много репликации файлов на наших серверах. Мы также не можем легко выполнить откат того, что только что выкатили. Мы выполняем diff перед каждым развертыванием, чтобы мы могли получить список файлов, которые будут изменены, чтобы мы знали, что было изменено после, но процесс отката все еще будет проблематичным. Что касается базы данных, я начал рассматривать dbdeploy как потенциальное решение. Мы действительно хотим получить общее руководство о том, как улучшить управление файлами и их развертывание. В идеале мы хотим, чтобы управление файлами было более тесно связано с нашим репозиторием, чтобы откат / откат был бы более связан с svn. Что-то вроде использования команды экспорта, чтобы убедиться, что файлы сайта совпадают с файлами репо. Было бы также хорошо, если бы решение, возможно, также остановило бы репликацию файлов вокруг наших серверов.

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

обобщить ...

• Каков наилучший способ синхронизации файлов на нескольких серверах с SVN?
• Как мы должны предотвратить репликацию файлов? символические ссылки / что-то еще?
• Как мы должны структурировать репо, чтобы мы могли разрабатывать новые функции и исправлять старые?
• Как мы должны запускать откат / откат?

заранее спасибо

РЕДАКТИРОВАТЬ:

Недавно я прочитал много хорошего об использовании Phing и Capistrano для подобных задач. Кто-нибудь может дать больше информации о них и насколько они хороши для такого рода задач?

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

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

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

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

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

Я предполагаю, что, как вы упомянули LAMP, вы используете PHP или другой язык сценариев, который не требует процесса компиляции. Это означает, что вы, вероятно, упускаете замечательный процесс, называемый непрерывной интеграцией. В основном это означает, что ваш код постоянно тестируется, чтобы убедиться, что он все еще находится в состоянии высвобождения. Каждый раз, когда кто-то проверяет новый код, процесс берет его и запускает процесс сборки и тестирования. В случае скомпилированного языка вы обычно используете это, чтобы убедиться, что код все еще скомпилирован. На каждом языке вы должны использовать возможность запуска модульных тестов (ваш код написан в тестируемых единицах, не так ли?) И интеграционных тестов. Для веб-сайтов хорошим инструментом для тестирования интеграционных тестов является Selenium. В наших сборках Java мы также измеряем охват кода и показатели кода, чтобы увидеть, как мы продвигаемся со временем. Лучший CI-сервер, который мы нашли для Java, это Hudson, но что-то вроде buildbot может лучше работать для других языков. Вы можете создавать пакеты, используя свой CI сервер.

Мы начали использовать Puppet (флагманский продукт Reductive Labs). Это основанная на Ruby среда для автоматизации заданий sys-admin. Я был в puppetcamp пару недель назад и вот ссылки на видео:

Представление Люка Кейнса - Puppet Intro

Кроме того, если вы хотите увидеть все презентации, сделанные на puppetcamp в Сан-Франциско, вот ссылка:

Презентации о том, как другие использовали Puppet

Наслаждаться.