У нас есть приложение для электронной коммерции, которое мы разрабатываем в нашей компании. Это достаточно стандартное приложение LAMP, которое мы постоянно разрабатываем около 3 лет. Мы разрабатываем приложение в тестовой области, здесь мы добавляем новые функции и исправляем ошибки и т. Д. Нашим отслеживанием ошибок и разработкой функций управляет размещенное на сервере решение для подрывной деятельности (Unfuddle.com). По мере появления сообщений об ошибках мы вносим эти исправления в тестовый домен, а затем фиксируем изменения в svn, когда будем счастливы, что ошибка исправлена. Мы следуем той же процедуре с добавлением новых функций.
Здесь стоит указать на общую архитектуру нашей системы и приложения на наших серверах. Каждый раз, когда разрабатывается новая функция, мы выкатываем это обновление на все сайты, использующие наше приложение (всегда контролируемый нами сервер). Каждый сайт, использующий нашу систему, по сути, использует одни и те же файлы для 95% кодовой базы. У нас есть несколько папок на каждом сайте, которые содержат файлы, специально предназначенные для этого сайта - файлы css / изображения и т. Д. Кроме того, различия между каждым сайтом определяются различными настройками конфигурации в каждой базе данных сайтов.
Это переходит к самому развертыванию. Когда мы будем готовы развернуть какое-либо обновление, мы запускаем команду на сервере, на котором находится тестовая площадка. Это выполняет команду копирования (cp -fru / testsite / / othersite /) и проходит через каждый vhost принудительно обновляет файлы на основе даты изменения. Каждый дополнительный сервер, который мы размещаем, имеет виртуальный хост, с которым мы синхронизируем производственную кодовую базу, а затем повторяем процедуру копирования на всех сайтах на этом сервере. Во время этого процесса мы удаляем файлы, которые не хотим перезаписывать, и перемещаем их обратно после завершения копирования. Наш сценарий развертывания выполняет ряд других функций, таких как применение команд SQL для изменения каждой базы данных, добавление полей / новых таблиц и т. Д.
Мы все больше обеспокоены тем, что наш процесс недостаточно стабилен, отказоустойчив, а также является чем-то вроде метода грубой силы. Мы также осознаем, что не используем Subversion наилучшим образом, поскольку у нас есть положение, в котором работа над новой функцией не позволит нам развернуть важное исправление ошибки, поскольку мы не используем ветки или теги. Также кажется неправильным, что у нас так много репликаций файлов на наших серверах. Мы также не можем легко выполнить откат того, что мы только что развернули. Мы действительно выполняем сравнение перед каждым развертыванием, чтобы мы могли получить список файлов, которые будут изменены, чтобы мы знали, что было изменено после, но процесс отката по-прежнему будет проблематичным. Что касается базы данных, я начал рассматривать dbdeploy как потенциальное решение. Что нам действительно нужно, так это несколько общих рекомендаций о том, как мы можем улучшить управление файлами и их развертывание. В идеале мы хотим, чтобы управление файлами было более тесно связано с нашим репозиторием, чтобы развертывание / откат было больше связано с svn. Что-то вроде использования команды экспорта, чтобы убедиться, что файлы сайта совпадают с файлами репо. Было бы также хорошо, если бы решение, возможно, также остановило бы репликацию файлов на наших серверах.
Игнорируя наши текущие методы, было бы действительно хорошо услышать, как другие люди подходят к той же проблеме.
чтобы обобщить ...
заранее спасибо
РЕДАКТИРОВАТЬ:
В последнее время я прочитал много хорошего об использовании Phing и Capistrano для такого рода задач. Может ли кто-нибудь предоставить дополнительную информацию о них и о том, насколько они хороши для такого рода задач?
Мой совет при выпуске релизов - иметь релизы функций и сервисные релизы. Выпуски функций - это выпуски, которые получают новые функции. Они добавляются в ваш сундук Subversion. Когда вы считаете, что эта функция завершена, вы переходите в ветку выпуска. Как только ваш процесс контроля качества будет доволен этим выпуском, вы помечаете выпуск и развертываете код на своих серверах.
Теперь, когда вы получаете отчет об ошибке, вы фиксируете это исправление в ветке и портировать его в транк. Когда вас устраивает количество исправленных ошибок, вы можете пометить и развернуть Maintenance Release.
Важно, чтобы у вас была ветвь вашей базы живого кода (или была возможность создать ее, зная живую ревизию), которая была отделена от вашей ветки разработки, чтобы у вас была возможность развертывать исправления для вашего живого кода без необходимости развертывать новые функции или непроверенный код.
Я бы рекомендовал использовать собственную систему упаковки вашего дистрибутива для развертывания нового кода. Если у вас есть пакет, содержащий всю вашу базу кода, вы знаете, что весь ваш код был развернут в виде атомарной операции, вы можете сразу увидеть, какая версия установлена, можете проверить свою базу кода, используя контрольную сумму пакетов. Откат - это всего лишь случай установки ранее установленной версии пакета.
Единственное препятствие, которое я вижу для вас, реализуя это, заключается в том, что у вас есть несколько копий базы кода для разных клиентов, работающих на одном сервере. Я бы попытался организовать ваш код так, чтобы все клиенты запускали одни и те же файлы и не использовали копии. Я не знаю, насколько легко это будет для вас, но уменьшение количества копий, с которыми вам придется иметь дело, значительно уменьшит вашу головную боль.
Я предполагаю, что, как вы упомянули LAMP, вы используете PHP или другой язык сценариев, который не требует процесса компиляции. Это означает, что вы, вероятно, упускаете замечательный процесс, называемый непрерывной интеграцией. В основном это означает, что ваш код постоянно тестируется, чтобы убедиться, что он все еще находится в готовом к выпуску состоянии. Каждый раз, когда кто-то регистрирует новый код, процесс берет его и запускает процесс сборки и тестирования. С скомпилированным языком вы обычно используете это, чтобы убедиться, что код все еще скомпилирован. Для каждого языка вы должны использовать возможность запускать модульные тесты (ваш код находится в тестируемых модулях, не так ли?) И интеграционные тесты. Для веб-сайтов хорошим инструментом для тестирования интеграционных тестов является Selenium. В наших сборках Java мы также измеряем покрытие кода и метрики кода, чтобы увидеть, как мы прогрессируем с течением времени. Лучший CI-сервер, который мы нашли для Java, - это Hudson, но что-то вроде buildbot может лучше работать для других языков. Вы можете создавать пакеты, используя свой CI-сервер.
Мы начали использовать Puppet (флагманский продукт компании Reductive Labs). Это платформа на основе Ruby для автоматизации заданий системного администратора. Я был в кукольном лагере пару недель назад, и вот ссылки на видео:
Люк Канис представляет - кукольное вступление
Кроме того, если вы хотите увидеть все презентации, сделанные в марионеточном лагере в Сан-Франциско, это ссылка:
Презентации о том, как другие использовали Puppet
Наслаждаться.