Эффективный рабочий процесс, позволяющий дизайнерам получить доступ к части репозитория SVN.

Question

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

Разработчики работают над веб-приложением в репозитории SVN локально на своей машине. У нас есть рабочие станции Windows 2003, которые позволяют каждому разработчику размещать каждый веб-сайт в IIS для целей отладки. Мы используем TortoiseSVN и Visual Studio с VisualSVN.

Функция разработчика состоит в том, чтобы получить новую функциональность и работать, а затем дизайнеру нужно войти и внести изменения в страницы, скины, CSS и т. Д., Чтобы сделать его красивым, но изменения, которые они вносят, должны вернитесь обратно в хранилище, чтобы их могли просматривать разработчики, а не перезаписывать.

Наличие у каждого дизайнера собственного IIS-сервера, с которым можно поиграться, невозможно с точки зрения поддержки. Наилучшее решение, которое мы можем предложить в настоящее время, - это настроить сервер проектирования с независимой общей проверкой части сайта в репозитории SVN и позволить всем дизайнерам вносить изменения в этот сайт через общий ресурс UNC, а затем фиксировать свои изменения, используя только TortoiseSVN. Затем разработчики обновятся, чтобы получить эти изменения для публикации в Test и, в конечном итоге, в Live.

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

Есть ли другие проблемы, о которых я не думаю?

Кто-нибудь еще придумал лучшее решение для этого типа рабочего процесса?

(Я боролся с тегами на этом, любая помощь в повторной привязке будет принята с благодарностью.)

Answer 1

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

Одной из возможностей может быть наличие одного IIS для всех ваших дизайнеров, но каждый (например, johndoe) будет работать над своим собственным приложением (скажем, http://johndoe.ueberserver.local/application), которое извлечено на сетевой диск (например, i: / johndoe / application). Таким образом, Джон может работать с некоторыми файлами и видеть результат в браузере.

Когда Джону пора проверить свои изменения, вы можете либо позволить ему сделать это, либо назначить "приятеля", который сделает это за него.

Answer 2

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

1. Можете ли вы предоставить им отдельные рабочие области в одной области сервера IIS? (возможно, с извлеченными областями рабочей области в папке, названной в их честь?) Таким образом, они будут фиксировать свою работу только из своих собственных рабочих областей. Конечно, это предполагает, что они работают над неперекрывающимся кодом и, следовательно, не будут перезаписывать часть работы друг друга при фиксации. Кроме того, они должны быть обучены, чтобы делать svn-обновления, прежде чем они начнут свою работу, чтобы у них были последние изменения от других в их пространстве, чтобы избежать любых конфликтов. (Я всегда нервничаю, когда несколько человек используют одну и ту же рабочую область)

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

Answer 3

Дизайнеры используют Visual Studio? Если это так, то вы можете использовать встроенный веб-сервер, который поставляется с VS, таким образом, вам вообще не нужен IIS. Вот как я делаю все свое развитие.

Если вы используете функции ветвления Subversion, то каждый разработчик может создать свою собственную ветку и работать в ней, пока не почувствует себя комфортно при объединении с транком или какой-либо веткой версии, над которой работают остальные разработчики.

Сохранение всех в максимально возможной изоляции приводит к тому, что все движется гладко. Это означает, что нет общего веб-сервера. Это действительно методология, для которой Subversion был построен в любом случае.

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

Answer 4

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

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

Как только это произошло, ствол должен быть разветвлен, и дизайнеры должны зафиксировать свои изменения в этой ветке.

Когда они закончат, разработчики могут просмотреть все изменения и объединить то, что необходимо для ствола для выпуска.

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

Answer 5

Я не понимаю, как вы сможете получить лучшую схему, чем та, которую вы упомянули, если вы не ослабите ограничение «максимум один сервер IIS». Разве нельзя использовать виртуальные машины, чтобы каждый разработчик мог получить свой собственный сервер? Все эти машины могут использовать один и тот же файл конфигурации. Тогда дизайнерам не придется беспокоиться об изменениях друг друга ...