My<cod/>.net
Решение deployment, CM, InstallShield
Люди,
У нас есть 4 или 5 утилит, которые работают в сочетании с нашим приложением. Эти утилиты представляют собой либо .bat файлов, либо VB приложения, PowerBuilder и т. д. Я пытаюсь управлять этими utils в системе управления версиями и пытаюсь найти лучший способ назначить им версии. Прямо сейчас разработчики используют метаданные системы управления версиями-в частности, метку-для хранения номера версии инструмента.
Моя цель состоит в том, чтобы иметь индивидуальные пакеты InstallShield для каждой утилиты, а также простые средства для управления и назначения номеров версий этим пакетам.
Вы бы рекомендовали отдельный файл .ini с информацией, или хранить информацию в самом файле InstallShield .ism, или просто использовать информацию о метаданных из средства управления версиями?
UPDATE :
Мне нравится эта идея, Орион. Но у меня есть одна забота. Скрипт, увеличивающий номер версии... он не может быть достаточно умен, чтобы увеличить основное число и т. д. право. напр. если один из utils имеет версию 1.2.3, и мы находимся в точке, где новая версия является 2.0.0. Сценарий может быть не в состоянии справиться с этим.
Я думаю, что это во многом связано с нашими методами ветвления-у нас их нет. Люди думали, что раз уж утили такие маленькие, то источник может и не нуждаться в ответвлениях.
PowerBuilder в частности имеет хороший трюк, который вы можете сделать, чтобы включить номер сборки из файла ini в скомпилированное приложение.
Подробности здесь: http://www.pbdr.com/pbtips/ex/autorev.htm
У нас есть файл ini внутри системы управления версиями, который хранит номер сборки, и его значение используется в наших сценариях сборки, чтобы определить, какую метку применить к дереву исходных текстов после успешной сборки. Работает очень хорошо для наших нужд. Когда мы ветвимся, нам приходится вручную пинать файл, чтобы увеличить нужное число.
Я управлял нашей системой сборки на моей последней работе, которая, казалось, имела некоторые параллели с тем, что вы спрашиваете.
Там было ~30 C++ проектов, которые требовали компиляции, и различные .NET/Java вещей, и нечетный perl скрипт.
Все это было построено на нашей машине сборки с использованием NAnt - если бы я делал это сегодня, я бы использовал rake, но идея та же.
У нас в основном был автоматически увеличивающийся номер сборки, который хранился в файле version.txt в корне репозитория.
Каждый раз, когда мы делали сборку (автоматически каждую ночь или по требованию, если это было необходимо), скрипт увеличивал это число и возвращал файл обратно в систему управления версиями.
Все другие приложения ссылались на этот файл для своего номера версии, или для вещей, которые не поддерживали работу подобным образом, сценарий устанавливал переменные среды или выполнял другие обходные пути
- Я почти уверен, что наши программы installshield ссылались на переменную окружения для своего номера версии, но мы устранили их в пользу wix , поскольку installshield действительно был отстой
- в случае visual studio grep / замените число в файлах .csproj и верните их обратно
Надеюсь, это даст вам некоторые идеи
Использование метаданных из вашей системы управления версиями должно упростить задачу. Это то, как ваши разработчики уже используют систему. Нет никакого дополнительного файла для обслуживания. Мой личный опыт научил меня версировать спутниковые приложения с той же версией, что и основное приложение. K.I.S.S