Развертывание решения, CM, InstallShield

Люди,

У нас есть 4 или 5 утилит, которые работают вместе с нашим приложением. Этими утилитами являются либо .bat-файлы, либо приложения VB, PowerBuilder и т. Д. Я пытаюсь управлять этими утилитами в управлении исходным кодом и пытаюсь найти лучший способ присвоения им версий. Прямо сейчас разработчики используют метаданные системы управления версиями - в частности, метку - для хранения номера версии инструмента.

Моя цель - иметь индивидуальные пакеты InstallShield для каждой утилиты и простой способ управлять этими номерами и назначать им номера версий.

Вы бы порекомендовали отдельный файл .ini с информацией, или сохранили бы информацию в самом файле InstallShield .ism, или просто использовали информацию метаданных из средства контроля версий?


ОБНОВИТЬ:

Мне нравится идея Ориона. У меня есть одна проблема, хотя. Сценарий, который увеличивает номер версии ... он не может быть достаточно умным, чтобы увеличивать номер и т.д. например, если один из утилит имеет версию 1.2.3, и мы находимся в точке, где новая версия 2.0.0. Сценарий может не справиться с этим.

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

3 ОТВЕТА

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

Было около 30 проектов C ++, которые требовали компиляции, а также различные вещи .NET / Java и нечетный Perl-скрипт.

Все это было построено на нашей сборочной машине с использованием NAnt. Если бы я делал это сегодня, я бы использовал rake , но идея та же.

У нас был автоматически наращиваемый номер сборки, который хранился в файле version.txt в корне хранилища.

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

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

  • Я почти уверен, что наши программы installshield ссылались на переменную окружения в качестве номера версии, но мы отказались от них в пользу wix, так как installshield действительно сосал
  • в случае Visual Studio, grep / заменить число в файлах .csproj и проверить их обратно в

Надеюсь, что это дает вам некоторые идеи

0
21.08.2008 01:58:08

В частности, в PowerBuilder есть хороший трюк, который вы можете сделать, чтобы включить номер сборки из INI-файла в скомпилированное приложение.

Подробности здесь: http://www.pbdr.com/pbtips/ex/autorev.htm

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

1
2.09.2008 19:50:15

Использование метаданных из вашей системы контроля версий должно упростить задачу. Это то, как ваши разработчики уже используют систему. Нет дополнительного файла для обслуживания. Мой личный опыт научил меня создавать версии спутниковых приложений, аналогичные версии основного приложения. ПОЦЕЛУЙ

0
20.09.2008 16:41:29