Создание Отдельной Системы Управления Техническими И Бизнес-Версиями

Распространенной проблемой в моей компании является управление версиями. Мы следуем системе версий отформатированный очень похоже на семантическое версионирование (но не определение). Наше текущее управление версиями используется не только разработчиками, но и отделами маркетинга/продаж в примечаниях к выпуску, рекламе и т. д. Часто возникают конфликты относительно того, какими должны быть версии. То, что команда разработчиков определяет как серьезное изменение (изменение API без обратной совместимости), часто не рассматривается маркетингом как «серьезное» изменение. В других случаях маркетинг будет настаивать на увеличении основного, потому что это существенное изменение рабочего процесса клиента, но с точки зрения разработки изменение очень незначительное (часто просто исправление кода приложения).

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

Каковы некоторые сложности при наличии двух систем управления версиями? Каковы некоторые преимущества разделения? Какое влияние это окажет на команды и компанию в целом?

#версии

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

Для маркетинга это не имеет большого значения — все выглядит по-прежнему, так почему же покупатель заметит это изменение? Нет необходимости рассматривать это как серьезное изменение... если только вы не разработчик, в этом случае вы рискуете получить огромное количество обращений в службу поддержки по поводу этих ошибок.

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

Итак, похоже, вам нужно решить, для чего, по вашему мнению, нужна нумерация версий.

• Используются ли номера версий для обозначения риска для клиентов?
• Какую систему контроля версий вы используете
• Нужны ли для разработки номера версий? совсем или достаточно ли идентификаторов фиксации?
• Содержит ли план разработки нумерацию версий для установления сроков?

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

Примечание: теги git отлично подходят для любой схемы нумерации версий, которую вы упомянули.

На мой взгляд, версию ПО не следует обновлять, если меняется документация, при этом само ПО не меняется.

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

В заключение можно использовать то же управление версиями, но если обновляется только документ, можно добавить метаданные, например 1.2.3-20171017. Используя метаданные, можно было увидеть, что документ принадлежит версии X программного обеспечения, а также увидеть, что документ был обновлен.