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