Я использую управление исходным кодом, сценарии и процедуры развертывания для управления несколькими проектами веб-приложений, такими как WordPress, PHPBB и пользовательские веб-приложения.За прошедшие годы я усовершенствовал их, и теперь у меня есть хорошая структура, которая, кажется, хорошо работает для меня, поэтому она может подойти другим, сталкивающимся с похожими вызовами.
Вот некоторые общие моменты об общей стратегии:
- У меня никогда не было SCM и исходных файлов на рабочем сервере.Я не вижу смысла помещать его туда, и обычно я не хочу, чтобы хранилища были открыты в случае взлома сервера.Приложения на рабочем сервере имеют только clean последней стабильной версии .Никаких файлов проекта, документов, модульного тестирования и т. Д. Ничего ненужного там нет.Я считаю это очень важным как с точки зрения безопасности, так и с точки зрения стабильности приложений.
- Не для того, чтобы превратить это в дискуссию по SCM, но я обнаружил, что для моих целей mercurial (и git) лучше, чем SVN в любом аспекте.Вам не нужен «сервер», а хранилища проще в обслуживании.
- Я держу отдельный репозиторий для каждого проекта.Ртутные репозитории дешевы и легки.Хранение каждого проекта в собственном хранилище дает большую гибкость.Так что нет ни одного большого репозитория для "public_html".
- Я работаю с локальными ртутными репозиториями на компьютере разработчика.Все резервируется как есть (используя любую стратегию резервного копирования - дополнительные машины, внешние диски, облачное резервное копирование).Совместное использование кода так же просто, как просто дать каталог проекта.Иногда я держу репозитории на dropbox , поэтому я могу получить к ним доступ из любого места.
- Развертывание выполняется автоматически с помощью сценария (ов) развертывания (более подробно позже).Который экспортирует нужную ревизию, редактирует ее и загружает на сервер.
- Дампы баз данных не сохраняются в SCM.Это не практично для любого реального проекта.Я храню дамп базы данных структура в SCM и обновляю его каждый раз, когда меняется структура (для этого я использую дамп mysql или phpmyadmin).Иногда имеет смысл сохранить дамп данных скелета в SCM вместе со структурой (таблицы со значениями по умолчанию, значениями поиска и т. Д.).
- Резервное копирование базы данных выполняется автоматическим сценарием ( automysqlbackup )хорошо работает), который работает на производственном сервере.Сбрасывает базу данных, архивирует ее и вращает файлы (ежемесячно, еженедельно, ежедневно).Существует также сценарий, который ежедневно загружает файлы резервных копий в удаленное хранилище.Это хорошо работает для проектов с относительно маленькими и средними размерами данных.Очевидно, что это необходимо изменить для больших баз данных.
- Я обычно держу отдельные экземпляры базы данных для разработки и производства.Возиться с производственной базой данных как можно меньше.Когда мне нужно что-то протестировать / отладить, я обновляю свою базу данных разработки копией живых данных.
- Иногда у меня на рабочем сервере есть вторая копия моего приложения для промежуточного / модульного тестирования, но это слишком многоописать здесь.
- Все развертывание туннелируется по SSH, который является единственным разрешенным соединением на сервере (кроме, конечно, http / s).Я храню файл ключа SSH на компьютере разработчика.В качестве альтернативы вы можете использовать VPN в качестве туннеля.
- Я предполагаю, что производственные серверы Linux / BSD.Все это будет совершенно иначе (и, как правило, сложнее) на сервере Windows.Я использовал эти процедуры на машинах для разработки под Windows, Mac и Linux, все инструменты доступны на всех.
Итак, чтобы ответить на некоторые ваши вопросы, я бы сделал это наоборот.Начните с рабочей среды на компьютере разработчика (в комплекте с веб-сервером и базой данных).Ваши приложения работают и тестируются там.Внесите изменения в локальный репозиторий по мере необходимости.Когда приложение будет готово к развертыванию, запустите сценарий развертывания, чтобы автоматически обновить рабочий сайт.
Мой сценарий развертывания выполняется примерно так:
- Экспорт желаемой ревизии в локальный каталог временного развертывания (mercurial, git, SVN имеют команды экспорта, которые создают рабочий каталог из вашего хранилища)
- Измените развернутый каталог, чтобы сделать его пригодным для оперативного развертывания.Это включает в себя изменение файлов конфигурации, изменение имен базы данных, путей, параметров журнала, уровней отладки и т. Д. Использование сценариев, sed, awk, grep или любых других инструментов командной строки.
- При необходимости создайте version.txt (или любой другойимя) файл из данных ревизии SCM, даты развертывания и т. д. Он будет загружен на сервер.
- Добавьте мой ключ SSH к агенту SSH (чтобы избежать использования паролей каждый раз).
- Используйте rsync, туннелированный через SSH, чтобы синхронизировать все с сервером.Сервер должен быть правильно настроен как пункт назначения rsync.Используйте rsync, чтобы исключить / включить фильтры, чтобы исключить все ненужное (часто это. * Кроме .htaccess).
- При необходимости используйте возможности удаленного выполнения SSH для запуска команд на сервере для выполнения таких задач, как установка специальных разрешений (например, разрешения на запись в каталогах загрузки Wordpress).
- Дайте мне приятный «успешное развертывание» сообщение :)
Вот и все, как только сценарий на месте, развертывание становится забавным.Запустите скрипт, перейдите на работающий сервер, чтобы увидеть, что все работает, готово.
Надеюсь, это поможет.