Comments 21
UFO just landed and posted this here
Приветствую статьи о CI и о Hudson в частности!
Поэтому, в случае если вам необходимо реализовать свой сценарий сборки, для которого не достаточно набора стандартных плагинов из группы «Сборка», можно пойти тремя путями:Я использую NAnt.
Поэтому «непрерывностью» в моём случае пришлось поступиться и начать запускать тесты не по hook'ам SVN, а по расписанию.Не думаю, что есть смысл запускать сборку после каждого коммита (особенно на начальной стадии проекта). Поэтому потеря не велика. Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).
>Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).
А багтрекер и репозиторий связаны между собой? Некоторые позволяют реализовать малой кровью автоматическое изменение статуса в багтрекере, например с «Assigned» на «Need review», и вставлять ссылку на ревизию в репозитории по коммиту со специального вида сообщением, вроде «Fixed issue #12345». По идее, если вставить в этот же хук вызов сервисов CI, то вручную запускать сборку вам не понадобится. Да и без «умного» багтрекера такую логику реализовать не сложно.
А багтрекер и репозиторий связаны между собой? Некоторые позволяют реализовать малой кровью автоматическое изменение статуса в багтрекере, например с «Assigned» на «Need review», и вставлять ссылку на ревизию в репозитории по коммиту со специального вида сообщением, вроде «Fixed issue #12345». По идее, если вставить в этот же хук вызов сервисов CI, то вручную запускать сборку вам не понадобится. Да и без «умного» багтрекера такую логику реализовать не сложно.
Между собой связаны репозиторий (Subversion) багтрекер (Trac) и сервер интеграции (Hudson).
Но видать или из-за кривых рук или же от не знания профит от этого нулевой.
Связка репозиторий — багтрекер:
— возможность в Trac просматривать содержимое репозитория;
— возможность в Trac просматривать diff'ы.
Связка репозиторий — сервер интеграции:
— возможность в Hudson просматривать события произошедшие в репозитории в рамках build'ов.
Связка багтрекер — сервер интеграции:
— возможность быстрого перехода из сервера ингерации к тикету (если commit'ах в коментарий помещать номер тикета (например: «Fix defect #42.»), то Hudson преобразует их в ссылки и позволяет переходить по ним к тикету в Trac).
Это все те возможности, которыми я сумел овладеть. Буду признателен если, кто-нибудь поделиться опытом и поскажет, какую ещё выгоду можно извлечь от связки указанных инструментов.
Но видать или из-за кривых рук или же от не знания профит от этого нулевой.
Связка репозиторий — багтрекер:
— возможность в Trac просматривать содержимое репозитория;
— возможность в Trac просматривать diff'ы.
Связка репозиторий — сервер интеграции:
— возможность в Hudson просматривать события произошедшие в репозитории в рамках build'ов.
Связка багтрекер — сервер интеграции:
— возможность быстрого перехода из сервера ингерации к тикету (если commit'ах в коментарий помещать номер тикета (например: «Fix defect #42.»), то Hudson преобразует их в ссылки и позволяет переходить по ним к тикету в Trac).
Это все те возможности, которыми я сумел овладеть. Буду признателен если, кто-нибудь поделиться опытом и поскажет, какую ещё выгоду можно извлечь от связки указанных инструментов.
Спасибо за статью. Как раз вовремя, в последнее время работаю над переходом с практически ручного управления проектами на более прогрессивные и автоматизированные методики.
Но вот не понял, в чём основное между билд/деплой сервисом и CI сервисом? Вроде одни и те же функции выполняют, так же могут получать версию из репозитория, собирать её, тестировать и деплоить на разные сервера. Или дело просто в удобстве, т. к. для Ant, Phing или Capistrano, сборка основная функция, а тестирование и деплой кое-как (зачастую через шелл или самописные расширения) пришиты для удобства, а для CI сервера собственно сборка это функция, делегируемая тем пакетам, для которых это основная работа, а работу с репозиториями и деплоем берёт на себя, предоставляя более удобный интерфейс для этого, чем у «конкурентов». Или и работа с репозиториями и деплоем это делегируемые функции, а CI-сервер просто среда для удобного управления сценариями в духе unix-way (каждый делает то, что лучше всего умеет), но с GUI, а не шеловскими скриптами и текстовыми конфигами?
Но вот не понял, в чём основное между билд/деплой сервисом и CI сервисом? Вроде одни и те же функции выполняют, так же могут получать версию из репозитория, собирать её, тестировать и деплоить на разные сервера. Или дело просто в удобстве, т. к. для Ant, Phing или Capistrano, сборка основная функция, а тестирование и деплой кое-как (зачастую через шелл или самописные расширения) пришиты для удобства, а для CI сервера собственно сборка это функция, делегируемая тем пакетам, для которых это основная работа, а работу с репозиториями и деплоем берёт на себя, предоставляя более удобный интерфейс для этого, чем у «конкурентов». Или и работа с репозиториями и деплоем это делегируемые функции, а CI-сервер просто среда для удобного управления сценариями в духе unix-way (каждый делает то, что лучше всего умеет), но с GUI, а не шеловскими скриптами и текстовыми конфигами?
Порадовало то что можно Selenium сервер пинать при помощи Хадсона, на прошлом проекте использовали Хадсон для релиза и деплоя, но что настолько всё можно поставить — не знал. Очень полезно для тех, кто занимается автоматизированием. Главное правильно поставить процесс.
Посоветуйте, пожалуйста, систему непрерывной интеграции под Visual Studio.
Тут скорее надо отталкиваться от системы управления версиями, которая у вас используется.
Если это TFS, то для нее в hudson есть plugin
wiki.hudson-ci.org/display/HUDSON/Team+Foundation+Server+Plugin
Если это Visual Source Safe, аналогично
wiki.hudson-ci.org/display/HUDSON/Visual+SourceSafe+Plugin
Если никакая система управления версиями не используется, то я бы с выбора такой системы и начал. А к hudson можно почти все «прикрутить».
Если это TFS, то для нее в hudson есть plugin
wiki.hudson-ci.org/display/HUDSON/Team+Foundation+Server+Plugin
Если это Visual Source Safe, аналогично
wiki.hudson-ci.org/display/HUDSON/Visual+SourceSafe+Plugin
Если никакая система управления версиями не используется, то я бы с выбора такой системы и начал. А к hudson можно почти все «прикрутить».
Visual Studio — это всего лишь IDE и в процессе непрерывной ингерации роли по большому счету не принимает. Совершенно не важно с помощью какого инструмента вы будете изменять исходные коды. При организации непрерывной интеграции отправной точкой, как уже сказал maxim_ge должна стать система управлениями версиями. А дальше по вкусу…
Мне очень сильно помогло на самом первом этапе для понимания основ вот эта статья: www.developers.org.ua/archives/jony/2009/06/16/dot-net-development-process/
К статье есть много вопросов, но для начала — самое то.
Мне очень сильно помогло на самом первом этапе для понимания основ вот эта статья: www.developers.org.ua/archives/jony/2009/06/16/dot-net-development-process/
К статье есть много вопросов, но для начала — самое то.
+1 конешно, но всеж с IDE системы CI тож можгут интегрится, в TeamCity например есть personal builds и pre-tested commit. Реально удобные штучки.
«Живаго не читал, но осуждаю...» (с)
Уверен, что если возможность интегрирования в IDE реализована, то это полезно и востребовано. Но в то же время хотел бы предостеречь tangro от использования подобных решений. Возможно это излишнее занудство, но сначало нужно понять процесс изнутри, а уже затем использовать инструменты инкапсулирующие его и предоставляющие более удобный интерфейс.
Приведу несколько примеров.
Например некотрые IDE поддерживают интеграцию с VCS и глупо бы было бы не использовать хотя бы время от времени эту возможность. Но познавать VCS по этому плагину — это тернистый путь ведущий в никуда.
Ещё одним примером может стать замечательный инструмен для работами с БД Access. С его помощью можно достаточно быстро создавать простые БД и, что более важно, проектировать отчеты и формы. Опять же таки, было бы глупо, в подходящих случаях не использовать Access. Но изучать основы БД по Access, на мой взгляд, зло. Почитайте вопросы которые задают на форумах новички по Access и, напрмер, по MS SQL Server или MySQL…
Т.о., резюмируя, хочу категорически порекомендовать tangro покинуть уютное окружение любимой IDE и познакомиться с сторонними инструментами и только после получения некоторого опыта инкапсулировать те операции, содержание которых понятно посредством plugin'ов.
chaliy, спасибо за ссылку — расширю кругозор (тем более, что: «TeamCity now supports continuous integration builds on Windows and Unix-based platforms under Mono framework.»).
Уверен, что если возможность интегрирования в IDE реализована, то это полезно и востребовано. Но в то же время хотел бы предостеречь tangro от использования подобных решений. Возможно это излишнее занудство, но сначало нужно понять процесс изнутри, а уже затем использовать инструменты инкапсулирующие его и предоставляющие более удобный интерфейс.
Приведу несколько примеров.
Например некотрые IDE поддерживают интеграцию с VCS и глупо бы было бы не использовать хотя бы время от времени эту возможность. Но познавать VCS по этому плагину — это тернистый путь ведущий в никуда.
Ещё одним примером может стать замечательный инструмен для работами с БД Access. С его помощью можно достаточно быстро создавать простые БД и, что более важно, проектировать отчеты и формы. Опять же таки, было бы глупо, в подходящих случаях не использовать Access. Но изучать основы БД по Access, на мой взгляд, зло. Почитайте вопросы которые задают на форумах новички по Access и, напрмер, по MS SQL Server или MySQL…
Т.о., резюмируя, хочу категорически порекомендовать tangro покинуть уютное окружение любимой IDE и познакомиться с сторонними инструментами и только после получения некоторого опыта инкапсулировать те операции, содержание которых понятно посредством plugin'ов.
chaliy, спасибо за ссылку — расширю кругозор (тем более, что: «TeamCity now supports continuous integration builds on Windows and Unix-based platforms under Mono framework.»).
При программировании на С++ и тем более С# под Windows (чем я занимаюсь) покидать «любимую IDE» просто некуда. Не думайте что я там фанатик и с флагом Майкрософта хожу на барикады, нет. Просто от студии никуда не деться. Пробовал, конечно и Delphi и С++ Builder, регулярно тестирую свежие билды MonoDevelop, экспериментировал с Eclipse, да чего уж там — даже простых текстовых редакторов перебрал десятка два. Ничего и рядом валяющегося с Visual Studio нет (еще раз — под Windows и для С++\C#).
Так что я смирился уж с тем, что при возникновении новой задачи можно поискать соответствующий плагин под студию и в 90% он есть и недорогой (а то и вовсе бесплатный). Думал и в этой сфере что-то есть.
Так что я смирился уж с тем, что при возникновении новой задачи можно поискать соответствующий плагин под студию и в 90% он есть и недорогой (а то и вовсе бесплатный). Думал и в этой сфере что-то есть.
При программировании на С++ и тем более С# под Windows (чем я занимаюсь) покидать «любимую IDE» просто некуда.Возможно я перемудрил с ответами. Просто я хотел обратить внимание на следующие продукты: Subversion, Mercurial, NAnt, NUnit, TeamCity, Cruise Control на Hudson само-собой (может быть вы уже с ними и знакомы). «Покидание IDE» в данном контексте заключается не в переходе на Notepad, а в запуске процесса сборки не из IDE, а из NAnt (bat, ...) или Hudson (TeamCity, ...). Совершенно очевидно, что для того, что бы скрипт запустить, его нужно создать и вот как раз в процессе создания этих скриптов и приходит понимание, что и как нужно делать.
Не думайте что я там фанатик и с флагом Майкрософта хожу на барикады, нет.Что за глупости? Я совершенно не против ни MS ни тем более VS (особенно Express версии), хотя сам в последнее время перешел на Linux и работаю с Mono…
Не очень понял почему в системе непрерывной интеграции самое главное — это система контроля версий. В конце концов checkout кода — единственное, что этой самой системе непрерывной интеграции нужно от системы контроля версий. И не пофигу ли ей делать этот checkot коммандой «svn checkout», «copy» или кликом в GUI? Я просто предположил, что поскольку Visual Studio решает массу задач (а помимо изменения исходных кодов у неё правда еще масса функций) то могут быть и удобные под неё плагины для системы непрерывной интеграции. За статью на developers.org.ua спасибо, несколько разложило по полочкам мысли.
Не являюсь специалистом по вопросам CI, поэтому возможны заблуждения с моей стороны, но тем не менее.
Сначала, вы создаете проект, к нему тесты, создаете репозиторий, для хранения кода, затем скрипт, который выполняет сборку проекта и запускает тесты, а в заключении «цепляете» это скрипт на сервер интеграции.
«Сделать пи… ато» «Build».
Не очень понял почему в системе непрерывной интеграции самое главное — это система контроля версий.Не то что бы главное, скорее базовое — то с чего начинается построение. Я например могу себе представить CI без генерации документации, или без разворачивания приложения, на худой конец, даже без тестирования, но вто без checkout'а — с большим трудом.
Сначала, вы создаете проект, к нему тесты, создаете репозиторий, для хранения кода, затем скрипт, который выполняет сборку проекта и запускает тесты, а в заключении «цепляете» это скрипт на сервер интеграции.
В конце концов checkout кода — единственное, что этой самой системе непрерывной интеграции нужно от системы контроля версий.Пожалуй да.
И не пофигу ли ей делать этот checkot коммандой «svn checkout», «copy» или кликом в GUI?Непрерывная интеграция — процесс автоматический и в процессе сборки «кликов» быть не должно. «Клик» должен быть один —
Я просто предположил, что поскольку Visual Studio решает массу задач (а помимо изменения исходных кодов у неё правда еще масса функций) то могут быть и удобные под неё плагины для системы непрерывной интеграции.По сути вопроса, мне ответить нечего — я не знаю о наличии (равно как и об отстутствии) подобных plugin'ов. Просто не могу не поделиться опытом и не отметить тот факт, что использования plugin'ов без понимания сути больше зло чем добро. Это субьективно и основано исключительно на личном опыте (точнее сказать на личных ошибках). Если вы понимаете чего вы хотите от непрерывной интеграции, то plugin помочь может, а в противном случае, по моему мнению, наврятли. Хотя…
При желании, и наличии некоторого количества времени, можно настроить TFS. Без использования Hudson и ему подобных.
Ещё можно jMeter прикрутить и измерять изменение производительности.
Hudson хорош тем, что позволяет удобно управлять процессами. Имеет огромное количество плагинов.
Но периодически он раздражает мелкими багами, которые могут появиться в новой версии.
И да, создатель Hudson ушел из Sun, форкнул проект и теперь пишет аналог Hudson, называется InfraDNA: infradna.com/
Если нужная более точная подстройка, то можно использовать BuildBot, но нужно знать питон, плюс у него веб-интерфейс довольно убогий.
Если кто знает хорошую альтернативу (не TeamCity или Bamboo, они не лучше Hudson), то порекомендуйте плиз.
Но периодически он раздражает мелкими багами, которые могут появиться в новой версии.
И да, создатель Hudson ушел из Sun, форкнул проект и теперь пишет аналог Hudson, называется InfraDNA: infradna.com/
Если нужная более точная подстройка, то можно использовать BuildBot, но нужно знать питон, плюс у него веб-интерфейс довольно убогий.
Если кто знает хорошую альтернативу (не TeamCity или Bamboo, они не лучше Hudson), то порекомендуйте плиз.
А какая из систем непрерывной интеграции лучшая, Hudson, Buildbot, или что ещё?
Sign up to leave a comment.
Непрерывная интеграция на примере Hudson