Непрерывная интеграция на примере Hudson

    Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

    Суть CI заключается в постоянной (например, после каждого commit'а) сборке и тестировании разрабатываемого ПО в максимально приближенной к боевой среде с целью как можно более раннего обнаружения ошибок и оповещения о них разработчиков. Сама идея CI принадлежит Martin Fowler, подробно описавшему её в своей статье.

    Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.



    Задача


    И так, допустим у нас есть два проекта: Java-сервис (со своей БД), и PHP-клиент (со своей БД) для него. Оба проекта распространяются в виде deb-пакетов. Необходимо настроить инфраструктуру непрерывной интеграции этих проектов.


    Реализация


    Для того, что бы иметь представление о том, чего же мы хотим в итоге добиться — начнём с конца: рассмотрим схему, которую мы хотим реализовать:



    • рабочая машина программиста — написание кода,
    • сервер SVN — хранение кода,
    • сервер Staging — установка и тестирование собранных проектов,
    • сервер Selenium — тестирование web-интерфейса,
    • сервер Repo — хранение собранных пакетов,
    • сервер CI — соединение всех узлов системы в единое целое.

    Разработчик вносит изменения в проект на своей машине и commit'ит их в SVN. На сервере SVN срабатывает post-commit hook, который инициирует процесс build'а соответствующего проекта на сервере CI. Сервер CI обновляет версию пакета из SVN, компилирует проект, запускает unit-тесты, выкладывает проект на staging-сервер.

    Для проектов без web-интерфейса запускаются интеграционные тесты, для проектов с web-интерфейсом запускаются тесты Selenium. Сервер CI формирует отчёты и при необходимости (в случае провала на любом из этапов сборки проекта) отправляет email-уведомление пользователю.

    Выкладка пакетов проекта в репозитарий для боевых серверов производится разработчиком вручную во время релиза.


    Hudson


    Главным и самым интересным узлом в нашей системе является сервер CI. В данном случае это будет Hudson как одно из самых популярных и распространённых бесплатных решений.
    Первым делом установим его. Hudson доступен в виде пакета, поэтому его установка довольно проста. Кроме того, всю свою конфигурацию Hudson хранит в файлах (/var/lib/hudson), в виду чего не требует интеграции с какой-либо БД.



    Архитектура Hudson'а построена на основе plugin'ов. То есть по сути работа Hudson'а сводится к хранению настроек проектов/плагинов и сборке проекта. В свою очередь сборка проекта заключается в запуске в определённом порядке установленных плагинов, включённых в настройках проекта.
    Плагины можно разделить на несколько условных групп, образующих цикл сборки проекта именуемый также как «pipeline» (настройка плагинов проекта доступна через меню «Настройки проекта»):
    • управление исходным кодом (получение/обновление кода проекта из репозитария),
    • триггеры сборки (настройка времени автозапуска для сборки проекта),
    • среда сборки (настройка среды сборки проекта: версия JVM),
    • сборка (основной этап: запуск плагинов, осуществляющих логику сборки, интеграции и тестирования),
    • послесборочные операции (формирование/публикация отчётов, нотификация).

    К сожалению, Hudson позволяет изменять только порядок выполнения плагинов, входящих в группу «сборка» (порядок выполнения остальных плагинов в рамках своей группы определяется на основе значений аннотации @Execution коде плагинов). Поэтому, в случае если вам необходимо реализовать свой сценарий сборки, для которого не достаточно набора стандартных плагинов из группы «Сборка», можно пойти тремя путями:
    1. вызвать любой внешний исполняемый скрипт, реализующий этот сценарий (пункт ”Execute Shell” из меню ”Add build step”),
    2. подключить плагин системы сборки проекта (Phing, Ant, Maven) и указать необходимую цель,
    3. написать свой плагин.

    По-умолчанию Hudson поставляется с уже установленными плагинами для работы с SVN и Maven. Этого могло бы быть вполне достаточно, если бы речь шла только о Java проектах. Однако допустим, что нам так же необходимо работать с PHP-проектами. В этом случае для сборки проекта логичнее использовать Phing, плагин для которого нужно установить отдельно. Делается это путём перехода в раздел «Настройка / Управление плагинами / Доступные обновления».



    Обратите внимание, что некоторые плагины требуют запуска Hudson под Java 6. Изменить путь к JVM (ровно как и остальные конфигурационные опции) можно в файле /etc/default/hudson. В остальном все конфигурационные параметры касающиеся непосредственно работы Hudson могут быть отредактированы через браузер в web-интерфейсе.

    Относительно настроек плагинов стоит также упомянуть, что плагин имеет как общие настройки («Настройка / Конфигурирование системы»), так и настройки проекта («Настройка / Имя проекта / Настроить проект»).



    Теперь, когда все необходимые плагины установлены, мы можем создать новый проект/задачу, указав его имя и настройки для соответствующих плагинов: URL в репозитарии SVN и команду для сборки.





    Обратите внимание, что вы можете производить сборку не по какому-то расписанию или при опросе репозитария при наличии изменений в проекте, а по коммиту в SVN. Благодаря тому, что Hudson имеет «Remote Access API», позволяющее кроме прочего инициировать сборку проекта, сделав GET-запрос, вы можете легко добавить соответствующий post-commit hook (например, с помощью svnlook) для вашего проекта.

    Рассмотрим этап сборки:



    На данный момент сборка пакета включает в себя получение данных из репозитария и выполнение цели Phing (сборка пакета). В принципе сюда же можно добавить запуск unit-тестов и deploy проекта на staging-сервер. Однако, тут стоит обратить внимание на несколько моментов.

    Во-первых, конфиг для работы приложения на staging-сервере может отличаться от боевого конфига. В этом случае очевидным решением будет хранение в проекте конфига для staging-сервера и подмене им оригинального проекта при сборке (отдельная цель для сборки в случае Phing или профиль для Maven).

    Во-вторых установить пакет на staging-сервер с помощью плагинов SCP и SSH (для работы плагина необходимо убедится, что параметр PasswordAuthentication в конфиге sshd выставлен в yes, а хост staging-сервера добавлен в known-хостов) не получится, так как плагин SSH относится этапу сборки проекта, а plugin SCP — к послесборочным операциям. Поэтому проблему deployment'a проекта на staging-сервер придётся решать с помощью Phing или Maven + AntRun.
    Для того, что бы наш сценарий сборки мог производить действия на удалённых серверах необходимо сгенерировать ssh-ключи: приватный ключ оставить на сервере CI, a публичный раскидать по всем серверам, с которыми будет происходить взаимодействие: staging, repo, svn — добавив их в список известных хостов (known_hosts). Кроме того, для того, что бы Hudson смог установить пакет на удалённом сервере потребуется завести на удалённом сервере соответствующего пользователя (hudson) и дать ему sudo.

    В-третьих, для успешной сборки java-приложений с помощью Maven потребуется определить настройки Maven для пользователя hudson на сервере CI (имеется ввиду каталог ~/.m2).

    Следующим шагом после установки пакета на staging-сервер должен стать запуск интеграционных тестов. Они могут быть запущены на самом сервере CI, однако, предпочтительнее сделать это на staging-сервере. В первом случае всё довольно просто: вызываем соответствующую цель Phing / Maven или настраиваем плагин SeleniumHQ.
    Однако, открытым остаётся вопрос, что же делать, если требуется запустить процесс тестирования на внешнем сервере — например, обратиться к серверу Selenium RC? Ответ тут как нельзя прост: Selenium RC имеет HTTP API для работы с ним, поэтому самым тривиальным решением в данном случае будет написание небольшого скрипта на любом угодном вам языке, который инициирует процесс тестирования и время от времени опрашивает удалённый сервер на предмет завершения теста. Далее этот скрипт подключается к сценарию сборки через плагин ”Execute Shell”. Добавлю ещё, что успех или неуспех работы скрипта определяется Hudson'ом на основе кода возврата вашего скрипта.



    Настроив процесс сборки не забудем о самой важной части процесса — уведомлении разработчика о результатах сборки. Hudson позволяет настроить почтовые уведомления как для конкретных получателей, так и для авторов commit'ов, чьи изменения вызвали поломку.



    В дополнение рекомендую всем, кто будет использовать Hudson для PHP-проектов ознакомиться с соответствующими статьями из Wiki Hudson'а.


    Сервер Staging




    Установка пакетов


    И так, как уже говорилось выше, в нашей инфраструктуре должен присутствовать сервер по конфигурации максимально приближенный к боевому. На этот сервер Hudson будет устанавливать самые свежие пакеты проектов, собранных по trunk'у. Это даст нам возможность:
    1. проводить интеграционное тестирование в условиях максимально приближенных к боевым,
    2. позволит иметь своего рода площадку для демонстрации самой свежей функциональности.

    Одной из основных проблем, которую придётся решить при настройке данного сервера, является «тихая» установка пакетов. Для того, что бы наши пакеты устанавливались без лишних диалогов (то есть могли быть установлены с помощью скриптов или плагинов Hudson'а) необходимо переконфигурировать debconf (dpkg-reconfigure debconf), указав ему уровень важности задаваемых вопросов выше, чем те, что используются в установочных скриптах вашего deb-пакета.



    Кроме того, между устанавливаемыми на staging-сервер пакетами возможны зависимости. Так, например, проект «клиент» зависит от проекта «сервер». В этом случае мы должны явно следить за тем, что бы на staging-сервере при установке пакета «клиент» происходила установка необходимого ему пакета «сервер».

    На первый взгляд очевидным решением, с учётом дистрибуции проекта через deb-пакеты,
    будет управление зависимостями силами dpkg путём добавления в dependencies control-файла пакета «клиент» информации о пакете «сервер».
    В этом случае нам также придётся выделить отдельный debian-репозитарий, в который будут сливаться все собранные сервером CI пакеты, и дополнить сценарий сборки командой копирования пакета в репозитарий. Кроме того, необходимо будет организовать механизм автообновления данных в этом репозитарии при добавлении нового пакета, организовать доступ к пулу репозитария (например, подняв веб-сервер) и добавить данный репозитарий в sources-list на staging-сервере. При организации автообновления вручную (запуском сканера пакетов после выкладки пакета в репозитарий) новый пакет можно будет ставить через apt, в случае если репозитарий будет обновляться по расписанию придётся изобретать фокусы типа dpkg -i package; apt-get -f install. Подробнее о настройке своего debian-репозитария можно почитать тут.

    Однако, данный подход имеет ряд недостатков. Во-первых, зависимости могут быть установлены только на этот же сервер. Во-вторых, такой подход довольно значительно усложняет всю систему в целом, что противоречит принципу KISS (ну или «ЧМОКЕ», если по-русски :D).

    Лучшим решением, на мой взгляд, тут будет использовать репозитарий только для взаимодействия с боевым сервером. При этом выкладка пакетов в репозитарий должна осуществляться не автоматически, а по решению разработчика. Что же касается staging-сервера — на нём будут устанавливаться пакеты из trunk'ов основного пакета и всех его зависимостей, что позволит значительной снизить сложность системы CI, при этом дав нам возможность иметь на staging-сервере последние актуальные версии
    пакетов.


    Работа с БД


    Наши пакеты могут использовать БД. В этом случае БД также устанавливается на staging-сервер, а обновление структуры / данных БД производиться с помощью утилиты dbdeploy.
    Интегрировать dbdeploy в проект двумя путями:
    1. под каждую БД выделяется отдельный проект в SVN и как следствие — в Hudson, со своим сценарием сборки, инициируемым по hook'у SVN (вариант имеет смысл, когда БД используется несколькими проектами),
    2. структура файлов dbdeploy становиться частью основного проекта, а вызов скрипта актуализации версии БД dbdeploy происходит в postinst-скрипте пакета.


    Отдельно в данном случае встаёт вопрос об изменениях данных БД в ходе тестирования. Понятно, при написании модульных тестов мы не работаем с БД, а используем mock-объекты (мне, например, нравится Mockito).
    Однако, как быть с интеграционными тестами, которым просто необходимо работать в «реальных» условиях? В случае XUnit-тестов мы можем выполнять каждый тест в рамках транзакции к БД. Такой подход на мой взгляд является более предпочтительным, так как с учётом версионирования БД через dbdeploy мы всегда знаем, какие данные у нас есть в БД на текущий момент и можем смело привязываться к ним в наших тестах. Однако, в случае тестирования web-интерфейса (например, с помощью Selenium) у нас нет возможности запускать каждый тест в рамках транзакции.
    Поэтому вариантов тут на мой взгляд остаётся два: либо перед запуском тестирования web-интерфейса полностью переинициализировать данные в БД на основе имеющихся
    патчей, либо строить тесты так, что бы они не привязывались к каким-то конкретным данным из БД (например, создавали необходимые для тестирования данные через web-интерфейс сами) и по возможности не оставляли после себя «мусора».


    Cервер Selenium


    В случае, когда приложение не имеет web-интерфейса, интеграционный тест на staging-сервере, как я уже писал выше, вполне может заключаться в запуске XUnit-тестов. Однако, при наличии пользовательского интерфейса крайне удобно провести полное тестирование всей цепочки от HTML до БД с помощью Selenuim'a.

    Selenium — это мощная система тестирования web-приложений, которую условно можно разделить на две части:
    • Selenuim IDE — инструмент для разработки и запусков сценариев тестирования в браузере (доступно в виде plugin'a firefox),
    • Selenium RC — распределённая система из сервера Selenium и подчинённых ему клиентов, на которых запускаются тесты под разными браузерами.

    По понятным причинам, нас интересует второй вариант. По скольку установка и настройка Selenuim'а — довольна большая тема, касаться её в этой статье я смысла не вижу: вся информация есть в документации.


    Замечания


    Стоит заметить, что CI можно проводить и в ручном режиме, каждый раз компилируя и тестируя код перед commit'ом. Однако, автоматизация данного процесса с помощью сервера CI на много целесообразней. Кроме того важно понимать, что CI и ночные сборки (nightly builds) — не одно и тоже. Последние позволяют выявить баги, но с большим запозданием, в то время как цель CI — скорейшее обнаружение ошибок. На мой взгляд ночные сборки могут послужить частичной заменой CI только в том, случае когда сборка и тестирование проекта — процесс, занимающей довольное большое количество времени. Кроме того, если в проекте есть как unit, так и интеграционные тесты, можно разбить сборку проекта на две части: первая (с unit-тестами) запускается каждый раз при commit'e, вторая с интеграционными тестами — раз в час/сутки.


    Вывод


    Описанное выше решение работает и приносит профит. Однако, как мы все знаем, теория, к сожалению, далеко не всегда соответствует практике. Внедрение системы CI потребовало решения ряда проблем, не все из которых были решены идеально.

    Вероятность того, что для staging-сервера кто-то даст вам ресурсы, сравнимые про характеристикам с боевыми, крайне мала — скорее всего это будет средней мощности виртуальник на полузаброшенной хост-машине, что в корне подрывает один из принципов CI — тестирование в схожем окружении. Это в свою очередь влечёт за собой то, что интеграционные тесты, могут начать занимать гораздо большее время, чем планировалось изначально. Поэтому «непрерывностью» в моём случае пришлось поступиться и начать запускать тесты не по hook'ам SVN, а по расписанию.

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

    Ну и наверное самое главное: как показала практика, интеграция системы CI — задача командная. Для её решения потребуется работа разработчиков, тестировщиков и администраторов.
    Share post

    Comments 21

      +1
      Стоит добавить, что в более простых случаях можно обойтись тем, что maven запускает unit-test'ы при сборке.
        0
        Приветствую статьи о CI и о Hudson в частности!

        Поэтому, в случае если вам необходимо реализовать свой сценарий сборки, для которого не достаточно набора стандартных плагинов из группы «Сборка», можно пойти тремя путями:
        Я использую NAnt.

        Поэтому «непрерывностью» в моём случае пришлось поступиться и начать запускать тесты не по hook'ам SVN, а по расписанию.
        Не думаю, что есть смысл запускать сборку после каждого коммита (особенно на начальной стадии проекта). Поэтому потеря не велика. Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).
          0
          >Я тоже сначала ставил hook на коммит, но потом отказался от этой идеи и начал запускать сборку «в ручную» по факту закрытия тикета в багтрэкере (а у меня это не всегда один коммит).

          А багтрекер и репозиторий связаны между собой? Некоторые позволяют реализовать малой кровью автоматическое изменение статуса в багтрекере, например с «Assigned» на «Need review», и вставлять ссылку на ревизию в репозитории по коммиту со специального вида сообщением, вроде «Fixed issue #12345». По идее, если вставить в этот же хук вызов сервисов CI, то вручную запускать сборку вам не понадобится. Да и без «умного» багтрекера такую логику реализовать не сложно.
            0
            Между собой связаны репозиторий (Subversion) багтрекер (Trac) и сервер интеграции (Hudson).
            Но видать или из-за кривых рук или же от не знания профит от этого нулевой.

            Связка репозиторий — багтрекер:
            — возможность в Trac просматривать содержимое репозитория;
            — возможность в Trac просматривать diff'ы.

            Связка репозиторий — сервер интеграции:
            — возможность в Hudson просматривать события произошедшие в репозитории в рамках build'ов.

            Связка багтрекер — сервер интеграции:
            — возможность быстрого перехода из сервера ингерации к тикету (если commit'ах в коментарий помещать номер тикета (например: «Fix defect #42.»), то Hudson преобразует их в ссылки и позволяет переходить по ним к тикету в Trac).

            Это все те возможности, которыми я сумел овладеть. Буду признателен если, кто-нибудь поделиться опытом и поскажет, какую ещё выгоду можно извлечь от связки указанных инструментов.
          +1
          Спасибо за статью. Как раз вовремя, в последнее время работаю над переходом с практически ручного управления проектами на более прогрессивные и автоматизированные методики.

          Но вот не понял, в чём основное между билд/деплой сервисом и CI сервисом? Вроде одни и те же функции выполняют, так же могут получать версию из репозитория, собирать её, тестировать и деплоить на разные сервера. Или дело просто в удобстве, т. к. для Ant, Phing или Capistrano, сборка основная функция, а тестирование и деплой кое-как (зачастую через шелл или самописные расширения) пришиты для удобства, а для CI сервера собственно сборка это функция, делегируемая тем пакетам, для которых это основная работа, а работу с репозиториями и деплоем берёт на себя, предоставляя более удобный интерфейс для этого, чем у «конкурентов». Или и работа с репозиториями и деплоем это делегируемые функции, а CI-сервер просто среда для удобного управления сценариями в духе unix-way (каждый делает то, что лучше всего умеет), но с GUI, а не шеловскими скриптами и текстовыми конфигами?

            +1
            Порадовало то что можно Selenium сервер пинать при помощи Хадсона, на прошлом проекте использовали Хадсон для релиза и деплоя, но что настолько всё можно поставить — не знал. Очень полезно для тех, кто занимается автоматизированием. Главное правильно поставить процесс.
              0
              Посоветуйте, пожалуйста, систему непрерывной интеграции под Visual Studio.
                +1
                Тут скорее надо отталкиваться от системы управления версиями, которая у вас используется.

                Если это 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 можно почти все «прикрутить».
                  +1
                  Visual Studio — это всего лишь IDE и в процессе непрерывной ингерации роли по большому счету не принимает. Совершенно не важно с помощью какого инструмента вы будете изменять исходные коды. При организации непрерывной интеграции отправной точкой, как уже сказал maxim_ge должна стать система управлениями версиями. А дальше по вкусу…

                  Мне очень сильно помогло на самом первом этапе для понимания основ вот эта статья: www.developers.org.ua/archives/jony/2009/06/16/dot-net-development-process/
                  К статье есть много вопросов, но для начала — самое то.
                    +1
                    +1 конешно, но всеж с IDE системы CI тож можгут интегрится, в TeamCity например есть personal builds и pre-tested commit. Реально удобные штучки.

                      +1
                      «Живаго не читал, но осуждаю...» (с)

                      Уверен, что если возможность интегрирования в 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.»).
                        +1
                        При программировании на С++ и тем более С# под Windows (чем я занимаюсь) покидать «любимую IDE» просто некуда. Не думайте что я там фанатик и с флагом Майкрософта хожу на барикады, нет. Просто от студии никуда не деться. Пробовал, конечно и Delphi и С++ Builder, регулярно тестирую свежие билды MonoDevelop, экспериментировал с Eclipse, да чего уж там — даже простых текстовых редакторов перебрал десятка два. Ничего и рядом валяющегося с Visual Studio нет (еще раз — под Windows и для С++\C#).

                        Так что я смирился уж с тем, что при возникновении новой задачи можно поискать соответствующий плагин под студию и в 90% он есть и недорогой (а то и вовсе бесплатный). Думал и в этой сфере что-то есть.
                          0
                          При программировании на С++ и тем более С# под Windows (чем я занимаюсь) покидать «любимую IDE» просто некуда.
                          Возможно я перемудрил с ответами. Просто я хотел обратить внимание на следующие продукты: Subversion, Mercurial, NAnt, NUnit, TeamCity, Cruise Control на Hudson само-собой (может быть вы уже с ними и знакомы). «Покидание IDE» в данном контексте заключается не в переходе на Notepad, а в запуске процесса сборки не из IDE, а из NAnt (bat, ...) или Hudson (TeamCity, ...). Совершенно очевидно, что для того, что бы скрипт запустить, его нужно создать и вот как раз в процессе создания этих скриптов и приходит понимание, что и как нужно делать.
                          Не думайте что я там фанатик и с флагом Майкрософта хожу на барикады, нет.
                          Что за глупости? Я совершенно не против ни MS ни тем более VS (особенно Express версии), хотя сам в последнее время перешел на Linux и работаю с Mono…
                      0
                      Не очень понял почему в системе непрерывной интеграции самое главное — это система контроля версий. В конце концов checkout кода — единственное, что этой самой системе непрерывной интеграции нужно от системы контроля версий. И не пофигу ли ей делать этот checkot коммандой «svn checkout», «copy» или кликом в GUI? Я просто предположил, что поскольку Visual Studio решает массу задач (а помимо изменения исходных кодов у неё правда еще масса функций) то могут быть и удобные под неё плагины для системы непрерывной интеграции. За статью на developers.org.ua спасибо, несколько разложило по полочкам мысли.
                        0
                        Не являюсь специалистом по вопросам CI, поэтому возможны заблуждения с моей стороны, но тем не менее.
                        Не очень понял почему в системе непрерывной интеграции самое главное — это система контроля версий.
                        Не то что бы главное, скорее базовое — то с чего начинается построение. Я например могу себе представить CI без генерации документации, или без разворачивания приложения, на худой конец, даже без тестирования, но вто без checkout'а — с большим трудом.
                        Сначала, вы создаете проект, к нему тесты, создаете репозиторий, для хранения кода, затем скрипт, который выполняет сборку проекта и запускает тесты, а в заключении «цепляете» это скрипт на сервер интеграции.
                        В конце концов checkout кода — единственное, что этой самой системе непрерывной интеграции нужно от системы контроля версий.
                        Пожалуй да.
                        И не пофигу ли ей делать этот checkot коммандой «svn checkout», «copy» или кликом в GUI?
                        Непрерывная интеграция — процесс автоматический и в процессе сборки «кликов» быть не должно. «Клик» должен быть один — «Сделать пи… ато» «Build».
                        Я просто предположил, что поскольку Visual Studio решает массу задач (а помимо изменения исходных кодов у неё правда еще масса функций) то могут быть и удобные под неё плагины для системы непрерывной интеграции.
                        По сути вопроса, мне ответить нечего — я не знаю о наличии (равно как и об отстутствии) подобных plugin'ов. Просто не могу не поделиться опытом и не отметить тот факт, что использования plugin'ов без понимания сути больше зло чем добро. Это субьективно и основано исключительно на личном опыте (точнее сказать на личных ошибках). Если вы понимаете чего вы хотите от непрерывной интеграции, то plugin помочь может, а в противном случае, по моему мнению, наврятли. Хотя…
                      0
                      При желании, и наличии некоторого количества времени, можно настроить TFS. Без использования Hudson и ему подобных.
                      0
                      Ещё можно jMeter прикрутить и измерять изменение производительности.
                        +1
                        Hudson хорош тем, что позволяет удобно управлять процессами. Имеет огромное количество плагинов.
                        Но периодически он раздражает мелкими багами, которые могут появиться в новой версии.
                        И да, создатель Hudson ушел из Sun, форкнул проект и теперь пишет аналог Hudson, называется InfraDNA: infradna.com/
                        Если нужная более точная подстройка, то можно использовать BuildBot, но нужно знать питон, плюс у него веб-интерфейс довольно убогий.
                        Если кто знает хорошую альтернативу (не TeamCity или Bamboo, они не лучше Hudson), то порекомендуйте плиз.

                          0
                          не TeamCity или Bamboo, они не лучше Hudson
                          Без холиваров, чем TeamCity не лучше Hudson?
                          И да, создатель Hudson ушел из Sun, форкнул проект и теперь пишет аналог Hudson, называется InfraDNA
                          Интересно, надо бы «поковырять» на досуге…
                            0
                            вообще TeamCity, наверное, более стабильный продукт плюс у него насколько я знаю более тесная интеграция со средствами разработки, но у него меньше плагинов, плюс он платный для более чем 10 проектов. По фичам оба примерно одинаковы.
                          0
                          А какая из систем непрерывной интеграции лучшая, Hudson, Buildbot, или что ещё?

                          Only users with full accounts can post comments. Log in, please.