Как эффективно управлять несколькими установками веб-приложения?

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

У моей компании есть собственная CMS, которая в настоящее время установлена на 100 серверах. На данный момент мы используем hack-ish FTP-based подход, в сочетании с сценариями обновления в определенных местах, чтобы обновить все наши установки CMS. Эффективное управление этими установками становится все более сложным и рискованным, когда задействовано несколько пользовательских модулей.

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

Некоторая контекстуальная информация: мы в основном разрабатываем в стеке LAMP. Одним из основных факторов, которые помогают нам продавать нашу CMS, является то, что мы можем плагировать практически во всем, что хочет наш клиент. Это может быть от 10 до 10 000 строк пользовательского кода.

Много пользовательской работы состоит из очень маленьких фрагментов кода; Управление всеми этими небольшими фрагментами кода в Subversion кажется довольно утомительным и неэффективным для меня (поскольку мы доставляем около 2 веб-сайтов каждую неделю, это приведет к множеству веток).

Если есть что-то, что я пропускаю, я бы хотел услышать это от вас.

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

Roundup: в первую очередь, спасибо за все ваши ответы. Все это действительно полезно.

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Удачи!

EDIT: пример хорошо разработанного приложения, использующего все принципы, описанные выше, см. Magento E-Commerce. Magento - это самое мощное, расширяемое и легко настраиваемое веб-приложение, с которым я работал до сих пор.

Ответ 3

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

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

например. скажем, вы создали новую версию 3 вашего модуля "Wiki". Вы хотите распространять новую версию на все серверы, на которых запущено ваше приложение, но вы вносили изменения в один из интерфейсов в модуле Wiki с версии 2. Теперь для всех установок по умолчанию это не проблема, но это сломается установки с пользовательскими расширениями поверх старого интерфейса. Хорошо спланированная система пакетов позаботится об этом.

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

Ответ 4

Не уверен, сказал ли кто-нибудь об этом, здесь много долгих ответов, и я их не читал.

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

Затем вы можете использовать свою магистраль (или конкретную ветку/тег, если хотите) в качестве svn: external в каждом проекте, который этого требует. Таким образом, любые обновления, которые вы делаете в CMS, можно перенести обратно в свой репозиторий и будут перенесены в другие проекты по мере обновления svn (или внешний svn: switch ed).

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

IE:

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(при необходимости вы могли бы иметь cms и lib в папке www)

Это позволит вам разделить/пометить каждый проект по своему усмотрению. Вы также можете переключить svn: внешнее местоположение на основе каждой ветки/метки.

С точки зрения получения изменений в реальном времени, я предлагаю вам немедленно избавиться от ftp и использовать rsync или svn checkout/exports. Оба работают хорошо, выбор зависит от вас.

У меня есть большой опыт использования маршрута rsync, rsyncing экспорт svn на сервер. Если вы спуститесь по этому маршруту, напишите некоторые сценарии оболочки, и вы можете создать тестовую оболочку script, чтобы показать вам файлы, которые она будет загружать, не загружая их, используя флаг -n. Обычно я использую пару скриптов для каждой среды - один тест, а другой - для этого.

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

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

Ответ 5

Вы посмотрели на Drupal? Нет, не развертывать и не заменять то, что у вас есть, но посмотреть, как они обрабатывают настройки и модули для сайта?

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

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

Ответ 6

Создайте в коде процесс самообновления.
Он проверяет наличие обновлений и запускает их когда/где/как вы его настроили для клиента.

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

Обновления в идеале - это несколько ключевых шагов.

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

b) Процесс мониторинга обновлений. Имейте телефон системы CMS домой, чтобы искать новую сборку.

c) Обновление расписания при доступности. Скорее всего, вы не хотите, чтобы обновление запускало второе, что доступно. Это означает, что вам придется создать cron/agent какого-либо типа, чтобы автоматически обновлять систему посреди ночи. Вы также можете учитывать требования клиентов к обновлению в выходные или в определенные дни. Вы также можете разворачивать свои обновления, чтобы вы не обновляли 1000 клиентов за 1 день и не получили поддержку в технической поддержке. Возможно, вам может быть выгодно пошатнутое развертывание.

d) Добавить режим обслуживания для обновления сайта. Наведите сайт в режим обслуживания.

e) Проверка SVN или загружаемые пакеты. В идеале вы можете развернуть через svn checkout, а если нет, настройте сервер для доставки svn-сгенерированных пакетов в архив, который можно развернуть на клиентских сайтах.

f) Развертывание сценариев СУБД. - Резервное копирование баз данных, их обновление, заполнение.

g) Обновить код сайта. Все это работает на один шаг.

h) Запустите на нем несколько тестов. Если ваш код имеет встроенные самотестирования, он был бы идеальным.

Ответ 7

Вот что я делаю...

Клиентский путь включает путь

Общий общий код находится в shared/current_version/lib/
Код для конкретного сайта находится в clients/foo.com/lib
Включаемый путь устанавливается из clients/foo.com/lib, а затем share/lib
Все в системе контроля версий

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

Общие файлы псевдонимов

Моя конфигурация виртуального хоста будет содержать строку типа

Alias /common <path>/shared/current_version/public_html/common

Позволяет совместно использовать общие элементы пользовательского интерфейса, значки и т.д.

Отметьте общий код с каждым выпуском сайта

После каждого выпуска сайта я отмечаю общий код, создавая ветвь, чтобы эффективно заморозить этот момент времени. Это позволяет мне развернуть/shared/version_xyz/на живой сервер. Затем я могу заставить виртуальный хост использовать определенную версию общих файлов или оставить его указателем на current_version, если я хочу, чтобы он собирал последние обновления.

Ответ 8

Просмотрели ли вы такие инструменты, как Puppet (для системного администрирования, включая развертывание приложения) или Capistrano (развертывание приложений в RubyOnRails, но не ограничиваясь ими)?

Ответ 9

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

Ответ 10

Как уже упоминалось, использование управления версиями (я предпочитаю Subversion из-за функциональности), и разветвление было бы лучшим вариантом. Другое программное обеспечение с открытым исходным кодом, доступное на sourceforge, называется cruisecontrol. Удивительно, вы настраиваете cruisecontrol с subversion в sach таким образом, что любая модификация кода или новый код, добавленный в serversion, Cruise Control будет знать автоматически и будет строить для вас. Это спасет ваше время.

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

Ответ 11

Если вы используете стек LAMP, я бы определенно превратил файлы решений в пакет вашего дистрибутива и использовал его для распространения изменений. Я рекомендую в этом отношении Redhat/Fedora из-за RPM и это то, что у меня есть. В любом случае вы можете использовать любой дистрибутив на основе Debian.

Когда-то я создал LAMP-решение для управления серверами хостинга ISP. У них было несколько серверов для обслуживания веб-хостинга, и мне нужен был способ развернуть изменения моего менеджера, потому что каждая машина была автономной и имела онлайн-менеджера. Я создал пакет RPM, содержащий файлы решений (в основном, php) и некоторые сценарии развертывания, которые запускались с RPM.

Для автоматического обновления у нас был собственный репозиторий RPM на каждом сервере в yum.conf. Я установил задание crontab для ежедневного обновления серверов с помощью последних RPM из этого доверенного репозитория.

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

Ответ 12

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

С другой стороны, наличие ветвей для каждого клиента выглядит как экспоненциальный рост для меня. И как бы вы "знаете", какие области вы что-то сделали, и не забывайте "делать" изменения во всех других отраслях. Это выглядит довольно уродливо для меня.

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

Ответ 13

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

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

Посмотрите на Git для управления версиями, он создан для ветвления и быстро.

Зайдите в Capistrano для управления развертываниями. Это рубин script, часто используемый с Rails, но он может использоваться для управления всеми видами файловых серверов на удаленных серверах, даже без рубиновых сайтов. Он может получить контент на удаленном конце с помощью различных stragegies, включая ftp, scp, rsync, а также автоматически проверять последнюю версию из вашего репозитория. Среди замечательных функций, которые он предоставляет, входят обратные вызовы для каждого шага процесса развертывания (например, чтобы вы могли скопировать файлы конфигурации вашего сайта, которые могут отсутствовать в управлении версиями), а система журналов выпуска - через символические ссылки - так что вы может быстро вернуться к предыдущему выпуску в случае возникновения проблем.

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