Как правильно использовать SVN при разработке веб-приложения

Question

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

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

Пользователи явно не могут работать с одной и той же рабочей копией (в этом смысл svn), и вы не можете извлекать разные рабочие копии в корне документа по путям, так как лучше всего работать с svn и веб-приложением развитие? Должен ли каждый пользователь иметь интерпретатор веб-сервера / php на клиентском компьютере?

Answer 1

У каждого разработчика есть рабочая станция с IDE, локальный веб-сервер и клиентские инструменты SVN. Веб-приложение проверяется на каждой рабочей станции, чтобы разработчики могли зафиксировать изменения в репозитории.

Answer 2

Одним словом, да.

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

Затем, когда вы хотите сделать релиз, вы экспортируете из SVN на свой рабочий сервер (или тестируете сервер для проверки качества).

Answer 3

В работе с веб-разработкой нет ничего особенного, в отличие от любого другого типа источника (например, толстого клиента). Они все одинаковые:

• Разработчики проверяют версию системы.
• Они вносят изменения в то, что проверено.
• При необходимости (*) они проверяют изменения обратно в хранилище.
• Вещи проверены (до некоторой степени)
• Изменения приняты.
• Система извлечена (где-то еще) и используется для обновления производства.

Все разрабатываемое программное обеспечение должно иметь как минимум три разных экземпляра:

• разработка (для каждого разработчика)
• тест (для каждой группы тестирования)
• производство

Если вы вносите изменения «разработки» непосредственно в рабочую копию, это обычно считается безрассудным. Это может показаться быстрым, но вы не учитываете «риск» правильно (и это укусит вас однажды). Если вы просто делите веб-сервер между разработчиками серверов в процессе разработки, вы по-прежнему просите неприятностей.

Каждый экземпляр разработки должен иметь свою собственную «законченную» среду для работы. То есть каждый разработчик должен иметь свой собственный веб-сервер, свой собственный источник, свои собственные конфигурации и т. Д. Используйте репозиторий, чтобы собрать все это вместе, это часть своей работы. Структура разработки должна соответствовать тестовой и производственной структурам "как можно ближе". Это сокращает количество ошибок во время установки.

Answer 4

Я всегда делал это там, где у каждого пользователя есть собственный веб-сервер / php-интерпретатор, хотя все, что вам нужно, это ваш собственный apachectl, который передает определенный пользователем httpd.conf. Тогда каждому пользователю нужен свой собственный httpd.conf. Поэтому все, что вам нужно для репликации, это httpd.conf и apachectl, каждый может использовать одну и ту же установку apache.

Answer 5

В зависимости от размера и структуры команды, не будет ли мудрее в этом случае

• В этом случае работайте с той же рабочей копией через локальную сеть и применяйте файловую блокировку на уровне ОС

или

• Поддерживать «рабочий» репозиторий, в который все изменения вносятся очень часто, чтобы другие могли обновить свои рабочие копии, и «финальный» репозиторий, в который команда фиксирует свои действия в конце дня или по достижении некоторой предварительной определенная точка?

Веб-приложение со сценарием обычно не имеет процесса сборки. Представьте, что кто-то работает над файлом CSS, вносит изменения и проверяет их в браузере каждые несколько секунд. Представьте, что кто-то еще работает над связанным файлом HTML и делает то же самое.

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

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