Рабочий процесс веб-разработки SVN - PullRequest
23 голосов
/ 18 ноября 2010

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

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

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

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

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

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

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

Что я знаю

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

Пример зависимости от восходящего потока

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

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

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

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

Ответы [ 2 ]

1 голос
/ 18 ноября 2010

Ваш рабочий процесс может быть улучшен, вот список моих советов:

  • Начните использовать ветки SVN и регулярно выпускать сборки / развертывания.
  • Выясните, насколько длительным должен быть ваш цикл развертывания, оставляя время для QA. Так, например, если вы собираетесь выпускать сборку каждый месяц, у вас есть 3 недели разработки и 1 неделя QA. Заморозить разработку для этой сборки через 3 недели, за исключением исправлений ошибок.
  • Выберите схему нумерации для ваших сборок, которая позволит увеличить пространство
  • Использование системы тикетов (ActiveCollab, JIRA, Mantis и т. Д.) И применение правила о том, что любой тикет должен быть связан с тикетом. Выберите тот, где вы можете сделать ваши коммиты автоматически отображаться в билете.
  • Если вы собираетесь документировать свои требования до начала разработки, не собирайте ваши требования в системе продажи билетов (ради бога)
  • Это поможет вам определить, какие функции есть в данной сборке. Поэтому сделайте какие-нибудь заметки о выпуске со списком номеров билетов или общим описанием билетов для каждой сборки.
  • Вставьте ваши номера сборки в ваше приложение, чтобы вы могли отслеживать развертывания в любой конкретной системе.
  • Начните работать с инструментами автоматизированного тестирования PHPUnit для модульных тестов и Selenium для функциональных тестов, чтобы ускорить QA и повысить качество / стабильность веб-приложения за счет уменьшения вероятности того, что ежедневные изменения приводят к появлению новых ошибок.
  • Хадсон и Финг могут быть спасателями для автоматизации ваших сборок и автоматизации вашего тестирования.
1 голос
/ 18 ноября 2010

ОК, пара мыслей:

Для такого типа рабочего процесса вы бы сделали НАМНОГО лучше с SCM с потоковой моделью, такой как Accurev или ClearCase. В потоковой модели работа передается от потоков каждого разработчика к потокам интеграции, затем к потокам QA, а затем к потокам выпуска (или к тому, что работает лучше всего). Поднимается только работа, готовая перейти к следующему этапу, и интеграция может быть выполнена только с этими пакетами работ.

Как сказал deceze, вам нужно разбить вещи на части более модульно, но вам также нужно объединить это с системой локализации, где специфичные для клиента функциональные возможности могут переопределять определенные части кода. Один из способов сделать это в PHP - реализовать оболочку импорта файлов PHP, которая сначала ищет клиентскую версию файла PHP, и, если она не существует, вместо этого загрузите универсальную версию.

function importModule($module, $clientId){
   if(is_file("${clientRootDir}/${clientId}/${module}.php")) {
      import("${clientRootDir}/${clientId}/${module}.php");
   } else {
      import("${defaultRootDir}/${module}.php");
   }
}

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

Наконец, с таким количеством «виртуальных веб-сайтов» для тестирования, вы получите огромную выгоду от добавления автоматического модульного тестирования (в виде PHPUnit) в сочетании с непрерывной интеграцией для автоматического запуска тестов, когда программное обеспечение подходит к стадии интеграции.

...