Контроль версий для SAAS Workflow

Question

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

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

В основном У меня есть приложение SAAS, которое постоянно растет. В настоящее время над приложением работает только один разработчик (я), но если интерес к нему сохранится, мне, возможно, придется начать нанимать.

Приложение написано на PHP, использует базу данных MySQL и размещено в стандартном стеке LAMP.

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

Моя главная задача - развертывание на нашем производственном сервере. Каждый из наших клиентов имеет свои собственные папки приложений и свои собственные базы данных.

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

1.Duplicates clients installation into a backup folder
2.Removes the live installation folder
3.Copies the new updated installation folder
4.Copies the users config files from the backup to the live install
5.Tells the operator to make the changes to the users database using a third party app
6.Cleans up.

Было скучно с 5 пользователями, но сейчас мы приближаемся к 50, и это абсолютный кошмар.

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

Я пытался настроить gitorious server , но подумал, что я бы попросил совета о том, как действовать, прежде чем копать себя глубже.

Спасибо

Answer 1

Может быть, вы могли бы хранить файлы вашего приложения в отдельном каталоге вне домашних каталогов пользователей и создавать символическую ссылку в каждом пользовательском каталоге, которая будет указывать на ваше приложение? Пример:

ln -s /var/myapp/publicfiles /home/someuser/lib

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

Answer 2

Для исходного кода

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

Т.е. есть каталог - на сервере - содержащий главный репозиторий ( bare git-репозиторий).Вы нажмите , чтобы перейти в этот главный репозиторий, а затем выполните операцию rebase для каждого клиента.

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

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

Для базы данных

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

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

Answer 3

Я думаю, что ваша проблема здесь в количестве развертываний, которые у вас есть.Это то, что вызывает самый большой кошмар.Тем не менее, это все еще управляемо в этой форме.По сути, вы хотите сделать следующее:

1. Сделать клон вашего репозитория git для каждого развертывания
2. Произведите любые пользовательские изменения для каждого развертывания
3. Для каждого программного обеспеченияПри обновлении вы будете проходить каждое развертывание и объединять изменения из основного (основного) репозитория.

Это должно объединить изменения без каких-либо проблем в приложении.Единственное изменение - это написание сценария, который может выполнять обновление / миграцию базы данных после развертывания нового кода.