Управление версиями с автоматической системой сборки

Question

Мы недавно перешли на автоматическую систему сборки (что-то внутреннее, но не Hudson или Teamcity).
Наша версия хранится в заголовочном файле и включена в некоторые файлы cpp и resource.Он также используется установщиком.

Его формат A.B.C.D, где:

• A не менялся годами.
• B изменяется редко (основнойверсия).
• C изменяется с дополнительными версиями.
• D изменяется при доставке в QA новой вспомогательной версии (исправление ошибки).

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

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

Как к этому следует подходить?

• Увеличивать ли я D всякий раз, когда создается новая сборка, будь то сборка QA или сборка для внутреннего тестирования (т. Е. Я работаю над какой-то функциейЯ хотел бы проверить, я ничего не сломал)?
• Является ли шаг инкремента задачей в автоматической системе сборки?
• После приращения я должен зафиксировать файл версии?
• Как мне избежать большого шума в контроле версий?Я не хочу, чтобы тонны коммитов были увеличены.
• Что мне делать, если сборка не удалась?По-прежнему увеличивать версию и фиксировать?

Answer 1

Увеличивать ли я D всякий раз, когда создается новая сборка, будь то сборка QA или сборка с внутренним тестом (т.е. я работаю над какой-то функцией, и я хочу проверить, что я ничего не сломал)?

Да, измените ваш процесс так, чтобы D увеличивался с каждой сборкой (успешной или нет), а не с каждой доставкой в ​​QA.

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

Является ли шаг приращения задачей в системе автоматической сборки?

Я бы хотел, чтобы система сборки автоматически увеличивала только номер сборки (D).

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

Память управления версиями предназначена для записи подробных шумов.

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

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

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

Что мне делать, если сборка не удалась? По-прежнему увеличивать версию и фиксировать?

По-прежнему увеличивать номер версии, я бы не зафиксировал номер версии, если бы она не была успешной сборкой. У вас могут быть различные сбои, не связанные с изменением исходного кода в управлении версиями, которые не нужно записывать - сборка сервера с диска, сбой сервера, компилятор все время шатается в коленях при сборке 32 и 64 бит, отладка и выпуск aix Линукс и виндовс собираются одновременно ...

Answer 2

Увеличивать ли я D всякий раз, когда создается новая сборка, будь то сборка QA или сборка с внутренним тестом (т.е. я работаю над какой-то функцией и хочу проверить, что ничего не сломала)?

Eclipse Foundation добавляет элемент E, дату и время сборки.Я думаю, что это хорошая идея для внутренних тестовых сборок.Вам решать, хотите ли вы использовать E для построения QA.

Является ли шаг приращения задачей в системе автоматической сборки?

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

Как мне избежать большого шума в контроле версий?Я не хочу, чтобы тонны коммитов были увеличены.

Зафиксируйте файл управления версиями с исходным кодом.

По сути, ваш процесс сборки разработки должен продолжаться в следующем порядке.

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

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

Процесс производственной сборки начнется со 2-го шага, пропуская 3-й шаг.

Что мне делать, если сборка не удалась?По-прежнему увеличивать версию и фиксировать?

Мой E автоматически увеличивается.:-) Я бы сказал нет для других элементов A, B, C или D.

Answer 3

Я бы порекомендовал использовать autorevision .

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

Answer 4

Как вы собираетесь автоматизировать это? Я имею в виду, какая система будет знать, что «эта сборка является сборкой релиза!». Мне кажется, что все ваши цифры в версии актуальны. Если для следующего выпуска (D + 1) требуются две сборки, то будет ли A.B.C.D + 2 следующей версией? Звучит подозрительно для меня. Вместо этого я бы добавил номер сборки поверх версии, если действительно необходимо иметь эту информацию в ваших DLL и EXE-файлах.

Я не думаю, что номер сборки - это релевантная часть информации, которая должна быть прикреплена к двоичному файлу, , если вы не распространяете файлы версии ABCD из разных сборок (что вам не следует делать в любом случае!)

Я бы настроил сервер сборки для хранения артефактов (DLL, EXE, MSI, PDB и т. Д.) В каталоге, имя которого включает номер сборки и версию, а затем записывал DVD / что-нибудь оттуда. Если вам когда-либо понадобится вернуться от версии к конкретной сборке, вы можете использовать эту информацию при условии, что вы храните архив своих выпусков (рекомендуется!).

Answer 5

Вы можете использовать соглашение для сборок .NET, как описано в документации для class System.Version. Цитата:

• Build [your C]: Разница в номере сборки представляет собой перекомпиляцию одного и того же источника. При изменении процессора, платформы или компилятора могут использоваться разные номера сборки.
• Редакция [ваш D]: сборки с одинаковыми именами, номерами старших и младших версий, но с разными ревизиями, должны быть полностью взаимозаменяемыми. В сборке, которая устраняет дыру в безопасности ранее выпущенной сборки, может использоваться более высокий номер ревизии.