Пользователь
0,0
рейтинг
1 февраля 2010 в 18:48

Разработка → Введение в Continuous Integration

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.


Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое. Не найдя отдельных публикаций на Хабре на эту тему, решил восполнить пробел, а заодно и по возможности заработать желанный инвайт.

Continuous Integration, зачем, почему и как?

Continuous Integration, или для краткости CI – это особый принцип разработки программного обеспечения, который может очень сильно упростить вам жизнь. Если на пальцах, то система CI – это некая программа, которая следит за вашим Source Control, и при появлении там изменений автоматически стягивает их, билдит, гоняет тесты (конечно, если их пишут) и возможно делает кое-что ещё. В случае же неудачи она дает об этом знать всем заинтересованным лицам, в первую очередь – последнему коммитеру.

Что нам это дает? Во первых – в любой момент времени мы имеем достоверную информацию о состоянии исходников в системе. Если последний билд был неудачным («упал»), значит брать свежую версию из сорц-контрола нельзя – он может даже не компилится, а если зелёненький, удачный – значит все отлично. Во-вторых – очень просто найти виновника «торжества» — скорее всего, это последний коммитер – он то и будет отвечать за «ремонт». Кстати, в подобной среде задачей высочайшего приоритета является исправление билда.

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

Итак, как готовить?

Систем CI довольно много, на вскидку приходят на ум CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Server, и лично мой любимый – TeamCity, пусть и не OpenSource, но все-же бесплатный для небольших проектов.

Итак, пускай нам необходимо запустить под TeamCity CI для небольшого проекта на .Net (VS2008SP1), который хранится в SVN, и содержит тесты на nUnit. Как вы увидите, для того чтобы сделать такое на TeamCity, нам не придётся написать ни строчки кода/конфига.

Во первых – нам нужен сервер. Да, я знаю, это уже довольно много, но я больше уверен в позитивном результате если пойду к админам и скажу: дайте мне сервер, чем если пойду к админам и скажу: дайте мне, к примеру, решарпер. Итак, припустим что сервер у нас уже есть, можно виртуальный. Устанавливаем на него TeamCity просто кликая next-next-next – установки по дефолту вполне прилична. В дальнейшем большинство установок также можно не трогать – здесь я буду указывать только те, что нужно изменить. Ну и на будущее, скоро пригодится, поставьте также .Net Framework подходящей версии (3.5SP1 в нашем случае) и Windows SDK.

Начинаем: Конфигурация

Итак, в TeamCity по завершении инсталляции создаем новый проект, который фактически просто группа для отдельных билд-конфигураций, и в нем новую конфигурацию, которую я, не мудрствуя лукаво назвал Build.

Ещё одна вещь, которую нуможно указать на этой странице – это путь к бинарникам, поле Artifacts, например вот так: ProjectName\bin\Release\*.*. В общем, артефакты – это те файлы, которые имеют смысл как результаты билда, это могут быть бинарники, логи, результаты анализа, что угодно. Тогда для каждого билда их можно будет аккуратненько скачать из веб-интерфейса.

Кстати… К сожалению стандартные visual studio установочные проекты vdproj не совместимы с msbuild-ом, который внутри делает за нас грязную работу. Поэтому если мы захотим получать в результате build-а готовый msi – придётся немного по-колдовать. Но об этом позже.

Система контроля версий

Жмём Next, и оказываемся на страничке посвящённой системе управления версиями. Во первых, нужно создать корень VCS. Поясню: к примеру вы используете один и тот же сорц-контрол для нескольких проектов, которые лежат в соседних папочках. Тогда нет смысла настраивать для каждого доступ отдельно – просто настраиваем доступ к корню, а в каждой конфигурации просто указываем какая именно часть исходников нам нужна. Итак, Create and attach new VCS root, далее – Type of VCS (у нас Subversion), ну и в зависимости от типа – дальнейшие настройки, для svn хватает соответственно: url, user name и password. Внизу страницы большая группа настроек labeling rules – это на случай если вы захотите делать теги успешных билдов, и кстати уже со старта настроена на стандартную структуру репозитория. Проверяем правильность введённых данных кнопкой Test Connection, сохраняем. Возвратившись на страницу выбора сорц-контрола для нашей конфигурации, на которой вверху появился только-что созданный корень, необходимо добавить Checkout rules. Именно они определяют, какая именно часть репозитория будет билдится. К примеру, если наш проект лежит по адресу svn.company.com/trunk/project то есть смысл установить корень на svn.company.com, а правило задать следующего вида:
+:trunk/project=>.
То-есть: взять то, что находится в SVN по такому-то адресу относительно корня, и вынуть в активную рабочую папку. Все остальные пути, как-то путь к файлу солюшена, пути к артефактам, будут задаваться относительно неё.

Собственно билдим: «раннер»

Все, можно переходить к самой интересной части: к выбору «раннера», то-есть процесса, который будет собственно исполнять билд. TeamCity из коробки поддерживает множество различных раннеров, в том числе и Ant, и Maven, и что для нас более интересно – NAnt, MSBuild и sln200*.

Для начала нам подойдет sln2008. Из параметров достаточно указать путь к файлу солюшена (как уже говорилось – относительно корня, заданного правилом). Далее у нас есть секция с настройками NUnit – здесь достаточно указать версию и путь(и) к dll-файлам с тестами. Все. По сохранении нас не бросит на следующую страницу – это потому, что конфигурация уже создана и пригодна к использованию. Конечно чтобы это все называть Continuous Integration, нам необходимо добавить условие запуска билда – в правой верхней части интерфейса ссылка под номером 4, Build Triggering. Здесь нужно поставить единственную птичку — Enable triggering when files are checked into VCS. Теперь можно переключатся на страницу Projects и жать кнопочку Run в строке Build. Если все сделано правильно (ну и если ваши исходники в порядке) – значок рядом со словом Build позеленеет, а внизу появится число успешно исполненных тестов.

Как развивать?

Да как хотите. Можно включить поиск продублированного кода или FxCop – соответствующие раннеры уже включены в TeamCity. Можно автоматизировать деплоймент – тут уже придётся сложнее.

Конечно, если ваш проект деплоется простым копированием, вы можете создать конфигурацию на основе простого command-line runner, добавить зависимость на артефакты из билда и наслаждаться.

Но что делать если у вас есть, к примеру, сервис или, хуже, база данных?
Виндовс-сервис перед деплойментом нужно остановить, перезаписать и стартануть, базу данных – пересоздать или обновить.

Здесь вам на помощь придёт NAnt или MSBuild. Я писал скрипты и на том и на другом, и мне сложно сказать что у меня есть особые предпочтения. Они довольно одинаковы, у каждого есть плюсы и недостатки. К примеру nant вызывает тот же msbuild для работы с проектами Visual Studio, msbuild по умолчанию ставится вместе с .net framework. Но с другой стороны у nant-а есть довольно большая библиотека дополнений nant-contrib. Вобщем – дело вкуса.

Итак, как добавить такой скрипт в наш проект? Просто добавляем в сорц-контрол, и ставим соответствующий раннер.

Типичный для меня скрипт билда проекта с сайтом, виндовс-сервисом и базой делает следующее: билдит проект, обновляет конфигурации в соответствии с шаблоном, ставит на сайт майнтенанс-мессадж, стопает на дев-сервере сервис, деплоит все на девелоперский сервер x-copy, обновляет базу скриптами из сорц-контрола (если нужно конечно), стартает сервис, убирает майнтенанс-мессадж. Позитив этого скрипта в том, что он без изменений пригоден к деплойменту в живую среду.

Вобщем, это уже тема для другого разговора, продолжу если вам этот пост понравится.

p.s. Я ещё обещал рассказать как билдить vdproj. Правильный ответ – с помощью Visual Studio. Да, она как не прискорбно должна быть установлена на билд-сервере. Сделать это можно к примеру вот-так.

p.p.s Большое спасибо JetBrains за софт.

p.p.p.s. Ещё большее спасибо Мицголу за инвайт.
@professor_k
карма
61,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (65)

  • +11
    Статья хорошая, и, главное, полезная.

    Но описано все немножко сумбурно. Я бы посоветовал описать каждую часть процесса отдельной статьей и описать все очень подробно, уделяя внимание деталям, приводя примеры из конфигов, скриншоты — это здорово помогло бы новичкам. А так по тексту очень много слов и терминов, которые будут непонятны тем, кто «не в теме» :-)
    • +3
      Я не волшебник, я только учусь… Поэтому наверное и получилось несколько сумбурно. В любом случае спасибо. В дальнейшем тему буду развивать, так как она «о наболевшем». В плане ещё как минимум статья о интеграциях БД. Если будет спрос (ваш комент наберет плюсов) — сделаю в «картинках» и примерах.
      Относительно терминов: вводя каждый термин старался давать простое определение, но может где что-то пропустил… Со стороны лучше видно, поэтому: какие именно термины непонятны?
      • +1
        dieron говорит, что по картинке кто «не в теме» сразу поймет куда тыкать, нежели искать текст, про которую вы писали, и еще убедиться, нет ли похожего текста в другом месте
        • 0
          Ну я уже понял свою ошибку) Вот на днях буду поднимать новый проект — сделаю на живом примере в картинках.
  • 0
    Поправьте меня, пожалуйста, если ошибаюсь, но CruiseControl — это, лишь, фронт-энд для Ant'a и ему подобных?
    Честно говоря, использовал только Ant и Maven, а Круиз видел только издалека.
    • 0
      Скорее нет, чем да. Да — потому что позволяет Ant запускать, но в то же время не заменяет его. Нет — потому что (если на пальцах и в двух словах) работает постоянно, в режиме сервиса/демона и следит за изменениями в Source Control. Если есть изменения — запускает Ant (ну или Maven, cmd или что там у вас).
    • 0
      неа, не угадал. Конечно, на анте можно сделать все то, что круиз делает, но гораздо сложнее.
      хотя круиз — редкое говно, лучше TeamCity или Hadson
      • 0
        Hudson
        • 0
          Jenkins :)
          • 0
            Когда тот комент писался, Jenkins'а ещё не было :)
    • 0
      спасибо за пояснения!
  • +1
    JetBrains конечно молодцы, но Hudson по прежнему отличный вариант.
    • 0
      Если писать на яве то teamcity лучше с idea интегрирован
      • 0
        а писать на яве = idea?
        • 0
          >а писать на яве = idea?
          Я где то это говорил?

          Но я считаю что если используется TeamCity и продукт разрабатывается на яве то идея лучший выбор.
          Я сравнивал с eclipse jdt, и netbeans, при наличии достаточно мощного компьютера(критичное условие для разработки крупного проекта в идее) и тот и другой уступают идее.
          • 0
            тут про дотнет, но я всё равно неправ (просто на идею аллергия ;)
          • 0
            Много и долго работал и с idea и с eclipse, eclipse мне больше нравится (естественно, дело вкуса). А CI особо интегрировать с ide не нужно, оно и в сторонке неплохо работает.
            • 0
              Интеграция методологии и иде, на мой взгляд вообще, нетривиальный процесс.

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

    ну и какой же урод хранит бинарники в свн? Senior Programmer говоришь?
    нет на него нашего начальника отдела!!!
    • 0
      Ну зато им удобно клиентам релизы сдавать… Клиенты тоже svn-у обучены. Где свежая версия?.. Да там, в svn возьми.
      Вот сейчас pm-у мозги промыл — помаленько и остальные субпроекты под TeamCity перетаскивает.
      • 0
        А должно быть удобно клиентам. Поднять какую-нибудь groupware не сложно, а клиентам приятно будет. Там помимо релизов еще и новости-доки-баг трекер будут.
  • 0
    А у нас в деревне вместо «ихний» говорят «ихов софт» или «иха программа».

    А еще там, где в тексте есть слова «жмем Некст», обязательно должны быть скриншоты с от руки обведенными красным цветом кнопочками.

    В общем, никакого представления о стиле! ;-)
    • +1
      Простите — язык не родной. Спелл-чекер не обругал…
      • 0
        Не мне вас ругать :-) Это была шутка и ирония одновременно. Спасибо за статью!
      • 0
        а деревня у них, видимо, с Сербскими корнями, т.к. «ньихов софт» это уже по-сербски получается :)
    • 0
      p.s. добавляю ещё +1 к статье «в картинках и примерах»
  • –1
    Статью надо переименовать в «Введение в Continuous Integration для NET» — нет описания как построить CI для любого веб-проекта
    • 0
      Позвольте не согласится. Во первых — не для любого веб-проекта, а вообще практически для любого проекта. Во вторых — пример на .Net, но схема остается та же. У вас проект на джаве с антом? Изменяем раннер, и все остальное справедливо.
      • 0
        тогда я хочу услышать :), что такое CI для проекта написанного на PHP(perl) к примеру, кроме запуска unit тестов и получения последней версии из SVN на stage сервере и как поможет тестеру такая CI?

        по мне так тестеру как раз проще будет получить последнюю версию исходников из SVNa, веб-сервер настроен у него в начале проекта, коннекшин к базе данных указывает на стажеDB и все — обновился и сиди проверяй новую версию

        да в статью наверное стоит добавить подзаголовков
        • 0
          для PHP есть Phing/Xing
        • +1
          К сожалению я не очень в курсе относительно того, как CI реализуют на проектах с интерпретируемыми языками. Как минимум прогонка unit-тестов при каждом коммите — вещь очень позитивная. Ну и наверное какая-нибудь проверка синтаксиса должна быть. Относительно деплоймента на тестовый сервер — не уверен, что это хорошая идея обновлять его по каждому коммиту. У меня на предыдущих проектах к примеру принято было на каждом билде деплоить на сервер разработчиков, деплоймент на тест-сервер совершался асинхронно самим тестером через тот же тимсити.

          Подзаголовков — сейчас перечитаю — добавлю.
          • 0
            положительные чувства испытываешь, когда билдишь что-нибудь компилируемое, тогда видишь, вот текущий exe-ник для тестера, вот инсталлятор, который в любой момент можешь отдать заказчику… а с интерпретируемыми языками эти чувства стираются — компиляция то будет потом, на веб-сервере
          • 0
            Это пока все что вспомнил(zf проект):
            — юнит тесты
            — сниффер кода
            — генерация .mo
            — БД миграции
            — обновление API доков
            — проверка/правка прав на спец папки
            — минимизация js/css

            Деплой на тестовый сервер как раз проходит по каждому коммиту (если все успешно прошло). На продакшен уходит специальная ревизия, ту что в гудзоне пометили (гудзон позволяет такое).
            • +1
              имхо не очень камильфо, если тестуемая версия обновляется без ведома тестера. хотя тестерам виднее.
              • 0
                Что-то в этом есть. Но мы видимо еще не доросли. Тестеров по сути у нас нет, есть человек, который просто проверяет функциональность сайта (не owner, его коллега).
                Но все же. Тот же гудзон предоставляет в виде RSS список билдов. Так что тестер всегда может быть в курсах очередного билда и его состояния. Единственное, в rss не увидишь commit message и список измененных файлов.
  • 0
    Если просто — можно повесить precommit хук для билда, запуска регрессионных тестов и postcommit для всего остального в случае успеха

    Вот еще супер вариант, который можно прикрутить :)
    andialbrecht.wordpress.com/2009/05/09/when-merging-fails/
    • +1
      можно… хотя по-моему не следует смешивать билд-сервер с сорц-контролом. Кроме того, специфический инструмент во многом лучше позволяет наблюдать за процессом. Из плюсов вашего варианта — нерабочий код никогда не попадет в сорц-контрол. С другой стороны тот же TeamCity позволяет гонять персональные билды — и коммитить в случае успеха, что дает схожий результат.
  • 0
    Спасибо за статью. Сами пользуемся TeamCity, раньше был CC.Net — не представляю, как можно жить без них на любом мало-мальски сложном проекте.
  • 0
    Единственное, что для промышленной эксплуатации лучше поднять СУБД на MySQL хотя бы, и смигрировать TeamCity туда.
  • 0
    Вот только сегодня начали внедрять этот подход и бац статья :) Спасибо!
    • 0
      Пожалуйста!
  • +1
    Плохое начало — обосрать собеседника в начале статьи.

    >>Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior
    >>никогда в жизни не стыкались с понятием CI

    У всех есть пробелы в знаниях. Возможно, многие в своей жизни работали на проектах, которые (web) не надо компилировать (половина негодования статьи мимо) или где не требуется постоянное тестирование каждой версии кода, закоммиченой в VCS, например потому, что deploy процессом занимается configuration manager и у него все под контролем.

    Например я бы на вашу статью мог ответить, что это работа именно configuration manager и senior программисты вообще не при чем — их дело разрабатывать.

    Надо понимать что не везде процессы строятся одинаково, потому что требования к процессы тоже разные. Само собой есть общие черты, но даже они везде разные. Статья же претендует на однозначную «панацею» и «так должны делать все», хотя на деле представляет собой противопоставление антипаттернов с нормальными паттернами на отдельно взятом проекте.
    • 0
      Я не пытался никого обидить, и если кто-то принял это на свой счет — прошу прощения.
      А теперь по сути критики. Простите, но я не понимаю, каким образом может корелировать постоянное тестирование с деплойментом. Если у вас на проекте есть тесты — то чем станет хуже если они будут запускатся на каждом коммите, указывая на набор изменений который привел к поломкам? Нет, это не серебрянная пуля. Конечно, требования и процессы разные. И возмножно где-то по процессу даже допустимо бинарники хранить в svn…

      И ещё раз относительно senior-прогамистов. К сожалению (или к счастью) далеко не все мы работаем в огромных компаниях на больших проектах, где есть build engineer или configuration manager. Зачастую спасение утопающих — дело рук самих утопающих. И senior програмист как минимум должен иметь представление о CI на уровне пользователя. Мой к примеру тех-директор не поймет, если я приду к нему и скажу: тестер не получит билдов пока на проекте (из 5 человек) не будет билд-инженера. А коммитить бинарники в svn — простите, религия не позволяет.
      • –2
        >>каким образом может корелировать постоянное тестирование с деплойментом
        Если мне не врут глаза, то слово «деплоймент» встречается у вас в тексте «про постоянное тестирование» 5 раз в разных формах.
        И коррелирует напрямую. Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.

        Под разными процессами я имел в виду не хранение бинарей в СВН, а невозможность или ненужность на фоне других больших проблем применения автобилдов.
        Как вы правильно заметили, не все работают в больших компаниях. Я долго работал в таких, где не то что билд инженера нет, где и тестера то толком нет. Так что снова повторюсь: жизнь и разработка — они такие разные. Не надо пытаться подстроить одну удачную practice, как глобальный шаблон. И тем более считать незнающих ее людей недостойными звания Senior.
        • 0
          >>Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.
          И да, и нет. В статье слово деплоймент упоминается 5 раз — но нигде не написано, что сам по себе деплоймент является целью CI. Тесты же проверяют работоспособность функциональности и отсутствие регресионных багов — независимо, собираетесь вы деплоить именно этот билд, или нет.

          И ещё о Senior-ах. ИМХО, Senior должен также постоянно учится. И если ему представляется случай улучшить качество собственного кода — почему нет? Двое моих друзей, не зарегистрированных пока Хабре, с прочли эту статью, ещё до публикации здесь. Оба синьоры, оба ниразу не работали с CI. Один сказал — интересно, при случае попробую. Второй — купил эту книгу.
  • +4
    Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое.


    Если называть вещи человеческим языком, например «автоматические билды», а не пугать ваших сеньоров баззвордами в индийском стиле, то я думаю удивления будет намного меньше :)
  • 0
    По моему опыту — везде вижу только Хадсон, ничего другого не встречал (9 из 10 компаний в Канаде-штатах, в одной ничего не было).

    Кстати, я бы не согласился с фразой «очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое».

    Программист — это инструмент, который используется для решения определенных задач. В команде обычно несколько инструментов, например: программисты, бизнес-аналисты, тестеры, технические писатели, дизайнеры и т.п. Они много чего могут, но делать должны то, что требуется на проекте. А это решает человек, ответственный за проект, например, Product Manager.

    Пример из жизни. Прошлый проект у меня был — сайт symantec.com. Там по правилам код не должен был содержать ни одного предупреждения (Java), комментироваться должны были все методы, включая private, сеттеры и герреты. А на теперешнем проекте (Clearwire.com) мы ничего этого не делаем, каждый форматирует, как хочет, комментарии — на усмотрение, предупреждений — сотни. Мы не можем сделать лучше? Можем, но Product Manager нам сказал — меня никто не спрашивал про качество кода, поэтому я на это время тратить не буду, делайте, чтобы вам было понятно.

    Так что программисту просто нужно сказать, что билд автоматически запускается после каждого изменения (или по графику), как получишь письмо от хадсона — значит, сломал билд, вот URL, зайди, проверь, что сломал, почини. Все. Знать, как это называется, ему в принципе не обязательно. Полезно, но не обязательно.

    IMHO.
    • 0
      С моей стороны — друге ИМХО: чисто не там где убирают, а где не сорят. Если с самого начала на проекте установлена политика отсутствия предупреждений и отформатированного кода — поддержка не занимает много времени разработчиков. С другой стороны — собственно предупреждения — они ж неспроста… Каждое предупреждение — потенциальная ошибка.
      Я, как ведущий программист на проекте, хочу делать качественный код, независимо от того, что мне сказал Product Manager. Мне неприятно (психологически) работать с кодом, который пестрит предупреждениями и подсказками. Соответственно нужно выбрать здоровый компромис между бюрократией ти качеством.
      • +1
        Это Америка, я не получаю емайлы и звонки в период с часу ночи до пяти утра, хорошо еще что мне платят по часам, так что не задаром не сплю. Для меня это просто очередной проект в очередной фирме, в апреле (надеюсь, что раньше) я вернусь в Канаду и больше никогда про эту контору не услышу.

        Вот к примеру емайл по группе от Product Manager'а:

        • No working remote
        • Health
        › Take care of yourself – manage your health (get lots of sleep, drink plenty of fluids, see the doctor and follow treatment plans
        › Do NOT come back to the office until you are healthy enough to work full days consistently
        • We will schedule to approx 50 hour work weeks. You should plan on a 60 hr work week.
        • Core work hours are 9:00 to 6:00 – not away from the office for more than 60 minutes during core time.
        • Communicate issues immediately, do not wait. EVERY MINUTE COUNTS
        • Blocking issues and broken builds will require you stay until resolved
        • Ensure you fix things locally, BEFORE you deploy, minimize build breakage.
        • Only work on tasks assigned to you in Rally, defer all other requests to management
        • Answer your phone 24/7
        • Plan personal commitments for the weekend
        • Have backup plans for childcare and other family commitments
        • Hourly cap is lifted however we will only pay for the work that you have been directed to complete by one of the execution managers or myself. Over 60 hours needs my email approval

        А на словах добавил — «This is business not personal». Так что я просто не могу себе позволить делать то, что мне комфортно забесплатно. Разработка софта — это бизнес, а раз так, за что заплатили, то и получили. А то, что я хочу, я делаю дома, для своих проектов, где мне никто не указ.

        • 0
          60-часовая рабочая неделя? И что, оно стоит того?
          • 0
            А что делать? Мне платят по часам, так что я просто получаю в полтора раза больше, и это контракт на полгода — когда я его заключал в Ванкувере с работой было не очень, а голод не тетка…

            По-моему на glassdor.com есть история, как девочку в amazon.com перевели на неполный рабочий день (part time), потому что она не могла работать больше 60-ти часов в неделю. Так что у меня еще не худший вариант. Правда, амазон в этом смысле это притча воязыцех, но все же.
  • +2
    Кстати, вот чудесный refcard по теме:
    «Continuous Integration: Patterns and Anti-patterns»
    bit.ly/5kBa1O

    Если лениво регистрироваться, вот сразу PDF:
    narod.ru/disk/17493813000/rc084-010d-continuous-integration_1.pdf.html

    Очень толково, по полочкам, с примерами.
  • 0
    Ну что, это правильный способ зарабатывания инвайтов. От себя добавлю, что для любого мало-мальски серьезного продукта система continuous integration это просто обязательная вещь; особенно это касается тех случаев, когда вы вынуждены поддерживать систему под несколько платформ (например, Linux i386, Linux x86_64 и FreeBSD, не говоря уже про прочие солярки).

    У нас мы используем довольно простую но эффективную многоуровневую систему — сперва делается чекаут, потом выполняется полный билд, потом строится маленький тестовый datapack, прогоняются юниттесты — которые именно на него и рассчитаны, потом строится настоящий большой production datapack, и уже на нем выполняются regression test'ы. Если обваливается один из шагов, дальше идти смысла нет — однако это все происходит независимо для разных платформ, на 6 CI серверах.
  • 0
    Сейчас обкатываем схему JIRA + Bamboo, пока только положительные эмоции. Статья очень обзорная.
    И кстати с Bamboo тоже есть plug-in для IDE
  • 0
    > статический анализ

    М.б. статистический?

    • 0
      все-таки статический.
      • 0
        Хмм :)

        А я думал о всяких LOC и покрытиях, которые у меня в голове в разделее «Статистика».

        Век живи, как грится.
  • 0
    >«Если на пальцах, то система CI – это некая программа!»

    Build Server != CI. Билд-сервер это один из столпов CI, но сам термин CI это именно всего лишь принцип, подход.
    • 0
      Именно так и написано в строке перед тей, которую вы цитируете. Хотя согласен, build server != CI.
      • +1
        Но нельзя сводить в простом объяснении к этому. Так как проблема в том, что суть CI именно в практике, а билд сервер лишь позволяет удобно получать свежие рабочие билды. А всякие FxCop, etc лишь вкусные плюшки от билд-сервера. Они лишь помогают убедиться что билд рабочий и сигнализируют о качестве.

        Было бы наверное неплохо о CI иметь перевод статьи Фаулера: martinfowler.com/articles/continuousIntegration.html
        • 0
          Хм) Фаулера уважаю, хотя этой статьи раньше не видел. Почитаю на досуге, а может даже соберусь с духом и переведу. Хотя переводить с одного иностранного на другой — занятие то ещё…
  • 0
    Друзья, а поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
    • 0
      Довольно просто.
      В TeamCity: Administration->Server Configuration->Issue Tracker->Create new connection, создаем подключение к Jira, указывая теги проектов. Теоретически все, если в коментарии будет упоминатся название бага, TeamCity его отловит.
      Если используется TortoiseSVN можно сделать красивше: в Properties корня репозитория SVN добавляем рекурсивно:

      bugtraq:append = false
      bugtraq:message = Issue: $PROJECTTAG$-%BUGID%
      bugtraq:label = $PROJECTTAG$
      bugtraq:warnifnoissue = true
      bugtraq:url = http://$YOURJIRA$/browse/$PROJECTTAG$-%BUGID%

      Здесь $PROJECTTAG$ — тег вашего проекта, $YOURJIRA$ — соответственно путь к ней.
      Такая настройка будет добавлять в начало лог-сообщения название ишшью, и предупреждать если не введен номер.
      • 0
        Пардон… Ответил, а потом понял что ответил не о том.
        Номер ревизии из SVN можно использовать в качестве номера билда, поставив %system.build.vcs.number.*% вместо Build number format. А вот как сделать чтобы Jira узнавала о биладх — самому интересно.
  • 0
    Открою небольшой секрет, но адаптированный к русскому языку глагол «to start» звучит как «стартовать». В Вашем случае не «стартает», а все-таки «стартует». В остальных случаях – так же.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.