Веб-разработка с контролем версий

Question

Коротко:
Я работаю в команде из 2 человек (мы можем расширяться в будущем).
У нас есть веб-сервер и рабочий сервер.
В настоящее время, когда мы начинаем разработку, мы запускаем их на локальном хосте, затем разворачиваем их в web-dev (к которому у нас есть доступ через подключенный диск) и отправляем изменения с этого «общего» диска в SVN. Финальный тест на web-dev, одобрение сверху и обратно проходит через FTP на наш рабочий сервер.
(Я слышу, как приближается Линч ...)
Да, я знаю, что все неправильно, когда вы обмениваетесь файлами из одного места и отправляете их оттуда, но тогда я познакомился с SVN не так уж и плохо. И теперь я хочу изменить это.

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

Могут ли некоторые из вас опытные люди подсказать, как это на самом деле должно работать?

Вещи, которые я узнал:

• мы должны работать над локальными копиями на наших машинах
• затем мы отправляем изменения в SVN.

Вещи, которые я хочу знать:

• как сделать обновление web-dev после фиксации SVN?
• как установить патчи на рабочий сервер? фтп файлы? это то, что ты делаешь? или какие-то другие умные решения?
• все, что я должен знать о рабочем процессе web-dev.

Answer 1

Subversion имеет хуков пост-фиксации , которые позволяют выполнять действия с коммитом.

Вы также можете взглянуть на решение для непрерывной интеграции, такое как CruiseControl.net или Team City.

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

Существует запланированная сборка для установщика обновлений, которая запускается еженедельно и обновляет установку на сервере, который QA использует для проверки исправлений. После проверки исправлений кто-то (вручную) применяет обновление, примененное к серверу QA на рабочих сайтах.

Answer 2

Вот как я это делал уже несколько лет.

Dev Server - Расположен в доме, содержит стек LAMP, репозиторий и рабочую копию. Он имеет те же версии программного обеспечения, что и рабочий сервер.

Производственный сервер - имеет промежуточную среду с рабочей копией репозитория, а также имеет производственную среду с версией проекта, отличной от svn (т. Е. Живой сайт).

Разработчик - имеет стек LAMP и рабочую копию хранилища на своей локальной машине.

Типичный процесс:

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

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

Если изменения работают на Dev Server, то рабочая копия в промежуточной среде обновляется вручную.

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

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

Answer 3

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

• как сделать обновление web-dev после фиксации SVN?
• как установить исправления на рабочий сервер?

Либо автоматически, через крючок, либо вы можете рассмотреть ручное «svn update» на производственных машинах, которое дает вам контроль, когда, какую ревизию и т. Д. Использовать.

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

Answer 4

То, как мы это делаем, довольно просто, и, будучи небольшой командой, вы сможете общаться.

• Разработка выполняется на локальном хосте и передается на ветку ствола.
• Для QA ветвь объединяется с транком, а среда разработки (которая является копией транка) просто делает svn up
• Если в QA все хорошо, я делаю svn up в живом окружении (которое также является копией транка) и все готово.

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

Answer 5

Модель, которую я успешно использовал, выглядит следующим образом

• Вместо Subversion, используйте распределенную систему контроля версий, такую ​​как Mercurial или Git
• У всех разработчиков есть локальный репозиторий, который они фиксируют локально во время развертывания
• Существует дополнительный репозиторий тестов, в который все разработчики вносят свои изменения после того, как все сделано. Это проверено QA и проверено
• Если с проверенным репозиторием все в порядке, он помечается и затем отправляется в рабочий репозиторий