Настройка идеального рабочего процесса для веб-разработки с 2-3 людьми, использующими Subversion

Question

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

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

Я создал учетную запись на хостинге подрывной деятельности springloops (springloops.com). Каждый раз, когда я работаю над новым проектом, я создаю репозиторий для него. Допустим, в этом случае я работаю на сайте1. Я хочу иметь 3 версии сайта в интернете:

1. Веб-разработка - Это сервер я и другие разработчики публикуют к. (Site1.dev.bythepixel.com)
2. Предварительный просмотр клиента - Это сервер что мы обновляем каждые несколько дней с хороший пересмотр для клиента, чтобы увидеть. (Site1.bythepixel.com)
3. Живой сайт - Сайт, на котором я публикуюсь при запуске (site1.com)

Каждая машина веб-разработки (в каждом месте) будет иметь локальную копию виртуального хоста xamp, на котором можно работать с несколькими веб-сайтами. Корень локальной копии настроен так же, как и локальная копия хранилища Subversion. Это сделано для того, чтобы мы могли вносить небольшие изменения и сразу же просматривать их. Когда некоторая работа была проделана, в хранилище сайта делается коммит. Я сделаю так, чтобы сайт разработчика автоматически выдвигался (это вариант в Springloops). Затем, когда я почувствую себя готовым перейти на сайт клиента, я сделаю это. Завершающим этапом будет продвижение к живому сайту.

Теперь у меня есть несколько проблем с этим рабочим процессом:

1. В настоящее время я использую codeigniter, и в файле конфигурации я обычно устанавливаю корень сайта. Ex. http://www.site1.com. Итак, похоже, что каждый раз, когда я публикуюсь на одном из интернет-серверов, мне придется изменять файл конфигурации? Есть ли способ сделать так, чтобы определенные файлы были установлены для каждого сервера? Поэтому, когда я нажимаю «Опубликовать в предварительный просмотр клиента», он просто загружает файл конфигурации для сервера предварительного просмотра клиента.

2. Я не хочу, чтобы живой сайт, сайт предварительного просмотра клиента и сайт разработчика использовали один и тот же сервер mysql по ряду причин. Значит ли это еще раз, что мне приходится корректировать информацию о сервере БД каждый раз, когда я перехожу на другой сайт?

3. Имеет ли смысл этот рабочий процесс? Если у вас есть предложения, пожалуйста, дайте мне знать. Я планирую, чтобы это был рабочий процесс, который я использую в течение следующих нескольких лет. Мне просто нужно установить систему, которая позволит расширять ее в будущем!

Answer 1

Существуют лучшие решения по управлению версиями для распределенных систем управления версиями, чем subversion, я настоятельно рекомендую изучить одну из них:

1. https://www.mercurial -scm.org
2. https://git -scm.com /
3. http://bazaar.canonical.com/en/

см. здесь , здесь и здесь для некоторой ненаучной дискуссии

также, как сказал Витторе, я бы посчитал, что решение CI было бы весьма полезным, которое могло бы автоматизировать ваш переход из среды разработки в «производство», где клиент мог видеть его в ходе успешного цикла сборки / тестирования.

Answer 2

1) Посмотрите на концепцию непрерывной интеграции. (существует десяток бесплатных для CI серверов небольших проектов, например TeamCity)

2) Наличие 1. Подготовьте процедуру развертывания, которая сможет охватить любую из ваших трех сред

3) Убедитесь, что ВСЕГДА проверяете, что на развернутых сайтах нет файлов .svn, доступных пользователям, поскольку это действительно небезопасно

Также прочитайте кое-что о работе с тегами / ветками в SVN

Далее я бы предложил следующий рабочий процесс

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

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

Смысл иметь так много веток - это возможность хранить историю личных изменений и стабильные сборки одновременно.

Answer 3

Вы не хотите использовать корень вашего хранилища в качестве корня вашей рабочей копии. Это делает невозможным дальнейшее использование веток позже. (Или вы всегда должны проверять все филиалы локально ... делая дешевые копии Subversion, дорогие в рабочей копии)