Мне было поручено выяснить, как улучшить контроль над версиями в моей компании.
Справочная информация
В настоящее время мы используем Borland StarTeam, у которого есть некоторые проблемы.Помимо того, что его часто трудно использовать, количество инструментов (поддержка IDE, проверка кода и т. Д.), Которые его поддерживают, очень мало.
В нашей компании около 40 разработчиков, но мы работаем с большим количествомразные проекты.В данном проекте обычно работают 3-6 разработчиков программного обеспечения.Наши проекты варьируются от (в основном) встроенных систем и разработки ПЛИС до настольных приложений.
Текущий рабочий процесс в значительной степени централизован с одним «представлением» (которое близко к ветви на языке StarTeam), которое каждый в проектеработает на.
Один из проектов использует несколько представлений следующим образом: Существует представление платформы, где не ведется разработка.Это представление затем имеет два вспомогательных представления для двух конкретных продуктов, которые совместно используют большую часть кода (через представление платформы), но достаточно различаются, чтобы их можно было разделить.Вся разработка выполняется в двух представлениях продукта, и иногда код из представления продукта переводится в представление платформы (которое затем автоматически доступно для другого продукта).
В другом проекте, похоже, используется основной вид ипросмотр функций, когда были добавлены основные функции.
Обычно нам приходится долго поддерживать программное обеспечение и предоставлять обновления программного обеспечения.
Некоторые из наших продуктов имеют большое количество различных версий.Разные версии будут совместно использовать большую часть кода, но некоторые части отличаются друг от друга и должны отличаться.
Разработчики используют Windows и Linux на своих рабочих станциях.
Идея
Моя идеяэто переключиться на использование современного DVCS.Рабочий процесс, который я рассматриваю, состоит в том, где каждый проект имеет несколько открытых веток, которые каждый разработчик может клонировать и работать над ними.Каждый проект мог бы затем определить, может ли каждый свободно выполнять коммиты или у нас должна быть какая-то система сторожевого устройства, где код должен пройти человеческую или автоматизированную систему сборки, прежде чем переходить в публичную ветвь.
Моя идея онастройка ветвления заключается в использовании веток релиза и функций, как в следующем сценарии:
Допустим, мы начинаем с разработки и наконец выпускаем версию 1.0 нашего продукта.Затем мы обнаруживаем, что нам нужны дополнительные функции, поэтому мы стремимся к выпуску 2.0 и начинаем новую ветку для этого.Работая над веткой выпуска 2.0, мы все еще можем выполнять обслуживание ветки 1.0, ведущей к выпуску версии 1.1 и т. Д.
Во время работы над веткой 2.0 мы обнаруживаем проблему безопасности, которая устранена.Так как он доступен и в ветке 1.0, этот код также перенесен в ветку 1.0.
Иногда в ветке 2.0 обнаруживается, что некоторые части системы действительно должны быть полностью переделаны, чтобы иметь возможностьсоздать функцию X. Новая открытая ветка 2.0-feature-X создана и работает над ней.Когда работа будет завершена, работа в этой ветке будет объединена с основной веткой 2.0.
Актуальные вопросы
Надеюсь, вы все еще читаете:)
Является ли вышеуказанный рабочий процесс (выпуск и ветвление функций) приемлемым вариантом?Есть ли ямы, которые стоит посмотреть?
В том случае, когда у продукта есть ветвь платформы и несколько веток, каков наилучший способ справиться с этим?Будет ли работать мастер ветка и ветки продукта?Есть ли проблема, когда две ветви продукта расходятся?На сколько они могут расходиться?
Я что-то пропустил?Я в основном вижу VCS с точки зрения разработчика, поэтому мне может не хватать того, что важно с точки зрения менеджера конфигурации или выпуска.