Веб-разработка с рабочим процессом управления версиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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