Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Статья хорошая, и, главное, полезная.
Но описано все немножко сумбурно. Я бы посоветовал описать каждую часть процесса отдельной статьей и описать все очень подробно, уделяя внимание деталям, приводя примеры из конфигов, скриншоты — это здорово помогло бы новичкам. А так по тексту очень много слов и терминов, которые будут непонятны тем, кто «не в теме» :-)
Но описано все немножко сумбурно. Я бы посоветовал описать каждую часть процесса отдельной статьей и описать все очень подробно, уделяя внимание деталям, приводя примеры из конфигов, скриншоты — это здорово помогло бы новичкам. А так по тексту очень много слов и терминов, которые будут непонятны тем, кто «не в теме» :-)
Я не волшебник, я только учусь… Поэтому наверное и получилось несколько сумбурно. В любом случае спасибо. В дальнейшем тему буду развивать, так как она «о наболевшем». В плане ещё как минимум статья о интеграциях БД. Если будет спрос (ваш комент наберет плюсов) — сделаю в «картинках» и примерах.
Относительно терминов: вводя каждый термин старался давать простое определение, но может где что-то пропустил… Со стороны лучше видно, поэтому: какие именно термины непонятны?
Относительно терминов: вводя каждый термин старался давать простое определение, но может где что-то пропустил… Со стороны лучше видно, поэтому: какие именно термины непонятны?
Поправьте меня, пожалуйста, если ошибаюсь, но CruiseControl — это, лишь, фронт-энд для Ant'a и ему подобных?
Честно говоря, использовал только Ant и Maven, а Круиз видел только издалека.
Честно говоря, использовал только Ant и Maven, а Круиз видел только издалека.
Скорее нет, чем да. Да — потому что позволяет Ant запускать, но в то же время не заменяет его. Нет — потому что (если на пальцах и в двух словах) работает постоянно, в режиме сервиса/демона и следит за изменениями в Source Control. Если есть изменения — запускает Ant (ну или Maven, cmd или что там у вас).
неа, не угадал. Конечно, на анте можно сделать все то, что круиз делает, но гораздо сложнее.
хотя круиз — редкое говно, лучше TeamCity или Hadson
хотя круиз — редкое говно, лучше TeamCity или Hadson
спасибо за пояснения!
JetBrains конечно молодцы, но Hudson по прежнему отличный вариант.
Если писать на яве то teamcity лучше с idea интегрирован
а писать на яве = idea?
>а писать на яве = idea?
Я где то это говорил?
Но я считаю что если используется TeamCity и продукт разрабатывается на яве то идея лучший выбор.
Я сравнивал с eclipse jdt, и netbeans, при наличии достаточно мощного компьютера(критичное условие для разработки крупного проекта в идее) и тот и другой уступают идее.
Я где то это говорил?
Но я считаю что если используется TeamCity и продукт разрабатывается на яве то идея лучший выбор.
Я сравнивал с eclipse jdt, и netbeans, при наличии достаточно мощного компьютера(критичное условие для разработки крупного проекта в идее) и тот и другой уступают идее.
тут про дотнет, но я всё равно неправ (просто на идею аллергия ;)
Много и долго работал и с idea и с eclipse, eclipse мне больше нравится (естественно, дело вкуса). А CI особо интегрировать с ide не нужно, оно и в сторонке неплохо работает.
Интеграция методологии и иде, на мой взгляд вообще, нетривиальный процесс.
Но тесная интеграция с билдсервером позволяет иметь ряд очень удобных фишек к примеру переход непосредственно к месту падения сборки (по бектрейсу из лога), мгновенное принятие ответственности, я уж не говорю о личных сборках.
Но тесная интеграция с билдсервером позволяет иметь ряд очень удобных фишек к примеру переход непосредственно к месту падения сборки (по бектрейсу из лога), мгновенное принятие ответственности, я уж не говорю о личных сборках.
позновательно,
может в скором и перейдем на одну из систем CI
ну и какой же урод хранит бинарники в свн? Senior Programmer говоришь?
нет на него нашего начальника отдела!!!
может в скором и перейдем на одну из систем CI
ну и какой же урод хранит бинарники в свн? Senior Programmer говоришь?
нет на него нашего начальника отдела!!!
А у нас в деревне вместо «ихний» говорят «ихов софт» или «иха программа».
А еще там, где в тексте есть слова «жмем Некст», обязательно должны быть скриншоты с от руки обведенными красным цветом кнопочками.
В общем, никакого представления о стиле! ;-)
А еще там, где в тексте есть слова «жмем Некст», обязательно должны быть скриншоты с от руки обведенными красным цветом кнопочками.
В общем, никакого представления о стиле! ;-)
Статью надо переименовать в «Введение в Continuous Integration для NET» — нет описания как построить CI для любого веб-проекта
Позвольте не согласится. Во первых — не для любого веб-проекта, а вообще практически для любого проекта. Во вторых — пример на .Net, но схема остается та же. У вас проект на джаве с антом? Изменяем раннер, и все остальное справедливо.
тогда я хочу услышать :), что такое CI для проекта написанного на PHP(perl) к примеру, кроме запуска unit тестов и получения последней версии из SVN на stage сервере и как поможет тестеру такая CI?
по мне так тестеру как раз проще будет получить последнюю версию исходников из SVNa, веб-сервер настроен у него в начале проекта, коннекшин к базе данных указывает на стажеDB и все — обновился и сиди проверяй новую версию
да в статью наверное стоит добавить подзаголовков
по мне так тестеру как раз проще будет получить последнюю версию исходников из SVNa, веб-сервер настроен у него в начале проекта, коннекшин к базе данных указывает на стажеDB и все — обновился и сиди проверяй новую версию
да в статью наверное стоит добавить подзаголовков
для PHP есть Phing/Xing
К сожалению я не очень в курсе относительно того, как CI реализуют на проектах с интерпретируемыми языками. Как минимум прогонка unit-тестов при каждом коммите — вещь очень позитивная. Ну и наверное какая-нибудь проверка синтаксиса должна быть. Относительно деплоймента на тестовый сервер — не уверен, что это хорошая идея обновлять его по каждому коммиту. У меня на предыдущих проектах к примеру принято было на каждом билде деплоить на сервер разработчиков, деплоймент на тест-сервер совершался асинхронно самим тестером через тот же тимсити.
Подзаголовков — сейчас перечитаю — добавлю.
Подзаголовков — сейчас перечитаю — добавлю.
положительные чувства испытываешь, когда билдишь что-нибудь компилируемое, тогда видишь, вот текущий exe-ник для тестера, вот инсталлятор, который в любой момент можешь отдать заказчику… а с интерпретируемыми языками эти чувства стираются — компиляция то будет потом, на веб-сервере
Это пока все что вспомнил(zf проект):
— юнит тесты
— сниффер кода
— генерация .mo
— БД миграции
— обновление API доков
— проверка/правка прав на спец папки
— минимизация js/css
Деплой на тестовый сервер как раз проходит по каждому коммиту (если все успешно прошло). На продакшен уходит специальная ревизия, ту что в гудзоне пометили (гудзон позволяет такое).
— юнит тесты
— сниффер кода
— генерация .mo
— БД миграции
— обновление API доков
— проверка/правка прав на спец папки
— минимизация js/css
Деплой на тестовый сервер как раз проходит по каждому коммиту (если все успешно прошло). На продакшен уходит специальная ревизия, ту что в гудзоне пометили (гудзон позволяет такое).
имхо не очень камильфо, если тестуемая версия обновляется без ведома тестера. хотя тестерам виднее.
Что-то в этом есть. Но мы видимо еще не доросли. Тестеров по сути у нас нет, есть человек, который просто проверяет функциональность сайта (не owner, его коллега).
Но все же. Тот же гудзон предоставляет в виде RSS список билдов. Так что тестер всегда может быть в курсах очередного билда и его состояния. Единственное, в rss не увидишь commit message и список измененных файлов.
Но все же. Тот же гудзон предоставляет в виде RSS список билдов. Так что тестер всегда может быть в курсах очередного билда и его состояния. Единственное, в rss не увидишь commit message и список измененных файлов.
Если просто — можно повесить precommit хук для билда, запуска регрессионных тестов и postcommit для всего остального в случае успеха
Вот еще супер вариант, который можно прикрутить :)
andialbrecht.wordpress.com/2009/05/09/when-merging-fails/
Вот еще супер вариант, который можно прикрутить :)
andialbrecht.wordpress.com/2009/05/09/when-merging-fails/
можно… хотя по-моему не следует смешивать билд-сервер с сорц-контролом. Кроме того, специфический инструмент во многом лучше позволяет наблюдать за процессом. Из плюсов вашего варианта — нерабочий код никогда не попадет в сорц-контрол. С другой стороны тот же TeamCity позволяет гонять персональные билды — и коммитить в случае успеха, что дает схожий результат.
Спасибо за статью. Сами пользуемся TeamCity, раньше был CC.Net — не представляю, как можно жить без них на любом мало-мальски сложном проекте.
Единственное, что для промышленной эксплуатации лучше поднять СУБД на MySQL хотя бы, и смигрировать TeamCity туда.
Вот только сегодня начали внедрять этот подход и бац статья :) Спасибо!
Плохое начало — обосрать собеседника в начале статьи.
>>Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior
>>никогда в жизни не стыкались с понятием CI
У всех есть пробелы в знаниях. Возможно, многие в своей жизни работали на проектах, которые (web) не надо компилировать (половина негодования статьи мимо) или где не требуется постоянное тестирование каждой версии кода, закоммиченой в VCS, например потому, что deploy процессом занимается configuration manager и у него все под контролем.
Например я бы на вашу статью мог ответить, что это работа именно configuration manager и senior программисты вообще не при чем — их дело разрабатывать.
Надо понимать что не везде процессы строятся одинаково, потому что требования к процессы тоже разные. Само собой есть общие черты, но даже они везде разные. Статья же претендует на однозначную «панацею» и «так должны делать все», хотя на деле представляет собой противопоставление антипаттернов с нормальными паттернами на отдельно взятом проекте.
>>Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior
>>никогда в жизни не стыкались с понятием CI
У всех есть пробелы в знаниях. Возможно, многие в своей жизни работали на проектах, которые (web) не надо компилировать (половина негодования статьи мимо) или где не требуется постоянное тестирование каждой версии кода, закоммиченой в VCS, например потому, что deploy процессом занимается configuration manager и у него все под контролем.
Например я бы на вашу статью мог ответить, что это работа именно configuration manager и senior программисты вообще не при чем — их дело разрабатывать.
Надо понимать что не везде процессы строятся одинаково, потому что требования к процессы тоже разные. Само собой есть общие черты, но даже они везде разные. Статья же претендует на однозначную «панацею» и «так должны делать все», хотя на деле представляет собой противопоставление антипаттернов с нормальными паттернами на отдельно взятом проекте.
Я не пытался никого обидить, и если кто-то принял это на свой счет — прошу прощения.
А теперь по сути критики. Простите, но я не понимаю, каким образом может корелировать постоянное тестирование с деплойментом. Если у вас на проекте есть тесты — то чем станет хуже если они будут запускатся на каждом коммите, указывая на набор изменений который привел к поломкам? Нет, это не серебрянная пуля. Конечно, требования и процессы разные. И возмножно где-то по процессу даже допустимо бинарники хранить в svn…
И ещё раз относительно senior-прогамистов. К сожалению (или к счастью) далеко не все мы работаем в огромных компаниях на больших проектах, где есть build engineer или configuration manager. Зачастую спасение утопающих — дело рук самих утопающих. И senior програмист как минимум должен иметь представление о CI на уровне пользователя. Мой к примеру тех-директор не поймет, если я приду к нему и скажу: тестер не получит билдов пока на проекте (из 5 человек) не будет билд-инженера. А коммитить бинарники в svn — простите, религия не позволяет.
А теперь по сути критики. Простите, но я не понимаю, каким образом может корелировать постоянное тестирование с деплойментом. Если у вас на проекте есть тесты — то чем станет хуже если они будут запускатся на каждом коммите, указывая на набор изменений который привел к поломкам? Нет, это не серебрянная пуля. Конечно, требования и процессы разные. И возмножно где-то по процессу даже допустимо бинарники хранить в svn…
И ещё раз относительно senior-прогамистов. К сожалению (или к счастью) далеко не все мы работаем в огромных компаниях на больших проектах, где есть build engineer или configuration manager. Зачастую спасение утопающих — дело рук самих утопающих. И senior програмист как минимум должен иметь представление о CI на уровне пользователя. Мой к примеру тех-директор не поймет, если я приду к нему и скажу: тестер не получит билдов пока на проекте (из 5 человек) не будет билд-инженера. А коммитить бинарники в svn — простите, религия не позволяет.
>>каким образом может корелировать постоянное тестирование с деплойментом
Если мне не врут глаза, то слово «деплоймент» встречается у вас в тексте «про постоянное тестирование» 5 раз в разных формах.
И коррелирует напрямую. Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.
Под разными процессами я имел в виду не хранение бинарей в СВН, а невозможность или ненужность на фоне других больших проблем применения автобилдов.
Как вы правильно заметили, не все работают в больших компаниях. Я долго работал в таких, где не то что билд инженера нет, где и тестера то толком нет. Так что снова повторюсь: жизнь и разработка — они такие разные. Не надо пытаться подстроить одну удачную practice, как глобальный шаблон. И тем более считать незнающих ее людей недостойными звания Senior.
Если мне не врут глаза, то слово «деплоймент» встречается у вас в тексте «про постоянное тестирование» 5 раз в разных формах.
И коррелирует напрямую. Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.
Под разными процессами я имел в виду не хранение бинарей в СВН, а невозможность или ненужность на фоне других больших проблем применения автобилдов.
Как вы правильно заметили, не все работают в больших компаниях. Я долго работал в таких, где не то что билд инженера нет, где и тестера то толком нет. Так что снова повторюсь: жизнь и разработка — они такие разные. Не надо пытаться подстроить одну удачную practice, как глобальный шаблон. И тем более считать незнающих ее людей недостойными звания Senior.
>>Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.
И да, и нет. В статье слово деплоймент упоминается 5 раз — но нигде не написано, что сам по себе деплоймент является целью CI. Тесты же проверяют работоспособность функциональности и отсутствие регресионных багов — независимо, собираетесь вы деплоить именно этот билд, или нет.
И ещё о Senior-ах. ИМХО, Senior должен также постоянно учится. И если ему представляется случай улучшить качество собственного кода — почему нет? Двое моих друзей, не зарегистрированных пока Хабре, с прочли эту статью, ещё до публикации здесь. Оба синьоры, оба ниразу не работали с CI. Один сказал — интересно, при случае попробую. Второй — купил эту книгу.
И да, и нет. В статье слово деплоймент упоминается 5 раз — но нигде не написано, что сам по себе деплоймент является целью CI. Тесты же проверяют работоспособность функциональности и отсутствие регресионных багов — независимо, собираетесь вы деплоить именно этот билд, или нет.
И ещё о Senior-ах. ИМХО, Senior должен также постоянно учится. И если ему представляется случай улучшить качество собственного кода — почему нет? Двое моих друзей, не зарегистрированных пока Хабре, с прочли эту статью, ещё до публикации здесь. Оба синьоры, оба ниразу не работали с CI. Один сказал — интересно, при случае попробую. Второй — купил эту книгу.
Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое.
Если называть вещи человеческим языком, например «автоматические билды», а не пугать ваших сеньоров баззвордами в индийском стиле, то я думаю удивления будет намного меньше :)
По моему опыту — везде вижу только Хадсон, ничего другого не встречал (9 из 10 компаний в Канаде-штатах, в одной ничего не было).
Кстати, я бы не согласился с фразой «очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое».
Программист — это инструмент, который используется для решения определенных задач. В команде обычно несколько инструментов, например: программисты, бизнес-аналисты, тестеры, технические писатели, дизайнеры и т.п. Они много чего могут, но делать должны то, что требуется на проекте. А это решает человек, ответственный за проект, например, Product Manager.
Пример из жизни. Прошлый проект у меня был — сайт symantec.com. Там по правилам код не должен был содержать ни одного предупреждения (Java), комментироваться должны были все методы, включая private, сеттеры и герреты. А на теперешнем проекте (Clearwire.com) мы ничего этого не делаем, каждый форматирует, как хочет, комментарии — на усмотрение, предупреждений — сотни. Мы не можем сделать лучше? Можем, но Product Manager нам сказал — меня никто не спрашивал про качество кода, поэтому я на это время тратить не буду, делайте, чтобы вам было понятно.
Так что программисту просто нужно сказать, что билд автоматически запускается после каждого изменения (или по графику), как получишь письмо от хадсона — значит, сломал билд, вот URL, зайди, проверь, что сломал, почини. Все. Знать, как это называется, ему в принципе не обязательно. Полезно, но не обязательно.
IMHO.
Кстати, я бы не согласился с фразой «очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое».
Программист — это инструмент, который используется для решения определенных задач. В команде обычно несколько инструментов, например: программисты, бизнес-аналисты, тестеры, технические писатели, дизайнеры и т.п. Они много чего могут, но делать должны то, что требуется на проекте. А это решает человек, ответственный за проект, например, Product Manager.
Пример из жизни. Прошлый проект у меня был — сайт symantec.com. Там по правилам код не должен был содержать ни одного предупреждения (Java), комментироваться должны были все методы, включая private, сеттеры и герреты. А на теперешнем проекте (Clearwire.com) мы ничего этого не делаем, каждый форматирует, как хочет, комментарии — на усмотрение, предупреждений — сотни. Мы не можем сделать лучше? Можем, но Product Manager нам сказал — меня никто не спрашивал про качество кода, поэтому я на это время тратить не буду, делайте, чтобы вам было понятно.
Так что программисту просто нужно сказать, что билд автоматически запускается после каждого изменения (или по графику), как получишь письмо от хадсона — значит, сломал билд, вот URL, зайди, проверь, что сломал, почини. Все. Знать, как это называется, ему в принципе не обязательно. Полезно, но не обязательно.
IMHO.
С моей стороны — друге ИМХО: чисто не там где убирают, а где не сорят. Если с самого начала на проекте установлена политика отсутствия предупреждений и отформатированного кода — поддержка не занимает много времени разработчиков. С другой стороны — собственно предупреждения — они ж неспроста… Каждое предупреждение — потенциальная ошибка.
Я, как ведущий программист на проекте, хочу делать качественный код, независимо от того, что мне сказал Product Manager. Мне неприятно (психологически) работать с кодом, который пестрит предупреждениями и подсказками. Соответственно нужно выбрать здоровый компромис между бюрократией ти качеством.
Я, как ведущий программист на проекте, хочу делать качественный код, независимо от того, что мне сказал Product Manager. Мне неприятно (психологически) работать с кодом, который пестрит предупреждениями и подсказками. Соответственно нужно выбрать здоровый компромис между бюрократией ти качеством.
Это Америка, я не получаю емайлы и звонки в период с часу ночи до пяти утра, хорошо еще что мне платят по часам, так что не задаром не сплю. Для меня это просто очередной проект в очередной фирме, в апреле (надеюсь, что раньше) я вернусь в Канаду и больше никогда про эту контору не услышу.
Вот к примеру емайл по группе от 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». Так что я просто не могу себе позволить делать то, что мне комфортно забесплатно. Разработка софта — это бизнес, а раз так, за что заплатили, то и получили. А то, что я хочу, я делаю дома, для своих проектов, где мне никто не указ.
Вот к примеру емайл по группе от 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». Так что я просто не могу себе позволить делать то, что мне комфортно забесплатно. Разработка софта — это бизнес, а раз так, за что заплатили, то и получили. А то, что я хочу, я делаю дома, для своих проектов, где мне никто не указ.
60-часовая рабочая неделя? И что, оно стоит того?
А что делать? Мне платят по часам, так что я просто получаю в полтора раза больше, и это контракт на полгода — когда я его заключал в Ванкувере с работой было не очень, а голод не тетка…
По-моему на glassdor.com есть история, как девочку в amazon.com перевели на неполный рабочий день (part time), потому что она не могла работать больше 60-ти часов в неделю. Так что у меня еще не худший вариант. Правда, амазон в этом смысле это притча воязыцех, но все же.
По-моему на glassdor.com есть история, как девочку в amazon.com перевели на неполный рабочий день (part time), потому что она не могла работать больше 60-ти часов в неделю. Так что у меня еще не худший вариант. Правда, амазон в этом смысле это притча воязыцех, но все же.
Кстати, вот чудесный refcard по теме:
«Continuous Integration: Patterns and Anti-patterns»
bit.ly/5kBa1O
Если лениво регистрироваться, вот сразу PDF:
narod.ru/disk/17493813000/rc084-010d-continuous-integration_1.pdf.html
Очень толково, по полочкам, с примерами.
«Continuous Integration: Patterns and Anti-patterns»
bit.ly/5kBa1O
Если лениво регистрироваться, вот сразу PDF:
narod.ru/disk/17493813000/rc084-010d-continuous-integration_1.pdf.html
Очень толково, по полочкам, с примерами.
Ну что, это правильный способ зарабатывания инвайтов. От себя добавлю, что для любого мало-мальски серьезного продукта система continuous integration это просто обязательная вещь; особенно это касается тех случаев, когда вы вынуждены поддерживать систему под несколько платформ (например, Linux i386, Linux x86_64 и FreeBSD, не говоря уже про прочие солярки).
У нас мы используем довольно простую но эффективную многоуровневую систему — сперва делается чекаут, потом выполняется полный билд, потом строится маленький тестовый datapack, прогоняются юниттесты — которые именно на него и рассчитаны, потом строится настоящий большой production datapack, и уже на нем выполняются regression test'ы. Если обваливается один из шагов, дальше идти смысла нет — однако это все происходит независимо для разных платформ, на 6 CI серверах.
У нас мы используем довольно простую но эффективную многоуровневую систему — сперва делается чекаут, потом выполняется полный билд, потом строится маленький тестовый datapack, прогоняются юниттесты — которые именно на него и рассчитаны, потом строится настоящий большой production datapack, и уже на нем выполняются regression test'ы. Если обваливается один из шагов, дальше идти смысла нет — однако это все происходит независимо для разных платформ, на 6 CI серверах.
Сейчас обкатываем схему JIRA + Bamboo, пока только положительные эмоции. Статья очень обзорная.
И кстати с Bamboo тоже есть plug-in для IDE
И кстати с Bamboo тоже есть plug-in для IDE
> статический анализ
М.б. статистический?
М.б. статистический?
все-таки статический.
>«Если на пальцах, то система CI – это некая программа!»
Build Server != CI. Билд-сервер это один из столпов CI, но сам термин CI это именно всего лишь принцип, подход.
Build Server != CI. Билд-сервер это один из столпов CI, но сам термин CI это именно всего лишь принцип, подход.
Именно так и написано в строке перед тей, которую вы цитируете. Хотя согласен, build server != CI.
Но нельзя сводить в простом объяснении к этому. Так как проблема в том, что суть CI именно в практике, а билд сервер лишь позволяет удобно получать свежие рабочие билды. А всякие FxCop, etc лишь вкусные плюшки от билд-сервера. Они лишь помогают убедиться что билд рабочий и сигнализируют о качестве.
Было бы наверное неплохо о CI иметь перевод статьи Фаулера: martinfowler.com/articles/continuousIntegration.html
Было бы наверное неплохо о CI иметь перевод статьи Фаулера: martinfowler.com/articles/continuousIntegration.html
Друзья, а поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
Довольно просто.
В TeamCity: Administration->Server Configuration->Issue Tracker->Create new connection, создаем подключение к Jira, указывая теги проектов. Теоретически все, если в коментарии будет упоминатся название бага, TeamCity его отловит.
Если используется TortoiseSVN можно сделать красивше: в Properties корня репозитория SVN добавляем рекурсивно:
Здесь $PROJECTTAG$ — тег вашего проекта, $YOURJIRA$ — соответственно путь к ней.
Такая настройка будет добавлять в начало лог-сообщения название ишшью, и предупреждать если не введен номер.
В 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$ — соответственно путь к ней.
Такая настройка будет добавлять в начало лог-сообщения название ишшью, и предупреждать если не введен номер.
Открою небольшой секрет, но адаптированный к русскому языку глагол «to start» звучит как «стартовать». В Вашем случае не «стартает», а все-таки «стартует». В остальных случаях – так же.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Continuous Integration