Идеи по настройке системы управления версиями

Question

Мне было поручено настроить контроль версий для наших веб-разработчиков. Программное обеспечение, которое было выбрано для меня, потому что у нас уже есть другие не-веб-разработчики, использующие его, является Serena PVCS.

Мне сложно решить, как настроить его, поэтому я расскажу, как происходит развитие в нашей системе, и, надеюсь, это приведет к некоторому обсуждению того, как это сделать.

У нас есть 3 сервера, разработка, UAT/постановка и производство. У веб-разработчиков есть доступ только для записи и проверки их кода на сервере разработки. Когда они пишут код, они должны пройти процесс сертификации, чтобы перевести код в UAT/Staging, а затем после тщательного тестирования кода он переместится в Production.

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

Я думал, что они должны использовать только контроль версий, когда они готовы перейти на UAT/Staging. Это позволяет им разрабатывать и тестировать без постоянной проверки их кода.

Группа сертификации затем может использовать элемент управления версиями, чтобы узнать, какие изменения были внесены в модуль, и убедиться, что они всегда получали последнюю версию от разработчика, чтобы выставить на UAT/Staging (теперь мы полагаемся на разработчик обновляет свои измененные файлы и загружает их через систему веб-запросов).

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

Любые мысли или идеи были бы весьма признательны. Благодарю.

Answer 1

Я бы не рассматривал контроль источника как раздражение. См. Ответ Никса по причинам.

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

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

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

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

Этот процесс должен включать в себя, по меньшей мере:

• Когда совершить.
• Когда разветвляться/сливаться.
• Что/когда маркировать.
• Общий рабочий процесс.

Answer 2

Использование источника управления не вызывает раздражения, это инструмент. Наличие преимуществ ветвления и тегирования неоценимо при работе с новыми API и библиотеками.

И всего лишь одно замечание, на пару месяцев назад одна из машин Dev's потерпела неудачу и потеряла все свои новейшие источники, мы спросили, когда последний раз он совершил код с контролем источника, и это было 2 месяца. Иногда просто иметь его для резервного копирования материала, когда вы достигаете вехи, приятно.

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

Answer 3

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

Answer 4

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

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

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

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

Итак, если другая команда заявляет, что вы должны использовать Серену, отодвиньте назад. Этот продукт ужасен.