Есть ли какая-то связь между версионированием и вехами?

Question

Множество проектов ОС, которые я знаю (я PHP-разработчик), используют версии в качестве вех, но это лучший способ? Должны ли вехи что-то значить в процессе итераций проекта (полные имена)? Есть ли правила? Или, может быть, это совершенно субъективно?

Answer 1

Как гласит старая пословица: «Прекрасно, что в стандартах есть так много выбора». Я не могу рассказать вам, как бы я это сделал для проекта PHP, но я могу рассказать вам о подходе, который мы используем для нашего магазина - магазина .NET.

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

Major.Minor.Revision.Build

Очевидно, что каждый из них будет числом. Эти четыре части предопределены для нас Microsoft. Позвольте мне рассказать вам о том, как мы оправдываем каждое из них:

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

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

В нашем магазине содержание вехи важнее, чем то, что она называется. Зачем? Сложные вехи не могут быть легко названы так, чтобы передать смысл, когда есть несколько причин, по которым это веха. Мы ставим вехи в календаре и вики с описанием ожидаемых результатов.

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

Answer 2

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

Наша стандартная схема этапов основана на общекорпоративном стандарте управления проектами. У нас есть

• S-Gate: Указано
• A-Gate: Доступен
• V-Gate: Проверено
• R-gate: Выпущено

Для итеративной разработки мы в основном повторяем этот цикл. От A до V gate - альфа-фаза, от V до R - бета-фаза. Для более крупных проектов мы добавляем этапы, относящиеся к конкретным наборам функций, которые будут выполнены.

Причина, по которой мы его используем, заключается главным образом в том, что все проекты представляются в соответствии с этой схемой, и всегда полезно представлять информацию руководству в известной ему форме; -)

Answer 3

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

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

Во-первых, работа по разработке программного обеспечения.

1. У нас есть спринты, чтобы строить вещи. Они могут быть пронумерованы, но обычно имеют имена. Такие имена, как «Массовая загрузка, часть 1», «Библиотека книги Refactor», «Добавить исправление данных демонстрации продаж» или тому подобное.

2. У нас есть релизы для релиза. Они могут быть пронумерованы (на основе версии SVN или на основе нашей внутренней «версии совместимости», но обычно они имеют имена. «Первый выпуск для клиента X», или «Исправление ошибки», «Обновление до этого» или что-то в этом роде). осмысленным.

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

1. SVN имеет номера версий репозитория. Это увеличивается с каждой регистрацией. Несколько недель, регистрация каждый день. Иногда бывает только несколько «больших» проверок.

2. У нас есть номер версии major.minor, который мы обновляем вручную, чтобы показать совместимость. Некоторые приложения переходят с 1.1 на 1.2, потому что что-то небольшое изменилось, но база данных и API одинаковы. Другие приложения переходят с 2.3 на 3.1, потому что база данных или API (или оба) изменились каким-то несовместимым образом, и нам нужно выполнить миграцию схемы и, возможно, уведомить клиента об изменениях в клиентском интерфейсе REST.

В-третьих, есть планирование проекта.

Планирование нашего проекта этапы включают наш график выпуска. Тем не менее, вехи проекта включают в себя другие вещи, которые имеют мало общего с программным обеспечением. Основные этапы включают в себя такие вещи, как, например, «Подписание нового соглашения о хостинге» или «Получить данные тестирования клиента X». Это не версии, не релизы, не спринты и не все.

"Есть ли правила?" Да. Читайте Scrum для хорошего набора правил.

Это не единственная вещь. Это две (или три) вещи.

Answer 4

Ну, да, это означает, что вы выполнили достаточно работы за итерации, чтобы выпустить что-то полезное. Веха обычно означает, что вы достигли чего-то более значимого, чем просто конец итерации. Я бы использовал значимые имена да.

Answer 5

Номера версий удобны, потому что вы можете мгновенно взять любые две версии и посмотреть, какая из них более новая. Это всегда будет в какой-то степени субъективным, потому что, кто скажет, какая особенность (и) или исправление (я) исправления являются вехой?

Мне нравится схема x.y.z, где x - номер основной версии, y - номер вспомогательной версии, а z - номер сборки. Основной выпуск будет означать либо переписать, либо пересмотреть, либо ввести новые важные функции. Незначительный выпуск будет означать значительное исправление ошибки или количество мелких улучшений или исправлений ошибок. Номер сборки будет именно таким - количество сборок.