Сообщений в теме: 15

[saezar]

Какой инсталлятор интегрируется с SVN?

[greesha]

А что интегрировать-то? Нужно инсталлировать файлы прямо в репозиторий? ;) Или извлекать из репозитория файлы для сборки инсталляционного пакета? Или просто нужно отслеживать изменения в инсталляционном проекте с помощью SVN?

[saezar]

Извлекать из репозитория файлы для сборки инсталляционного пакета. Очень желательна поддержка автоматичческих сборок. Пытаемся перейти сначала на еженедельные сборки.

[Alfa]

Извлекать из репозитория файлы для сборки инсталляционного пакета. Очень желательна поддержка автоматичческих сборок. Пытаемся перейти сначала на еженедельные сборки.

То, что вы ищете называется сервер непрерывной интеграции (continuous integration server). Таких есть много под разные технологии (java, .NET, etc). Начать поиск подходящего вам инструмента можно например здесь в разделе инструменты, ну и далее по ссылкам. Более объемная подборка и сравнения инструментов есть тут.

Мой совет переходить сразу на непрерывную интеграцию -- это не сложно.

[saezar]

Спаибо за ссылки, внимательно посмотрел. Интересно всё это, возможно мы когда ни будь к этому придём, но сейчас другая задача - из скомпилированных файлов собирать инсталляшки. В репозиториях SVN предполагается хранить не только исходный код но и скомпиленый файлы. Так что вопрос остался. (Или я чего то не понял в идее непрерывных сборок)
Я посмотрел на Wise Installer - у меня есть только 5-й, он SVN в упор не видит, хотя интеграция контроля версий там заявлена. Приглядываюсь к WIX, бесплатный , мощный, консольный - позволит писать скрипты, в которых вручную можно выдёргивать head revision из репозиториев.
Остальные, во всяком случае в описаниях, что я читал, нигде не заявляют о возможности сборки из репозитория.

[rlabs]

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

Заранее прошу прощения, особо не вникал в дискуссию,
но, по-моему, вы путаете теплое с мягким и мешаете горячее с синим.
Не очень понятен смысл "сборки из репозитория". У вас есть инструмент для сборки. Он должен работать с тем, что дадут. У вас есть репозиторий. Он должен отдавать то, что просят. На этом - всё.

Первый шаг к нормальному техпроцессу сборки - это организация сборки в одну-две команды. Идеальная последовательность команд: взять свежие исходники - сконфигурировать - собрать - опубликовать (или "задеплоить" в случае уже размещенных приложений).

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

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

[saezar]

Вопервых. Никаких исходников нет. Я имею ввиду - для меня они недоступны.
Вовторых. Разделим понятия сборка бинарников и сборка инсталляшки. К сборке бинарников я не имею никакого отношения и в ближайшем обозримом будущем иметь не буду. Мне через репозиторий передаются только бинарники. Из них я должен собрать инсталляшку всего пакета.
Втретьих. Вопрос всего лишь в том, что бы программа собирающая инсталляшки (WiseInstaller например) умела делать чекаут из свн-а сама, не вынуждая меня делать это вручную. Тоесть хочу сделать

Первый шаг к нормальному техпроцессу сборки - это организация сборки в одну-две команды

Я не увидел в СС средств для сборки инсталляшек, а WiseInstaller - средств работы с SVN.
В четвёртых.

У вас есть инструмент для сборки. Он должен работать с тем, что дадут. У вас есть репозиторий. Он должен отдавать то, что просят.

Собственно про него и спрашиваю. Репозиторий отдавать то что попросят умеет по определению, а вот какой инструмент умеет у него просить, я и хотел выяснить этим топиком. Тоесть инструмента для сборки у меня пока нет. Я его выбираю. Ещё раз подчеркну, из бинарников собрать " *.msi "
Или я всётаки чегото не понимаю.

[rlabs]

Вопервых. Никаких исходников нет. Я имею ввиду - для меня они недоступны.
Вовторых. Разделим понятия сборка бинарников и сборка инсталляшки. К сборке бинарников я не имею никакого отношения и в ближайшем обозримом будущем иметь не буду. Мне через репозиторий передаются только бинарники. Из них я должен собрать инсталляшку всего пакета.

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

Втретьих. Вопрос всего лишь в том, что бы программа собирающая инсталляшки (WiseInstaller например) умела делать чекаут из свн-а сама, не вынуждая меня делать это вручную. Я не увидел в СС средств для сборки инсталляшек, а WiseInstaller - средств работы с SVN.
В четвёртых. Репозиторий отдавать то что попросят умеет по определению, а вот какой инструмент умеет у него просить, я и хотел выяснить этим топиком. Тоесть инструмента для сборки у меня пока нет. Я его выбираю. Ещё раз подчеркну, из бинарников собрать " *.msi "
Или я всётаки чегото не понимаю.

Да. Не понимаете. Как выглядит процесс сборки сейчас? Ну, предположим, как-то так (предположим, используется NSIS):

c:\Work>svn checkout <репозиторий>…Checked out revision 8810.c:\Work>nsis.exe <скрипт>

Этот пример решает задачу "собрать инсталлятор из SVN"? По-моему, решает. Но вам хочется делать это не двумя командами, а одной, правильно? Напишите батник, который будет это делать.

Если же хочется запускать батник не руками, а как-нибудь автоматически - по таймеру, например, или после появления в репозитории новых исходников, или просто чтобы была где-нибудь большая кнопка "СОБРАТЬ" - используется средство автоматизации, такое, как CruiseControl.

Краткий курс по CruiseControl для тех, кто не прочитал его описание на сайте. В каждом проекте есть а) действия - например, получить код из репозитория, запустить батник, собирающий продукт; б) триггеры, запускающие действия - например, "в 9 утра в субботу" или "после каждого сабмита в репозиторий"; в) паблишеры - "сообщить о результатах сборки по электронной почте" и тд и тп. Используя эти три средства, вы делаете свой автоматический сборщик. Самому CC все равно, что вы делаете с его помощью, он просто умеет связывать все в один процесс.

Можно еще почитать книжку Pragmatic Project Automation, правда там про Java-проекты в основном.

Что касается конкретных средств приготовления инсталляторов, я бы не советовал Wise, а советовал бы Wix. У последнего больше преимуществ и (кажется) меньше проблем. Но - не надо заставлять Wix работать с SVN. Его дело - собрать продукт из того, что лежит на диске. Как свежие исходные файлы попадают на диск - не его проблема.

[Alfa]

Пара уточнений.

Сборка - процесс осмысленный.

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

В кадом проекте есть а) действия - например, получить код из репозитория, запустить батник, собирающий продукт;

"Получить код из репозитория" не надо относить к действиям. Это скорее триггер "что-то изменилось в репозитории".

А в целом согласен, данную проблему может решить простой скрипт и инсталлятор, который не надо прикручивать к SVN, кроме как через скрипт. CruiseControl -- более "промышленное" решение этой проблемы.

[Alfa]

Пара уточнений.

Сборка - процесс осмысленный.

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

В кадом проекте есть а) действия - например, получить код из репозитория, запустить батник, собирающий продукт;

"Получить код из репозитория" не надо относить к действиям. Это скорее триггер "что-то изменилось в репозитории".

А в целом согласен, данную проблему может решить простой скрипт и инсталлятор, который не надо прикручивать к SVN, кроме как через скрипт. CruiseControl -- более "промышленное" решение этой проблемы.

[rlabs]

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

Непрерывные сборки - да. Релизные - автоматические, но с заведомо определенной конфигурацией.

"Получить код из репозитория" не надо относить к действиям. Это скорее триггер "что-то изменилось в репозитории".

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

[Alfa]

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

Я имел ввиду, что в CruiseControl получение кода из SVN это modificationset, а запуск батника это schedule. Если так стало понятней.
То, что вы описали вроде тоже можно сделать, но я не делал.

[Vasiliy]

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

[rlabs]

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

Вообще говоря, для решения исходного вопроса действительно достаточно обычного батника.

Но раз уж затронули тему непрерывной интеграции, то системы типа CruiseControl хороши тем, что практически "из коробки" очень быстро позволяют решить сразу несколько очень важных задач:

• сборка и тестирование в "чистой" среде (первая проверка - собирается ли код где-либо еще, кроме машины разработчика)
• удобная панель управления с хорошим обзором всех проектов
• сама по себе непрерывная интеграция: если сборка делается достаточно быстро, есть шанс узнать о ломающем все сабмите почти сразу же после него
• быстрое автоматическое тестирование: даже базовый набор тестов позволит получать результаты "смок-теста", вообще не напрягаясь
• расширяемая автоматизация: с результатами сборки можно сделать практически все, что угодно - выложить на сайт, отправить почтой, включить сирену (http://www.martinfow...eWhatsHappening)

Ну и так далее. В общем, оно того стоит.

[saezar]

Ок. Понял. Всем биг сенькс.

[Vasiliy]

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

Да, видимо набор функций и требований достаточно стандартен. А вот способы решения различны. :)