Развертывание решения, CM, InstallShield - PullRequest
Новая
       29

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

0 голосов
/ 20 августа 2008

Люди,

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

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

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

ОБНОВЛЕНИЕ:

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

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

Ответы [ 3 ]

1 голос
/ 02 сентября 2008

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

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

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

0 голосов
/ 20 сентября 2008

Использование метаданных из вашей системы контроля версий должно упростить задачу. Это то, как ваши разработчики уже используют систему. Нет дополнительного файла для обслуживания. Мой личный опыт научил меня создавать версии спутниковых приложений, аналогичные версии основного приложения K.I.S.S

0 голосов
/ 21 августа 2008

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

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

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

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

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

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

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

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

...