Работа с номерами версий программы

Октябрь 11, 2019

Старая моя статья на хабре.
———————————————
А на моей машине все работает!
Из ненормативной лексики программистов.

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

У моего IE номер версии 8.0.6001.18828, а у Paint версия 6.0, но номер сборки 6002.
Для обозначения номеров версий продуктов Microsoft Office используется следующий синтаксис:
aa.bbbb.cccc
* aa: Версия Office.
* bbbb: Версия исполняемого файла программы, например Excel.exe.
* cccc: Версия файла Mso.dll.

Но оригинальнее всего поступил Дональд Кнут. С версии 3.0 TeX использует характерную систему нумерации версий: каждое обновление добавляет дополнительную десятичную цифру к номеру версии, так что она асимптотически приближается к π. Это отражает тот факт, что текущая версия TeX’а — 3.1415926 — очень стабильна и возможны лишь мелкие обновления (см. ru.wikipedia.org/wiki/TeX).

Забудем пока о шутке Кнута. Как все-таки удобнее? В своем семинаре по настройке бактрекера я рассказываю про различные группы атрибутов. Есть атрибуты описательные, а есть управляющие.

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

А вот для управления фичами и дефектами удобно использовать номер официального релиза. Пусть мы набираем задачи для четырехнедельной итерации. Сейчас вышел релиз 2.14, следующий будет 2.16. То что, мы передаем в эксплуатацию должно иметь метку. Иначе конечному пользователю будет очень тяжело общаться с нами. Иногда удобно делать структуру большое изменение/малое изменение. Например, «версия 2» была на php+MySQL, а версия 3 будет на .Net+MSSQL. В четвертой же версии мы перейдем с трехуровневой на четырехуровневую архитектура и наконец сделаем толстый клиент. А в версии 5 наконец сделаем логистику в дополнение к складскому учету. Т.е. версии 2.х, 3.х, 4, х – это большие прыжки, а переход 3.12-3.14 это выпуск патчей, добавление небольшой функциональности и т.д.

Иногда делают и три уровня:
• первый уровень – большие прыжки, раз в 6-30 месяцев
• второй уровень – малые прыжки, раз в 2-4 недели
• третий уровень – срочные патчи по требованию в любое время

При этом вполне может наблюдаться картина, когда часть команды работает над версией 4.0, другая готовит 3.14, и пара ребят с быстрыми руками готовят 3.12.1 и 3.12.2 (номер 3.12.1будет у того, кто раньше нажмет коммит). Не то чтобы это было полным кошмаром конфигурационного управления, но и радости немного.

Я бы рекомендовал остановиться на двухуровневой нумерации релизов. Если ваша команда обслуживает одного клиента (поддержка и развитие системы), то удобно сделать первым номером номер плановой итерации, а вторым номер патча к продакт-версии. Для коробок будет по-другому, но и там можно обойтись двумя номерами

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

Так, например, пусть сейчас в эксплуатации находится версия 14.0 (или результат седьмой четырехнедельной итерации), в разработке находится 15.0, но при этом уже вышли патчи 14.1 и 14.2

Полный номер версии в этом случае будет выглядеть aa.b.ccc, где:
• aa – номер релиза
• b – номер патча
• ccc – номер сборки

И у вас будет примерно такое соответствие:
image

• Версия 14.0.283 (релиз 14.0, сборка 283) стоит у клиента. На следующий релиз 16.0 запланировано исправить дефекты Д14 и Д16 и добавить фичи Ф10 и Ф11.
• Команда приступает к работе, выпускает 15.0.284, с реализованными Ф10, Д14.
• Но тут пользователи находят в 14.0.283 пару дефектов. Принято решение Д17 сделать патчем, а Д16 отложить до лучших времен. Выпускается патч 14.1.285
• …
• 15.0.289 и 16.0.289 идентичны. Отличие в номерах делается, для того, чтобы показать, что это официальный релиз.

Такой способ нумерации достаточно удобен для многих случаев. Возможно, конкретно вашему проекту он не подходит. Самое главное, если будете что-то менять, помните, что есть описательные атрибуты и есть управляющие. Вы можете построить управление на других атрибутах, не относящихся к номеру версии. В этом случае номер можно упростить. А может быть и так, что всем все и так понятно и номер версии просто не нужен. Бывает и так. Впрочем, об этом или в другой статье или на тренинге.
——————-
Любопытная статья: “Семантическое Версионирование 2.0.0

Этикет онлайн тренинга

Август 30, 2019

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

  • Общаемся на “ты”
  • Мы не говорим из каких мы компаний. Так проще. Так мы не попадаем под НДА и не боимся испортить PR-рейтинг компании.
  • Если вам нужно описать какую-то ситуацию не говорим: “У нас было так” или “в компании … была такая штука”. А говорим: “Ехал в лифте, услышал”, - или: “на конференции в кулуарах обсуждали”. В лифтах иногда такое говорят…
  • Все что говорится на семинарах, на них же и остается. Если вы захотите пересказать какую-то историю «услышанную в лифте» впоследствии, вы ее слышали где-то. Но не на этом тренинге. Если запись и делается, то исключительно для внутреннего анализа. Не для публикаций в интернете.
  • Мы не спрашиваем и не называем своих должностей. Чтобы не попасть под синдром “давление авторитета” (эксперимент Милгрэма).
  • Представляться не обязательно, можно участвовать в семинарах под псевдонимом. Просто не забудьте выбрать себе читаемый / легкопроизносимый ник для Zoom на весь тренинг.
  • Постарайтесь четко разделять фазы генерации идей и фазы критики. Если кто-то высказывает “гениальную/ безумную” идею, давайте дослушаем идею до конца и запишем ее. Когда у нас накопится множество “безумных” идей мы отбросим невозможное и будем работать с тем, что останется.
  • Не забудьте на время семинара отключить мобильный телефон. И найдите тихое место.
  • На семинаре работайте с компьютера, а не с мобильника. Иногда придется совместно придется работать с доской. С мобильника это ”сложно”.
  • В начале занятий «прогрейте» голос. Можно что-то сказать с выключенным микрофоном.
  • Если пересохло горло – отключите микрофон, выпейте чаю, включите микрофон снова.

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

Невзятый мой замок

Август 28, 2019

Мне все беды не в счет,
Ведь на гребне скалы меня ждет
Невзятый мой замок.

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

Груминг заголовков

Июль 8, 2019

Танк Тигр (57 тонн) можно завести ручным стартером (на ютубе есть видео). Это тяжело. Провернуть вручную сам движок – здоровья не хватит. Поэтому сначала раскручивают тяжелый маховик. Идет тяжело, скорость вращения минимальна. Оборот, еще оборот, еще десять оборотов, еще. Быстрее, быстрее. Потом переключаем маховик на двигатель. И движок заводится. Если переключить маховик слишком рано – ничего не получится.  И все начинать сначала. Если пойти передохнуть – маховик остановится. И все начинать сначала. Оборот за оборотом, тяжеленную неподатливую  тушу маховика. Но если не раскрутить – движок не заведется и танк останется неподвижной, а потому крайне уязвимой мишенью. Хорошо бронированной, с отличной пушкой, но мишенью. Поэтому крути маховик. Крути. И не останавливайся. Пока не наберешь нужный запас энергии.

Вот также с внедрением многих практик в процесс разработки ПО. Одна из ключевых практик – приведение заголовков задач в трекере в читаемый вид. Не “Логин”, “Некорректный заказ”, “Программа не работает корректно”, “Приборы 300″, -  а что-нибудь более ласкающее взгляд. Небольшое отступление. Есть мнение и не только мое, что эту практику обязательно нужно внедрить до внедрения написания постановки задачи (требований / ТЗ …). Все, всегда пытаются сделать наоборот. С известным заранее результатом. Недавно услышал что практика причесывания заголовков называется «Груминг». Более пятнадцати лет этому учу, а теперь узнал, как называется.
Читать дальше »

Различные подходы к риск менеджменту. Краткий экскурс.

Июнь 29, 2018

Откопал  в архивах свою старую статью об управлении рисками. Статья аж от 2005 года. Сейчас я бы написал ее совершенно по-другому. Добавил бы про то, что риск оптимумы являются частным случаем карт Шухарта, Что есть и другие подходы и т.д. Но иногда самому интересно, как я писал много лет назад. Пока оставлю как есть. Даже без комментариев.

Читать дальше »

Метрики тестирования

Июнь 12, 2018

Мы все утопаем в океане данных, но при этом,

очень редко можем получить необходимую информацию.

(С) Э. Голдратт
10-го июня прошел очередной онлайн тренинг по метрикам тестирования программного обеспечения. Это один из модулей большого  тренинга «Ключевые процессы, метрики и артефакты тестирования».  Материал достаточно сложный. И вопрос даже не столько в опыте участников сколько в знакомстве с теорией ограничений.

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

Читать дальше »

Анализ процессов при помощи карт Шухарта. Синопсис вебпосиделок Клуба иФБ.

Июнь 9, 2018

“Шухарт изобрел и опубликовал это правило в 1924 г.
С тех пор никто не сделал ничего лучшего.”

Что такое карты Шухарта?

Существует множество способов описания процессов: BPML, UML, IDEF, блок схемы, EPC, забытые структурно-информационные временные диаграммы и т.д. Они очень хорошо помогают, когда надо писать софт. Т.е. Когда процессы проанализированы, улучшены и теперь остается только их описать и передать программистам. Но часто нужно именно проанализировать процессы с целью их улучшения.

Читать дальше »

Правила работы с трекером. Синопсис вебпосиделок клуба иФБ

Май 31, 2018

Правила, приведенные ниже были озвучены на “вебпосиделках” Клуба иФБ в мае 2018. Работали по модели первой фазы мозгового штурма. По очереди высказывали правила, которые на взгляд участника наиболее важны. Фазы критики не было. Т.е. это пока материал для обсуждения. Кроме того, участники предлагали эти правила не для крохотных проектов, а имели в голове производство со сложным гетерогенным продуктовым ландшафтом на 100+ систем. Так что, вполне возможно, вам эти правила не подойдут. И да, это, естественно, не все правила. Времени на обсуждения было мало.
Приятного чтения.

Читать дальше »

Посиделки клуба иФБ

Май 21, 2018

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

А потом эта группа решила собираться на регулярной основе на «посиделки».

Собираемся в вебе. Пока через zoom. В воскресенье с 10 до 11. Ну, так получилось. Собрания открытые. Может приходить, кто хочет.

Читать дальше »

Пример документа описания архитектуры взаимодействия многих систем

Май 15, 2018

spec_architecture.zip

Полагаю, имею право уже опубликовать, т.к.