Контроль версий PHP Web Project

Мы были в похожей ситуации, и вот что мы в итоге сделали:

• Настройте две ветви - ветка релиза и разработки.
• Для ветки разработки включите хук post-commit, который развертывает репозиторий на сервере dev, чтобы вы могли протестировать.
• Когда вы будете готовы, вы объедините свои изменения в ветке релиза. Я бы также предложил добавить хук post-commit для развертывания там.

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

Нам пришлось использовать один сервер разработки, потому что мы использовали проприетарную CMS и столкнулись с проблемами лицензирования. Таким образом, наш пост-коммит был простым FTP-ботом.

Каждый из вас может запустить его локально или на своем собственном сервере разработки (или даже на одном и том же с другим портом ...).

Один из возможных способов (возможно, есть и лучшие):

У каждого из вас должна быть своя проверенная версия проекта.

Имейте локальную копию сервера на своем компьютере и тестируйте ее там в течение дня. Затем в конце каждого дня (или когда-либо) вы объединяете все, что вы готовы протестировать, и вы проверяете это на сервере разработки и тестируете это.

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

Вы могли бы,

• Сделать репо

• Добавьте всю свою структуру документа PHP вашего проекта

• Оформите копию этого репо в правильном месте на вашем сервере разработки

• Используйте svn hook, который активируется при коммите

Этот хук автоматически обновляет содержимое сервера, когда кто-либо в команде проверяет какой-либо код.

Крюк находится в:

svn_dir / repo_name / Крючки / после совершения

И может выглядеть так:

/ usr / bin / svn up / path_to / webroot - имя пользователя svn_user --password svn_pass

Это обновит вашу рабочую копию на сервере разработчика до последней регистрации.

Вот что мы делаем:

• У каждого разработчика есть виртуальная машина, настроенная как наш сервер интеграции
• На сервере интеграции есть место для Магистрали, каждого пользователя и несколько слотов для филиалов.
• Производственный сервер
• Крюки в Subversion для электронной почты, когда совершаются коммиты

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

Как только они закончили все в своем личном пространстве, они входят на сервер интеграции и проверяют свою ветвь, запускают свои тесты и т. Д. Когда все, что проходит, их ветвь объединяется в Trunk.

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

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

В Beanstalk есть встроенные хуки для пост-фиксации для развертывания на серверах разработки, подготовки и производства.

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

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