Поскольку наши веб-приложения росли, и все больше и больше разработчиков начали работать над ними, стало очевидно, что нам нужна какая-то система контроля версий для управления нашим кодом. Поскольку CVS довольно устарел, а Subversion (SVN) представила некоторые удобные функции (атомарные транзакции, Apache piggybacking, более удобное ветвление / тегирование, множество других улучшений), мы решили использовать SVN. Большой вопрос был: как правильно его использовать? После выдвижения некоторых более или менее странных идей, я думаю, мы наконец нашли достойное решение для перевода веб-приложения в систему контроля версий. Имейте в виду, что этот пост не о том, как использовать сам SVN, а о архитектуре системы для его использования в веб-разработке. Если вам нужна помощь с Subversion, вы можете найти ее в руководстве и FAQ .
Управлять веб-приложениями в SVN сложно по ряду причин:
- При использовании контроля версий программист всегда работает над «рабочей копией» проекта. В традиционной разработке программного обеспечения эта копия находится где-то на его машине, так как это отдельное приложение. В веб-разработке, однако, мы говорим о веб-пространстве. Должен ли каждый разработчик иметь на своем компьютере среду PHP? Разве не все программисты должны работать на одной и той же конфигурации сервера? А как насчет пользователей Windows и Mac?
- Это означает, что рабочие копии должны быть лучшими на одном веб-сервере вместе с клиентом SVN. Таким образом, нам нужен некоторый интерфейс (самый простой из которых — SSH) для доступа к нему. Может быть, богатый веб-клиент будет еще лучше.
- Большинство веб-приложений используют базу данных. Разные версии программного обеспечения нуждаются в разных версиях базы данных. Хуже того, их работоспособность может зависеть от данных в базе данных. Версия приложения без соответствующей структуры базы данных не годится.
- Приложение должно быть развернуто в реальном веб-пространстве. Это может происходить довольно часто и должно быть максимально безболезненным.
Вот что нам нужно, чтобы это заработало:
- Общедоступный веб-сервер с живым веб-пространством
- Тестовый веб-сервер с хотя бы одним веб-пространством (рабочей копией) для каждого разработчика
- Сервер MySQL с двумя базами данных
- Сервер SVN
- Некоторая дисциплина
WebServers
Каждый разработчик теперь может работать над проектом в своем собственном рабочем каталоге (веб-пространстве). Все они совместно используют одну базу данных разработки, так как код не должен зависеть от данных в базе данных. Всякий раз, когда программист завершает свою задачу, он вносит свои изменения в хранилище.
Когда следующая версия вашего приложения будет готова, она может быть развернута на работающем сервере, который также является рабочей копией. Таким образом, обновления могут выпускаться очень быстро и эффективно без необходимости экспорта всего хранилища. Все, что нам нужно, это небольшой скрипт или webmin для запуска развертывания. Из соображений безопасности нет другого способа получить доступ к файлам в реальном веб-пространстве. Все, что нужно сделать, — это предотвратить спуск Apache в папки .svn. Небольшая директива в нашем httpd.conf может помочь нам здесь.
# Disallow browsing of Subversion working copy administrative dirs.
<directorymatch "^/.*/.svn/">
Order deny,allow
Deny from all
</directorymatch>Базы данных
Для каждой версии существует соответствующая структура базы данных. Как мы собираемся справиться с этим? Прежде всего, кажется разумным поддерживать обратную совместимость, поскольку важно, чтобы вы могли вернуться к предыдущей версии, не нарушая приложения. Это означает: нигде ничего не удаляйте, просто расширяйте существующие структуры.
В каждом выпуске программного обеспечения все изменения в структуре базы данных необходимо вносить на действующий сервер базы данных. При первой же мысли это должно быть сделано автоматически. Проблема в том, как? Мы не просто хотим «реплицировать» все различия сервера разработки на работающий сервер, потому что там, безусловно, есть тестовые таблицы или другие недоделанные вещи. Что делает необходимым тщательно выбирать, и это больно.
Вот почему вы должны вести журнал изменений, где вы можете добавить все изменения в базу данных, которые предназначены для использования в реальном времени. Это требует некоторой дисциплины, но имеет то преимущество, что у вас всегда есть готовый файл SQL для создания базы данных. Если правильно прокомментировать, вы также можете использовать его как список изменений.
Что если по какой-то странной причине ваш код зависит от данных в базе данных? Скажем, в базе данных хранится какая-то карта сайта. Это больно, потому что вы должны обновить эту таблицу вручную. Перед каждым коммитом, когда в него вносятся изменения, вам нужно выгрузить его в файл SQL, чтобы поставить его под контроль версий. Таким образом, ваши данные также становятся объединяемыми. Когда есть много мест для этого, вы должны рассмотреть сценарии для замораживания (записи данных базы данных в файлы) и размораживания (наоборот) вашего веб-приложения.
Что положить в …
Конечно, ваш код относится к управлению версиями. То же самое делают схемы базы данных, шаблоны и графика. То, что вы не должны вставлять, это:
- Пользовательские данные — загруженные пользователем файлы и прочее не принадлежат.
- Данные базы данных — не путайте контроль версий с резервной копией!
- Кэшированные данные — это временные данные.
- Файлы конфигурации — они должны быть созданы вручную.
Даже не думайте о переводе файлов конфигурации в систему контроля версий. Прежде всего, они имеют тенденцию перезаписываться и, например, изменять базу данных вашего живого сервера. Во-вторых, пароли не входят в контроль версий! Вместо этого вы должны добавить файлы конфигурации по умолчанию с измененными именами файлов, например, database.conf.default .
Ветвление и пометка
Важно помнить, что в транке находится только рабочий код. В конце концов, он должен быть готов к развертыванию все время. Из-за этого вам нужно создавать новую ветку всякий раз, когда:
- Вы работаете над большим проектом, который требует собственных версий.
- Это проект, который занимает довольно много времени. Ваш код безопаснее в хранилище, чем на ноутбуке разработчика.
- Когда над проектом работает более одного человека. В своей собственной ветке разработчики могут делиться своим кодом, не повреждая ствол.
Эти ветви сливаются обратно в ствол после завершения. Что касается тегов, единственное, что я могу сказать, это то, что разумно создавать теги всякий раз, когда вы обновляете свой живой веб-сервер, чтобы отслеживать ваши выпуски.
Безопасность
Приятным побочным эффектом всего этого подхода является то, что разработчику больше не требуется доступ к работающему серверу. Если все сделано правильно, обновления сервера в реальном времени запускаются через веб-интерфейс, и это все, что вам нужно для административного доступа на этом компьютере. И это хорошо. И не забудьте использовать SSL для безопасности ваших транзакций SVN!