Continuous integration что это
Справочная: как устроен процесс Continuous Integration
Сегодня мы обратимся к истории термина, обсудим сложности внедрения CI и приведем несколько популярных инструментов, которые помогут с ним работать.
/ Flickr / Altug Karakoc / CC BY / Фото изменено
Термин
Continuous Integration (непрерывная интеграция) — подход к разработке приложений, подразумевающий частое проведение сборок проекта и тестирование кода.
Цель — сделать процесс интеграции предсказуемым и обнаружить потенциальные баги и ошибки на ранней стадии, чтобы было больше времени на их исправление.
Впервые термин Continuous Integration появился в 1991 году. Его ввел в употребление создатель языка UML Гради Буч (Grady Booch). Инженер представил концепцию CI как часть собственной практики разработки — метода Буча. Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем. Гради не описал каких-то требований к непрерывной интеграции. Но позже в своей книге «Object-Oriented Analysis and Design with Applications» он сказал, что задача методики — ускорить выпуск «внутренних релизов».
История
В 1996 году CI переняли создатели методологии экстремального программирования (XP) — Кент Бек (Kent Beck) и Рон Джеффрис (Ron Jeffries). Непрерывная интеграция стала одним из двенадцати ключевых принципов их подхода. Основатели XP уточнили требования к методологии CI и отметили необходимость проводить сборку проекта несколько раз в день.
В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер (Martin Fowler). Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl. Утилиту создал коллега Мартина — Мэттью Фоммель (Matthew Foemmel).
Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе. Решение можно скачать и сегодня — оно распространяется под BSD-подобной лицензией.
С появлением софта для CI практику начали перенимать всё больше компаний. Согласно исследованию Forrester [стр.5 отчёта], в 2009 году 86% из пятидесяти опрошенных технологических компаний использовали или внедряли CI-методы.
Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.
Как это работает
Основу непрерывной интеграции составляют два инструмента — система контроля версий и CI-сервер. Последний может быть как физическим устройством, так и виртуальной машиной в облачной среде. Разработчики один или несколько раз в день загружают новый код. CI-сервер автоматически копирует его со всеми зависимости и выполняет сборку. После — запускает интеграционные и юнит-тесты. Если тесты проходят успешно, то CI-система разворачивает код.
Общую схему процесса можно представить следующим образом:
Методология CI предъявляет ряд требований к разработчикам:
Сложности внедрения
Первая проблема — высокие операционные расходы. Даже если компания использует открытые CI-инструменты (о которых мы поговорим дальше), то ей все равно придется потратить деньги на поддержку инфраструктуры. Однако решением могут стать облачные технологии.
Они упрощают сборку разномасштабных компьютерных конфигураций. Плюс компании платят только за используемые ресурсы, что помогает сэкономить на инфраструктуре.
Согласно опросам [стр.14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».
Третья сложность — проблемы с автоматизацией. С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.
/ Flickr / theilr / CC BY-SA
Кто использует
Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.
Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.
Инструменты
Вот нескольких популярных инструментов для CI:
Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой
В преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили для вас перевод полезного материала.
Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.
CI/CD — это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.
Определение CI/CD
Непрерывная интеграция — это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.
С технической точки зрения, цель CI — обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений. При налаженном процессе непрерывной интеграции разработчики с большей вероятностью будут делать частые коммиты, что, в свою очередь, будет способствовать улучшению коммуникации и повышению качества программного обеспечения.
Непрерывная поставка начинается там, где заканчивается непрерывная интеграция. Она автоматизирует развертывание приложений в различные окружения: большинство разработчиков работают как с продакшн-окружением, так и со средами разработки и тестирования.
Инструменты CI/CD помогают настраивать специфические параметры окружения, которые конфигурируются при развертывании. А также CI/CD-автоматизация выполняет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут нуждаться в перезапуске или выполнении каких-то дополнительных действий при развертывании приложения.
Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель — разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI/CD-конвейере.
Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание. Хотя здесь стоит отметить, что непрерывная поставка подходит не для всех бизнес-приложений.
Непрерывная интеграция улучшает коммуникации и качество
Непрерывная интеграция — это методология разработки, основанная на регламентированных процессах и автоматизации. При внедренной непрерывной интеграции разработчики часто коммитят свой код в репозиторий исходного кода. И большинство команд придерживается правила коммитить как минимум один раз в день. При небольших изменениях проще выявлять дефекты и различные проблемы, чем при больших изменениях, над которыми работали в течение длительного периода времени. Кроме того, работа с короткими циклами коммитов уменьшает вероятность изменения одной и той же части кода несколькими разработчиками, что может привести к конфликтам при слиянии.
Команды, внедряющие непрерывную интеграцию, часто начинают с настройки системы контроля версий и определения порядка работы. Несмотря на то что коммиты делаются часто, реализация фич и исправление багов могут выполняться довольно долго. Для контроля того, какие фичи и код готовы существует несколько подходов.
Многие используют фича-флаги (feature flag) — механизм для включения и выключения функционала в рантайме. Функционал, который еще находится в стадии разработки, оборачивается фича-флагами и развертывается из master-ветки в продакшн, но отключается до тех пор, пока не будет полностью готов к использованию. По данным недавнего исследования 63 процента команд, использующих фича-флаги, говорят об улучшении тестируемости и повышении качества программного обеспечения. Для работы с фича-флагами есть специальные инструменты, такие как CloudBees Rollout, Optimizely Rollouts и LaunchDarkly, которые интегрируются в CI/CD и позволяют выполнять конфигурацию на уровне фич.
Другой способ работы с фичами — использование веток в системе контроля версий. В этом случае надо определить модель ветвления (например, такую как Gitflow) и описать как код попадает в ветки разработки, тестирования и продакшена. Для фич с длительным циклом разработки создаются отдельные фича-ветки. После завершения работы над фичей разработчики сливают изменения из фича-ветки в основную ветку разработки. Такой подход работает хорошо, но может быть неудобен, если одновременно разрабатывается много фич.
Этап сборки заключается в автоматизации упаковки необходимого программного обеспечения, базы данных и других компонент. Например, если вы разрабатываете Java-приложение, то CI упакует все статические файлы, такие как HTML, CSS и JavaScript, вместе с Java-приложением и скриптами базы данных.
CI не только упакует все компоненты программного обеспечения и базы данных, но также автоматически выполнит модульные тесты и другие виды тестирования. Такое тестирование позволяет разработчикам получить обратную связь о том, что сделанные изменения ничего не сломали.
Большинство CI/CD-инструментов позволяет запускать сборку вручную, по коммиту или по расписанию. Командам необходимо обсудить расписание сборки, которое подходит для них в зависимости от численности команды, ожидаемого количества ежедневных коммитов и других критериев. Важно, чтобы коммиты и сборка были быстрыми, иначе долгая сборка может стать препятствием для разработчиков, пытающихся быстро и часто коммитить.
Непрерывное тестирование — это больше, чем автоматизация тестирования
Фреймворки для автоматизированного тестирования помогают QA-инженерам разрабатывать, запускать и автоматизировать различные виды тестов, которые помогают разработчикам отслеживать успешность сборки. Тестирование включает в себя функциональные тесты, разрабатываемые в конце каждого спринта и объединяемые в регрессионные тесты для всего приложения. Регрессионные тесты информируют команду: не сломали ли их изменения что-то в другой части приложения.
Лучшая практика заключается в том, чтобы требовать от разработчиков запускать все или часть регрессионных тестов в своих локальных окружениях. Это гарантирует, что разработчики будут коммитить уже проверенный код.
Регрессионные тесты — это только начало. Тестирование производительности, тестирование API, статический анализ кода, тестирование безопасности — эти и другие виды тестирования тоже можно автоматизировать. Ключевым моментом является возможность запуска этих тестов из командной строки, через веб-хук (webhook) или через веб-сервис и возврат результата выполнения: успешный был тест или нет.
Непрерывное тестирование подразумевает не только автоматизацию, но и интеграцию автоматического тестирования в конвейер CI/CD. Модульные и функциональные тесты могут быть частью CI и выявлять проблемы до или во время запуска CI-конвейера. Тесты, требующие развертывания полного окружения, такие как тестирование производительности и безопасности, часто являются частью CD и выполняются после разворачивания сборок в целевых средах.
CD-конвейер автоматизирует поставку изменений в различные окружения
Непрерывная поставка — это автоматическое развертывание приложения в целевое окружение. Обычно разработчики работают с одним или несколькими окружениями разработки и тестирования, в которых приложение развертывается для тестирования и ревью. Для этого используются такие CI/CD-инструменты как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.
Типичный CD-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:
В более сложном CD-конвейере могут быть дополнительные этапы, такие как синхронизация данных, архивирование информационных ресурсов, установка обновлений и патчей. CI/CD-инструменты обычно поддерживают плагины. Например, у Jenkins есть более 1500 плагинов для интеграции со сторонними платформами, для расширения пользовательского интерфейса, администрирования, управления исходным кодом и сборкой.
При использовании CI/CD-инструмента разработчики должны убедиться, что все параметры сконфигурированы вне приложения через переменные окружения. CI/CD-инструменты позволяют устанавливать значения этих переменных, маскировать пароли и ключи учетных записей, а также настраивать их во время развертывания для конкретного окружения.
Также в CD-инструментах присутствуют дашборды и отчетность. В случае сбоя сборки или поставки они оповещают об этом. При интеграции CD с системой контроля версий и agile-инструментами облегчается поиск изменений кода и пользовательских историй, вошедших в сборку.
Реализация CI/CD-конвейеров с Kubernetes и бессерверными архитектурами
Многие команды, использующие CI/CD-конвейеры в облаках используют контейнеры, такие как Docker, и системы оркестрации, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой.
Есть множество вариантов совместного использования контейнеров, инфраструктуры как код и CI/CD-конвейеров. Подробнее изучить это вы можете в статьях Kubernetes with Jenkins и Kubernetes with Azure DevOps.
Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.
CI/CD обеспечивает более частое развертывание кода
Итак, подведем итоги. CI упаковывает, тестирует сборки и оповещает разработчиков, если что-то пошло не так. CD автоматически разворачивает приложения и выполняет дополнительные тесты.
CI/CD-конвейеры предназначены для организаций, которым необходимо часто вносить изменения в приложения с надежным процессом поставки. Помимо стандартизации сборки, разработки тестов и автоматизации развертываний мы получаем целостный производственный процесс по развертыванию изменений кода. Внедрение CI/CD позволяет разработчикам сосредоточиться на улучшении приложений и не тратить силы на его развертывание.
CI/CD является одной из DevOps-практик, поскольку направлена на борьбу с противоречиями между разработчиками, которые хотят часто вносить изменения, и эксплуатацией, требующей стабильности. Благодаря автоматизации, разработчики могут вносить изменения чаще, а команды эксплуатации, в свою очередь, получают большую стабильность, поскольку конфигурация окружений стандартизирована и в процессе поставки осуществляется непрерывное тестирование. Также настройка переменных окружения отделена от приложения и присутствуют автоматизированные процедуры отката.
Эффект от внедрения CI/CD-конвейеров можно измерить в виде ключевых показателей эффективности (KPI) DevOps. Такие KPI как частота поставки (deployment frequency), время реализации изменений (change lead time) и среднее время восстановления после инцидента (mean time to recovery) часто улучшаются при внедрении CI/CD с непрерывным тестированием. Однако CI/CD — это лишь один из процессов, который может способствовать этим улучшениям. Есть и другие условия для увеличения частоты поставки.
Для начала работы с CI/CD команде разработчиков и эксплуатации необходимо совместно определиться с технологиями, практиками и приоритетами. Команды должны выработать консенсус в отношении правильных подходов к своему бизнесу и технологиям, чтобы после внедрения CI/CD команда постоянно придерживалась выбранных практик.
Введение в 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 по завершении инсталляции создаем новый проект, который фактически просто группа для отдельных билд-конфигураций, и в нем новую конфигурацию, которую я, не мудрствуя лукаво назвал 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, добавить зависимость на артефакты из билда и наслаждаться.
Но что делать если у вас есть, к примеру, сервис или, хуже, база данных?
Виндовс-сервис перед деплойментом нужно остановить, перезаписать и стартануть, базу данных – пересоздать или обновить.
Итак, как добавить такой скрипт в наш проект? Просто добавляем в сорц-контрол, и ставим соответствующий раннер.
Типичный для меня скрипт билда проекта с сайтом, виндовс-сервисом и базой делает следующее: билдит проект, обновляет конфигурации в соответствии с шаблоном, ставит на сайт майнтенанс-мессадж, стопает на дев-сервере сервис, деплоит все на девелоперский сервер x-copy, обновляет базу скриптами из сорц-контрола (если нужно конечно), стартает сервис, убирает майнтенанс-мессадж. Позитив этого скрипта в том, что он без изменений пригоден к деплойменту в живую среду.
Вобщем, это уже тема для другого разговора, продолжу если вам этот пост понравится.
Continuous Integration для самых маленьких
Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.
Работа с VCS
Для начала нам потребуется тестовое окружение для тестирования приложения. Если цикл тестирования достаточно длительный, а разработка ведется быстро, то разумно выделить еще и dev-окружение. Структура VCS будет отражать ваши окружения.
Все разработчики работают с основной веткой разработки, затем определенная версия фиксируется и мержится в тестовую ветку. Из тестовой ветки происходит выкладка на тестовое окружение. Производится тестирование, внесение фиксов и обратный мерж в дев. Протестированная версия отправляется в релизную ветку и от туда публикуется на продакшн. В случае нахождения ляпов на продакшне (к сожалению, такое бывает) чиним в авральном режиме из продакшн ветки и опять мержим в DEV-ветку.
В философии GIT будет немного иначе, так как при работе с GIT не принято комитить в master и даже dev. Вместо этого практикуется подход фича-бренч. Про git workflow можно почитать здесь: habrahabr.ru/post/60030. Вообще, все предлагаемые структуры VCS преследуют одну цель: избежать ситуации, когда ветка разработки не стабильна, а совершенно необходимо что-то быстро «пофиксить» или «допилить» и выложиться. При выборе своей структуры задайте себе вопрос «смогу ли я выложиться на продакшн в течение одного дня и не поломать все. Если ответ «да», то структура вам подходит.
Чтобы не пропускать ошибки на продакшн, следует сделать тестовое окружение на столько похожим на целевое, на сколько это возможно. Обычно, главная сложность это зависимость от сторонних веб-сервисов или других компонентов и операции, связанные с реальными финансовыми транзакциями.
Конфигурации
Начинающие разработчики часто впадают в ступор при отладке трансформаций Web.config’а на локальных машинах: в отличие от App.config’ов они хранятся на уровне приложения, а не в папке bin, поэтому при локальной сборке трансформации не происходит. Трансформации применяются при публикации проекта. Если вам действительно нужно обойти это ограничение, можно создать файл Web.template.config и добавить трансформацию на PostBuild приложения. Не забудьте только убрать таск трансформации из проекта, иначе трансформация будет применяться дважды.
Если в приложении используют другие технологии, все-равно лучше иметь один основной конфигурационный файл с общими настройками и дополнительные конфигурационные файлы для изменения эталонного конфига. Это избавит вас от копипаста одинаковых настроек.
Добавление файлов, отсутствующих в проекте к выкладке
Версионирование продукта
Основные подходы
Все современные CI-решения предлагают такую переменную во время сборки. Для того, чтобы этот подход работал, нужно добавить импортировать msbuild-таски из msbuildtasks.tigris.org и добавить в конце проекта:
Версионирование базы данных
SSDT-проект msdn.microsoft.com/ru-ru/data/tools.aspx
Плюсы: процесс создания и редактирования БД напоминает то, как бы вы это делали с Management Studio.
Минусы: сложность написания миграционных скриптов. Т.к. инкрементальные изменения строит сам проект, сохранность данных обеспечивается за счет pre-deploy и post-deploy-скриптов. Придется опираться на наличие/отсутствие полей в БД или «изобретать» таблицу schema version, уже реализованную в миграционных движках.
ECM7 Migrator code.google.com/p/ecm7migrator
Движок миграций с открытым кодом. Проект поддерживает хабраюзер dima117.
Плюсы: поддерживаются разные СУБД, если что-то вас не устраивает, код открыт. Мигратор поддерживается и обрастает новыми функциями. И, пожалуй, самое важное, поддерживает несколько ключей миграций в одной базе данных. Это может быть очень полезно, если ваше приложение модульное и поддерживает плагины в том или ином виде. Каждый плагин может выполнять свои миграции и при этом использовать одну БД
Минусы: нет плюшек Entity Framework Migrations.
Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
Автоматизация публикации приложения
В 2012 студии система публикации web-проектов была значительно улучшена. В первую очередь это касается профилей публикации. Если вы публикуете приложение в azure, то профиль можно просто скачать с портала. В противном случае его нужно будет создать.
Как видно на скриншотах, в последней версии WebDeploy можно запустить EF-миграции с помощью всего одной галочки. Кроме этого публикация из студии умеет заменять строку подключения без использования трансформации.
Подробно про трансформации и публикации написано у Троя Ханта в статье: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html. Сейчас нас интересует пятый шаг его гайдлайна, а именно, автоматическая публикация с помощью билд-сервера: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html. Я большой фанат TeamCity, поэтому рассмотрим именно эту CI.
Автоматизация публикации Windows-служб
Для автоматического создания windows-служб проще всего воспользоваться командной sc:
TeamCity
Использование средств, описанных выше, сэкономит ваше время. Пойдем дальше и установим билд-сервер. Скачиваем TeamCity: www.jetbrains.com/teamcity и запускаем инсталятор, жмем везде «Ок».
Два основных понятия TeamCity – «проект» и «билд». «Проект» соответствует вашему солюшну, а под билдом понимается любая осмысленная совокупность действий над вашим проектом: будь то сборка, запуск тестов, выкладка на сервер, создание бекапов и так далее.
Автоматизированная выкладка
Первым шагом, дадим возможность выкладывать новую версию тему у кого Visual Studio не устновлена.
Основная идея, это запустить msbuild-шаг с дополнительными параметрами, создайте новый Build Definition и выберите первый шаг Msbuild. В параметры командной строки нужно передать:
Эти параметры укажут, куда нужно публиковать.
Для того, чтобы опубликовать миграции потребуется дополнительный шаг Command Line:
Сохраняете билд. Теперь кто угодно может опубликовать последнюю версию из VCS. Хорошая практика публиковаться на дев-стенд каждый день до начала рабочего дня. Таким образом вы будете отлавливать интеграционные проблемы максимально быстро.
Rolling builds
Еще одна хорошая практика – настроить триггер на запук билда, который просто будет запускать сборку вашего солюшна после каждого изменения в репо или по таймеру (например, каждые 10 минут), если над проектом работает одновременно очень много разработчиков. К этому билду следует подключить нотификацию. TeamCity поддерживает нотификации по почте, jabber, с помощью плагина для VisualStudio и Tray-приложения. Выберите вариант по вкусу. Мне по душе приложение в трее. Если билд сломался – надо срочно чинить.
Как не ломать билд
Какие бы практики вы не вводили, чтобы не делали, не существует никакого способа дать 100% гарантию, что разработчики не будут вносить в VCS код, который даже не собирается. Этот вопрос должен решаться с помощью административных мер: не уходить с работы, не проверив, что билд после твоих изменений собрался, кто сломал, тот и чинит. В одной компании, где я работал проблема со слишком часто сломанным билдом была решена правилом: сломал билд – принеси тортик. Сначала торты ели каждый день, потом перестали.
Автоматический запуск тестов
Этот шаг следует разделить на 2: юнит-тесты и интеграционные и приемочные тесты. Это важно, потому что юнит-тесты должны работать на любом окружении. Все внешние зависимости заменяются фейками.
Запуск юнит-тестов
Запуск интеграционных и приемочных тестов
Эти тесты могут зависеть от многих факторов и их запуск может предполагать накатывание бекапов или скриптов инициализации. Возможно, что вы захотите построить дополнительные отчеты о запуске таких тестов. Лучше не захламлять ваш проект с выкладкой и создать для них специальный билд. TeamCity позволяет создавать цепочки билдов. В Build triggers билда с приемочными/интеграционными тестами вы можете добавить триггер, срабатывающий при удачном прохождении билда с выкладкой. Создание такого билда для запуска приемочных тестов я описал в топике: habrahabr.ru/post/182032.
Бекапы
Создание бекапов при выкладке также может быть автоматизировано. Для бекапа файловой системы, лично я не нашел ничего лучше, чем nnbackup: www.nncron.ru/index_ru.shtml.
Команда создает аривирует в zip папку source и копирует архив в destination. Устанавливать nnbackup на целевые машины или вызывать с билд-сервера: вопрос ваших предпочтений, расположения билд сервера, сетевых издержек и безопасности.
Бекапить sql-сервер можно с помощью T-SQL
Т.е. для автоматического бекапа, вам потребуется добавить еще один Command Line-шаг. Или вы можете воспользоваться msbuild-тасками из того-же самого community-пакета, а для nnbackup написать свой msbuild-таск.
Можно пойти дальше и поставить триггер на запуск автоматического отката из бекапа, если приемочные тесты не прошли. Тогда у вас будет цепочка билдов: Выкладка » Приемочные тесты » Откат из бекапа.
Интеграция с системой ведение проекта и баг-трекером
До этого момента, мы уже сделали много полезного. Осталась одна неприятная особенность. Билд-сервер все-еще никак не связан с нашим процессом разработки. Он ничего не знает о задачах текущей итерации разработки.
TeamCity поддерживает интеграцию с YouTrack, Jira и Bugzilla. Интеграция выполняется буквально в 2 клика. После этого, указывая номер задачи в комментарии к комиту, вы увидите ссылки на соответствующие задачи в информации о билде.
YouTrack поддерживает обратную интеграцию. Основное преимущество: YouTrack будет автоматически указывать номер билда, в котором баг или фича были закрыты.
Артефакты билда
Если ваше приложение коробочное, то вам, наверняка нужно озаботиться созданием инсталляторов или deploy packages для отгрузки клиентам. Создание инсталляторов – отдельная тема, я не буду ее рассматривать в рамках этого топика. Важно, что для коробочного продукта, инсталлятор или пакет публикации – это самая важная часть релиза. Как раз для этого и придуманы артефакты билда.
Артефакт – это любой файл, являющийся значимым результатом выполнения билда. Для билдов с инсталляторами вы можете указать my-installer.exe или my-package.zip, как маску для артефактов билда и TeamCity отобразит их в соответствующей вкладке.
Вот здесь и пригодится интеграция с Issue Tracker’ом. Тестировщик или менеджер может посмотреть закрытую задачу, перейти по ссылке с билдом и забрать версию с исправлениями из артефактов билда.
В заключение хочу добавить, что процесс разработки сугубо индивидуален для каждой команды. Приведенные практики являются базой. Дальнейшее развитие инструментария должно происходить вместе с развитием продукта. Мы разрабатываем софт, чтобы делать жизнь других людей лучше. Разумно использовать софт и для того, чтобы нам самим было комфортнее работать.