Рабочий процесс веб-разработки SVN

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

Наша установка

• База кода PHP (в частности, Kohana)
• База кода поддерживает ~ 60 сайтов, каждый с уникальными шаблонами (например, 60 доменов QA [Quality Assurance])
• каждый сайт имеет A-записи для различных активов и ресурсов (например, 8 A-записей для каждого домена)
• 3 разработчика
• 3 дизайнера
• разработчики имеют образ рабочего сервера VMware для локальной разработки
• дизайнеры не
• совместно используют физическую разработку сервера, используемого для контроля качества, обновление после фиксации постоянно поддерживает этот сервер в текущем ГОЛОВЕ магистрали
• производственный сервер, обновляется для сочетания и соответствия различных ревизий в зависимости от того, какие функции активны

Наш рабочий процесс

• Разработчики работают локально, пока данная функция не будет завершена, а затем передают всю функцию в транк для внутреннего контроля качества.
• Дизайнеры вносят небольшие изменения только в CSS / изображения / шаблоны. Они фиксируют непосредственно в транке, контролируют свои собственные изменения и обновляют соответствующие файлы на производственном сервере, как правило, сразу после своего контроля качества.
• Когда функции готовы к запуску, производственный сервер вручную обновляется до правильных номеров редакций для каждого файла, связанного с функцией. Иногда это просто, иногда довольно сложно (много вызовов svn log для поиска зависимостей от восходящего потока).

Наши проблемы

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

Что я знаю

• Некоторые из наших проблем можно было бы облегчить, если бы у нас было производственное отделение. Мы могли, по крайней мере, отслеживать, какие функции и когда добавлялись в производственную среду, хотя это не решило бы проблем с зависимостями в восходящем направлении.
• Разветвления функций - это вариант, и мы пробовали это в прошлом. Из-за того, что для нашего программного обеспечения требуется 60 доменов QA на ветку, мы сталкиваемся с проблемами управления процессами там. Например, создание 480 (60 доменов x 8 записей на домен) A-записей для каждой функциональной ветви.
• Разветвления для разработчиков также возможны, но время проверки наших функций может быть разным. Я не могу однозначно сказать, что предыдущая функция выйдет из контроля качества, прежде чем мне нужно будет зафиксировать что-то еще.

Пример восходящей зависимости

• Разработчик A добавляет новую функцию слайд-шоу как в админке, так и во внешнем интерфейсе.
• Разработчик B добавляет новую функцию обратной связи как в админке, так и во внешнем интерфейсе.
• Обе эти функции связаны с логикой модели / контроллера местоположения, поэтому в эти связанные файлы вносятся изменения для учета обеих новых функций.
• Функция слайд-шоу входит в QA, но задерживается из-за некоторого надзора за разработкой или смещения масштабов.
• Функция обратной связи входит в QA и проходит без проблем.
• Мы хотим следовать графику и продвигать функцию обратной связи в производство, но мы не можем сделать это напрямую, потому что обе функции требовали изменений в модели / контроллере местоположения. То есть мы не можем просто выполнить svn update file1 file2 file3 .
• Примечание: Это простой пример, и его можно обойти, выполнив обратное слияние. Часто наши проблемы более сложные, чем эта.

Информация о структуре нескольких сайтов

• У нас есть ряд предварительно определенных структурных тем, состоящих из представлений, изображений, файлов CSS, файлов JS и т. Д.
• Каждому сайту назначается тема.
• По причинам брендинга и расширяемости каждый сайт может заменять представление темы настраиваемым представлением или включать дополнительные файлы CSS / JS для конкретного сайта.

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