Ci что это: Continuous Integration для новичков / Хабр

Continuous Integration для новичков / Хабр

Что такое CI

Continuous Integration — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет раннего обнаружения и устранения ошибок и противоречий. Основным преимуществом является сокращение стоимости исправления дефекта, за счёт раннего его выявления.

Если вы не знаете как настроить CI в своем проекте, я приглашаю вас «под кат»

Всем любителям стилей и нотаций, я не всегда соблюдаю нотации и требования в силу личных обстоятельств и причин, которые я не хочу обсуждать. Я знаю, что я отступаю от канонов React и JS сообществ, поэтому сразу прошу меня за это извинить и считать данные вольности придурью автора. Моя цель поделиться опытом и рассказать людям насколько просто сегодня настроить CI, я не имею никакого отношения к Тревису или Хероку, более того, мне не нравится Heroku, я использовал его только из-за простоты настройки для новичков. Дальше TLDR.

Зачем нам это нужно

В процессе работы мне часто приходится обновлять сервисы и разворачивать их на конечные сервера. Когда проектов было мало, это не составляло особых проблем, т.к. релизы были редкими, развертывания выполнялись довольно редко. Тесты выполнялись вручную. Со временем, проектов и задач становилось больше, и выполнение однотипных задач стало занимать больше времени. Рассмотрим классический процесс решения задачи, подходящий для большинства компаний:

• Берем задачу из списка/Получаем от начальства
• Создаем новую ветку в git и открываем пул реквест
• Пишем код
• Лично или с помощью коллеги выполняем код-ревью (code review — обзор/проверку кода)
• Запускаем тесты
• Сливаем ветку в мастер
• Выполняем сборку проекта
• Публикуем новую сборку

Этот процесс повторяется для каждой задачи, если вы 10 дней писали код и на сборку/развертывание потратили 1 час, то это выглядит разумно и не трудозатратно. Но что если вы поправили мелкий баг за 1 минуту, но на развертывание потратите тот же час? В этой ситуации это выглядит довольно расточительно. А если вам нужно выполнять в день 10 — 20 багфиксов (bugfix, исправление ошибки)?

Первый путь, укрупнять пул реквесты и делать объединение в мастер как можно реже. Второй путь настроить CI чтобы процесс тестирования/построения/развертывания выполнялся автоматически. Делать ревью больших пул реквестов неудобно, поэтому мы пойдем вторым путем.

Что мы будем использовать для решения задачи

Когда я столкнулся с этой проблемой еще в далеком 2008м году, на рынке было очень мало решений, тогда для автоматизации этих процессов приходилось разворачивать свои сервера, следить за правильностью версий библиотек, писать скрипты для сборки проекта, писать скрипты для выгрузки проекта на сервера и много других трудоемких операций. Сейчас все проще, большая часть задач элементарно поддается автоматизации, на рынке множество облачных сервисов для их решения. После продолжительных поисков, я решил остановиться на open source проекте travis-ci.org. «Трэвис» бесплатен для open source проектов, имеет платный вариант для коммерческого использования. Он понравился мне за простоту настройки и использования. Тем не менее, чтобы это не выглядело рекламой, я хочу отметить, что на рынке появляется все больше достойных сервисов, например: CircleCI, Codeship.

Мы создадим React приложение, для тестирования будем использовать Jest, для развертывания Heroku. Предполагается, что читатель обладает базовыми знаниями в программировании, базовым английским, базовым интеллектом, имеет настроенную среду node.js, установленный yarn, имеет учетные записи на github.com, heroku.com, travis-ci.org или в состоянии создать их в процессе прохождения данного туториала.

Создаем приложение

Т.к. статья ориентирована на молодых разработчиков, мы будем использовать генератор

React приложений — create-react-app. Установим его глобально:

$ yarn global add create-react-app

После установки создадим наше приложение, к примеру мы будем писать веб-интерфейс для управления производственной линией.

$ create-react-app factory_line_manager

После создания проекта и скачивания всех библиотек, зайдем в папку проекта и запустим его.

cd factory_line_manager
$ yarn start

В браузере должна открыться страница нашего приложения. По умолчанию, если порт 3000 свободен — localhost:3000

По умолчанию create-react-app создает нам проект with no build configuration, что означает — без конфигураций. Генератор создаст для нас стандартный файл конфигурации и нам не нужно будет настраивать webpack, jest, babel и прочие библиотеки. В 95% случаев эти настройки будут выдавать более качественный и чистый код, чем новичок сможет сконфигурировать самостоятельно. Поэтому, я настоятельно рекомендую оставлять конфигурацию как есть, до тех пор пока вы не поймете, как это работает.

Если Вам интересно как работает конфиг

Сделайте копию проекта и выполните следующую команду в консоли

$ yarn eject

Подтвердите операцию. Генератор извлечет конфигурационные файлы в папку проекта, где вы сможете изучить их детально.

Подключаем GIT

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

Зайдите на github и создайте новый репозиторий. Я создал следующий репозиторий habrahabr_topic_352282.

Находясь в папке проекта. Инициализируем гит:

$ git init

Добавляем все файлы нашего проекта в гит

$ git add .

Создаем первый комит:

$ git commit -m "First commit"

Подключаем локальную папку к Вашему репозиторию на гите. Будьте внимательны, замените evilosa — на свой профиль и habrahabr_topic_352282 — на имя созданного вами репозитория:

$ git remote add origin [email protected]:evilosa/habrahabr_topic_352282.git

Заливаем наш проект на удаленный сервер гит:

$ git push -u origin master

После последней команды должна произойти магия и код выгрузится в наш репозиторий на гите.

Настраиваем CI

Заходим на сайт travis-ci.org и входим с учетной записью гитхаба (Sign in with Github). В появившемся окне авторизуем приложение через OAuth:

Нажимаем Authorize-CI и ждем пока тревис выполнит синхронизацию данных с нашей учетной записью на гитхабе. После завершения этого процесса вы должны увидеть что-то вроде этого:

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

Мы выполнили большую часть работы, теперь нам нужно создать конфигурационный файл для тревиса. Создадим в папке нашего проекта файл .travis.yml со следующим содержимым:

sudo: false

language: node_js
node_js:
  - 9

branches:
  only:
    - master

Добавляем изменения в гит и выгружаем на сервер:

$ git add .
$ git commit -m "Add travis config"
$ git push -u origin master

Настройка первого этапа CI завершена. После выгрузки изменений в гит, тревис должен увидеть настройки и выполнить тестирование и сборку проекта:

В конце логов тревиса, вы должны увидеть статус успешного прохождения тестов:

Теперь при каждом комите в мастер ветку у нас будет запускаться автоматическое построение и запуск тестов на тревисе. Уже неплохо. Двигаемся дальше. Следующий шаг — автоматическая публикация нашего проекта на Heroku.

Зайдите на Heroku, создайте учетную запись и авторизуйтесь. Обратите внимание, что почта из домена mail.ru у них заблокирована, используйте сторонние сервисы.

Если Вы новый пользователь то увидите примерно следующее:

Создайте новое приложение нажав кнопку Create New App. Введите имя Вашего приложения и регион размещения:

Обратите внимание имя моего приложения на Heroku, не соответствует имени репозитория.

Вернемся в наш файл конфигурации тревиса .travis.yml. Добавьте в него следующий код подставив свои значения:

deploy:
  provider: heroku
  app: "Имя вашего приложения в Heroku"
  api_key:
    secure: "Ваш ключ API Heroku"

Как найти ключ API Heroku

Перейдите в настройки профиля, для этого кликните по иконке профиля и выберите пункт «Account settings». Найдите пункт API key:

После нажатия на кнопку Reveal у Вас появится возможность скопировать ключ.

Добавляем изменения в гит и выгружаем на сервер:

$ git add .
$ git commit -m "Add Heroku deploy to travis"
$ git push -u origin master

Проверяем логи тревиса. Если все сделано правильно, то мы должны увидеть следующее сообщение:

Переходим по ссылке вида https://<Имя вашего приложения на Heroku>.herokuapp.com/ и видим наше React приложение.

Если вылетела ошибка

Если при построении вы увидели вот такую ошибку:

Значит произошло обновление какого-либо пакета входящего в состав генератора create-react-app.

Обновите список пакетов локально и выгрузите изменения в мастер следующими командами:

$ yarn install
$ git add .
$ git commit -m "Update yarn.lock"
$ git push -u origin master

Наш CI готов, можно испытывать его боем.

Что делать дальше

Эта статья призвана ознакомить пользователя с основами CI и служит отправной точкой для дальнейших экспериментов. Из явных минусов представленного подхода — Ваш API ключ Heroku будет лежать в открытом репозитории. После прохождения туториала, я настоятельно рекомендую Вам его обновить. Для реальных проектов ключи определяются через encrypted variables, подробнее Вы можете ознакомиться с этим здесь.

Если Вам нужно публиковать несколько версий приложения, к примеру — production, staging. То вы можете сделать несколько веток в гите и управляя этим процессом, публиковать разные ветки на разные приложения в Heroku, пример:

deploy:
  provider: heroku
  app: 
    master: my-staging-application
    production: my-production-application
  api_key:
    secure: "Ваш ключ API для Heroku"

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

Бонус

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

Зайдите и зарегистрируйтесь на coveralls.io с учетной записью github. После успешной OAuth авторизации, в меню слева нажмите Add repos. В появившемся списке переключите тумблер для нужного проекта:

В файл .travis.yml добавим следующий код:

after_success:
  - cat ./coverage/lcov.info | ./node_modules/codecov.io/bin/codecov.io.js
  - cat ./coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js

Замените содержимое файла readme.md подставив свои значения в ссылки:

# Factory line manager
[![Travis][build-badge]][build]
[![Coveralls][coveralls-badge]][coveralls]

Awesome factory line manager!

[build-badge]: https://img.shields.io/travis/<Ваше имя на гите>/<Имя вашего проекта>/master.png?style=flat-square
[build]: https://travis-ci.org/<Ваше имя на гите>/<Имя вашего проекта>

[coveralls-badge]: https://img.shields.io/coveralls/<Ваше имя на гите>/<Имя вашего проекта>/master.png?style=flat-square
[coveralls]: https://coveralls.io/github/<Ваше имя на гитхабе>/<Имя вашего проекта>

Добавьте каталог coverage в .gitignore

В проекте для тестов, по умолчанию добавим проверку покрытия кода тестами. Для этого в файле package.json поправьте код до следующего вида:

...
"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom --coverage --collectCoverageFrom=src/**/*js --collectCoverageFrom=!src/registerServiceWorker.js",
...

В данном конфиге мы добавляем запуск проверки покрытия нашего кода тестами. Это нужно для генерации файлов, необходимых для создания баджа. Мы исключаем файл src/registerServiceWorker из проверки, т.к. этот файл нами не обслуживается.

Установим нужные dev зависимости для проекта и выгрузим все на github:

$ yarn add codecov.io coveralls --dev
$ git add .
$ git commit -m "Add coverage"
$ git push -u origin master

Результат после сборки проекта тревисом:

Заключение

Как видите, настроить полноценный CI при наличии знаний займет не более 10 минут, в сложных конфигах вы можете потратить часы, возможно дни и недели. Но сколько своего времени вы сэкономите автоматизировав этот процесс? Я думаю тут каждый решит для себя сам, нужно ему это или нет.

Надеюсь пост был Вам полезен, исходный код можно взять тут, если понравилось плюсуйте, если нет — люто минусуйте. Желаю успешного кодерства. Мир всем!

P.S. Я специально использовал разные имена в папке проекта, имени репозитория и имени приложения в Heroku. API ключ перегенерировал. Если кому интересно, в своем проде я добавляю в CI пайплайн промежуточный сервис для сборки Docker контейнеров и публикую готовые контейнеры в swarm кластер.

Введение в 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. Ещё большее спасибо Мицголу за инвайт.

Что такое 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-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:

• Получение кода из системы контроля версий и выполнение сборки.
• Настройка инфраструктуры, автоматизированной через подход “инфраструктура как код”.
• Копирование кода в целевую среду.
• Настройка переменных окружения для целевой среды.
• Развертывание компонентов приложения (веб-серверы, API-сервисы, базы данных).
• Выполнение дополнительных действий, таких как перезапуск сервисов или вызов сервисов, необходимых для работоспособности новых изменений.
• Выполнение тестов и откат изменений окружения в случае провала тестов.
• Логирование и отправка оповещений о состоянии поставки.

Например, в Jenkins конвейер определяется в файле Jenkinsfile, в котором описываются различные этапы, такие как сборка (build), тестирование (test) и развертывание (deploy). Там же описываются переменные окружения, секретные ключи, сертификаты и другие параметры, которые можно использовать в этапах конвейера. В разделе post настраивается обработка ошибок и уведомления.

В более сложном 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 команда постоянно придерживалась выбранных практик.

Краткий обзор инструментов CICD: Gitlab CI, Docker, Ansible

как устроен процесс Continuous Integration / Блог компании 1cloud.ru / Хабр

Сегодня мы обратимся к истории термина, обсудим сложности внедрения 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 из экстремального программирования. Исправление багов — самая приоритетная задача разработчиков.
• Автоматизировать процессы. Разработчики и менеджеры должны постоянно искать «узкие места» в процессе интеграции и устранять их. Например, часто «бутылочным горлышком» интеграции оказывается тестирование.
• Проводить сборки как можно чаще. Раз в день, чтобы синхронизировать работу команды.

Сложности внедрения

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

Они упрощают сборку разномасштабных компьютерных конфигураций. Плюс компании платят только за используемые ресурсы, что помогает сэкономить на инфраструктуре.

Согласно опросам [стр.14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».

Третья сложность — проблемы с автоматизацией. С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.

/ Flickr / theilr / CC BY-SA

Кто использует

Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.

Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.

Инструменты

Вот нескольких популярных инструментов для CI:

• Jenkins — одна из самых популярных CI-систем. Она поддерживает более тысячи плагинов для интеграции с разными VCS, облачными платформами и другими сервисами. Jenkins используем и мы в 1cloud: инструмент входит в нашу DevOps-систему. Он регулярно проверяет Git-ветку, предназначенную для тестирования.
• Buildbot — python-фреймворк для написания собственных процессов непрерывной интеграции. Первоначальная настройка инструмента довольно сложна, однако это компенсируется широкими возможностями кастомизации. Среди достоинств фреймворка пользователи выделяют его невысокую ресурсоёмкость.
• Concourse CI — сервер от Pivotal, который использует контейнеры Docker. Concourse CI интегрируется с любыми инструментами и системами контроля версий. Разработчики отмечают, что система подходит для работы в компаниях любых размеров.
• Gitlab CI — инструмент, встроенный в систему контроля версий GitLab. Сервис работает в облаке и использует для конфигурации YAML-файлы. Как и Concourse, Gitlab CI применяет Docker-контейнеры, которые помогают изолировать разные процессы друг от друга.
• Codeship — облачный CI-сервер, который работает с GitHub, GitLab и BitBucket. Платформа не требует долгой первоначальной настройки — в Codeship доступны стандартные предустановленные CI-процессы. Для небольших (до 100 сборок в месяц) и open source проектов Codeship доступен бесплатно.

Материалы из нашего корпоративного блога:

Отсутствует CI САМ-модуль LG что это такое?

CI САМ-модуль — устройство, которое является как бы расшифровщиком цифрового контента. CI расшифровывается как Common Interface. Который зашифрован для всех, так как платный. Если вы заплатили за услугу телевиденья — то у вас должно быть такой модуль, чтобы вы смогли получить доступ к контенту. Данный модуль выдает и настраивает провайдер для каждого абонента. Как я понимаю это все не касается аналогового вещания, это все цифровое ТВ.

И разумеется, если у вас нет этого CI САМ-модуля, то показывать ничего не будет. Или даже если есть, но он не настроен сотрудником провайдера — все равно показываться не будет.

Может быть и обратная ситуация — когда у вас услуга настроена на аналоговое вещание, а в телевизоре в настройках выставлено на прием цифрового. Тогда CI САМ-модуль вам как бы и не нужен. Но необходимо кабель антенны подключить в соответствующее гнездо и в самом телевизоре настроить прием аналогового ТВ.

Еще вариант решения ошибки отсутствует CI САМ-модуль — повторить настройку каналов, но уже снять галочку по поводу кабельных каналов, чтобы остались только аналоговые. Это как раз тот случай, когда у вас тип вещания — аналоговый.

За заметку. Модуль вставляется вот сюда:

Расположение разьема может отличаться и зависит от конкретной модели телевизора. Еще пример расположения модуля:

Дополнительная информация:

На этом все. Удачи.

На главную!
LG
19.10.2017

CI — это… Что такое CI?

1. call indicator — указатель вызова;

2. card input — ввод с перфокарт; входные данные на перфокартах;

3. carrier-to-interference ratio — отношение сигнала несущей к уровню шума;

4. cast iron — литейный чугун;

5. chain index — цепной указатель;

6. chemical injection — химический впрыск;

7. circuit interruption — размыкание цепи;

8.

clearing index — коэффициент очистки;

9. color index — индекс цвета; цветной индекс;

10. combat information — информация о боевой обстановке, боевая информация;

11. communications and instrumentation — связь и контрольно-измерительная аппаратура;

12. communications information — информация по связи;

13. comparison indicator — индикатор сравнения;

14. component interface — интерфейс компонентов;

15. compression-ignition — с воспламенением от сжатия;

16. computer interface — интерфейс компьютера;

17. cone interference — касание шарошек;

18. configuration interaction — конфигурационное взаимодействие;

19. configuration-independent — независимый от конфигурации;

20. containment integrity — сохранность гермооболочки, целостность гермооболочки;

21. containment isolation — изоляция гермооболочки при аварии ядерного реактора;

22. contour interval — контурный интервал; сечение; интервал между изолиниями;

23. control instrumentation — управление и приборы контроля;

24. convective instability — конвективная нестабильность;

25. correlation index — индекс корреляции; показатель зависимости между удельным весом и температурой кипения нефтепродукта;

26. corrugated iron — волнистая листовая сталь; рифленая сталь;

27. counterintelligence — защита от средств разведки; контрразведка;

28. course indicator — указатель курса;

29. crystal impedance — полное сопротивление кристалла;

30. cubic inch — кубический дюйм;

31. cumulative index — кумулятивный указатель;

32. curie — кюри;

33. current-awareness information — сигнальная информация

Англо-русский словарь технических аббревиатур.
2011.

Как создать современную CI/CD-цепочку с помощью бесплатных облачных сервисов

Решение поставленной перед разработчиком задачи бывает найти нелегко. Но как только оно получено, автору сразу хочется поделиться им со всем миром, ведь это так здорово — «отгружать» код. Неиспользуемая программа — это не что иное, как цифровой мусор. Чтобы не тратить время на никому не нужный софт, современные разработчики поставляют функциональность небольшими порциями, разбивая процесс на короткие итерации.

Такой способ создания программного обеспечения используется в процессах Непрерывной интеграции (Continuous Integration) и Непрерывного развертывания (Continuous Deployment), или CI/CD-цепочке. В этой статье мы пройдем по всем шагам настройки такой цепочки, используя для ее построения бесплатные облачные сервисы.

Мы сделаем следующее:

1. Напишем маленькую программу на Python (не Hello World).
2. Создадим несколько автоматизированных тестов.
3. Разместим код на GitHub.
4. Настроим Travis CI на постоянное выполнение автоматизированных тестов.
5. Настроим Better Code Hub на постоянную проверку качества кода.
6. Превратим программу на Python в веб-приложение.
7. Создадим Docker-образ для приложения.
8. Разместим Docker-образ на Docker Hub.
9. Развернем Docker-образ на Heroku.

В этой статье я стремлюсь продемонстрировать читателю основные компоненты современной цепочки разработки программного обеспечения, а также то, как эти компоненты соединяются в единое целое. Текст не акцентирован на каком-либо языке программирования или методологии разработки. Возможно, некоторые компоненты не совпадают с теми, которые используются в вашем технологическом стеке. Но даже в этом случае я бы посоветовал пройти все предложенные шаги. Имея общее понимание работы цепочки от начала до конца, будет намного проще подстроить ее под себя.

Чтобы быть полностью честным по отношению к читателям, должен сообщить, что являюсь одним из разработчиков Better Code Hub.

Шаг № 1: пишем генератор модных фраз

Итак, нам нужна небольшая программка, которую мы прогоним через все этапы цепочки — от ноутбука до облака. С этой целью напишем на Python генератор модных CI/CD-фраз.

Создайте новую директорию ‘cicd-buzz’, внутри — еще одну под названием ‘buzz’, а в ней — файл ‘generator.py’, содержащий представленный ниже код.

import random

buzz = ('continuous testing', 'continuous integration',
    'continuous deployment', 'continuous improvement', 'devops')
adjectives = ('complete', 'modern', 'self-service', 'integrated', 'end-to-end')
adverbs = ('remarkably', 'enormously', 'substantially', 'significantly',
    'seriously')
verbs = ('accelerates', 'improves', 'enhances', 'revamps', 'boosts')

def sample(l, n = 1):
    result = random.sample(l, n)
    if n == 1:
        return result[0]
    return result

def generate_buzz():
    buzz_terms = sample(buzz, 2)
    phrase = ' '.join([sample(adjectives), buzz_terms[0], sample(adverbs),
        sample(verbs), buzz_terms[1]])
    return phrase.title()

if __name__ == "__main__":
    print generate_buzz()

Также создайте в этой директории пустой файл ‘init.py’. Теперь структура проекта должна выглядеть так:

cicd-buzz/
  buzz/
    __init__.py
    generator.py

Зайдите в директорию ‘buzz’ и выполните скрипт:

[cicd-buzz/buzz] $ python generator.py
End-To-End Devops Enormously Boosts Continuous Testing

Попробуйте несколько раз — это весело:

[cicd-buzz/buzz] $ python generator.py
Complete Continuous Improvement Enormously Improves Devops
[cicd-buzz/buzz] $ python generator.py
Modern Devops Remarkably Improves Continuous Testing

Шаг № 2: создаем автоматизированные тесты

Цепочки непрерывной поставки (Continuous Delivery) нужны лишь в том случае, когда написано много автоматизированных тестов, которые помогают избежать непрерывной отгрузки плохо работающего ПО. Для размещения unit-тестов создайте в корневой директории проекта папку ‘tests’. Представленный ниже код сохраните в файл ‘test_generator.py’:

import unittest

from buzz import generator

def test_sample_single_word():
    l = ('foo', 'bar', 'foobar')
    word = generator.sample(l)
    assert word in l

def test_sample_multiple_words():
    l = ('foo', 'bar', 'foobar')
    words = generator.sample(l, 2)
    assert len(words) == 2
    assert words[0] in l
    assert words[1] in l
    assert words[0] is not words[1]

def test_generate_buzz_of_at_least_five_words():
    phrase = generator.generate_buzz()
    assert len(phrase.split()) >= 5

Тесты мы будем запускать с помощью фреймворка ‘pytest’. Для его установки потребуется Python Virtual Environment (‘virtualenv’). Не беспокойтесь, сделать это легче, чем сказать. Сначала убедитесь, что у вас установлен virtualenv. Далее выполните следующую команду в корневой директории проекта:

[cicd-buzz] $ virtualenv venv

В результате будет создана новая директория ‘venv’. Чтобы начать использование этого окружения, выполните:

[cicd-buzz] $ source venv/bin/activate
(venv) [cicd-buzz] $

Далее создайте файл под названием ‘requirements.txt’ и пропишите там зависимость от pytest:

pytest==3.0.6

Для загрузки перечисленных в requirements.txt требований выполните команду ‘pip’:

(venv) [cicd-buzz] $ pip install -r requirements.txt

Корневая директория проекта должна выглядеть так:

cicd-buzz/
  buzz/
  requirements.txt
  tests/
  venv/

Теперь, используя виртуальное окружение, мы можем выполнить тесты из ‘test_generator.py’:

(venv) [cicd-buzz] $ python -m pytest -v tests/test_generator.py

Вывод команды должен выглядеть примерно так:

========== test session starts ==========
platform darwin -- Python 2.7.10, pytest-3.0.6, py-1.4.32, pluggy-0.4.0 -- /Users/rob/projects/workspace/cicd-buzz/venv/bin/python
cachedir: .cache
rootdir: /Users/rob/projects/workspace/cicd-buzz, inifile:
collected 3 items
tests/test_generator.py::test_sample_single_word PASSED
tests/test_generator.py::test_sample_multiple_words PASSED
tests/test_generator.py::test_generate_buzz_of_at_least_five_words PASSED
========== 3 passed in 0.02 seconds ==========

Шаг № 3: размещаем код на GitHub

Войдите на GitHub (зарегистрируйтесь, если у вас еще нет аккаунта), и создайте новый публичный репозиторий ‘cicd-buzz’.

В корневой директории проекта создайте файл ‘.gitignore’, содержащий одну строку:

venv

Это нужно для того, чтобы git не добавил virtualenv в репозиторий. А теперь настало время локально инициализировать Git и отправить код на GitHub:

[cicd-buzz] $ git init
[cicd-buzz] $ git add *
[cicd-buzz] $ git commit -m "Initial commit"
[cicd-buzz] $ git remote add origin [email protected]:<YOUR_GITHUB_USERNAME>/cicd-buzz.git
[cicd-buzz] $ git push -u origin master

Шаг № 4: для выполнения тестов после каждого коммита подключаем Travis CI

Travis CI — это облачный сервис Непрерывной интеграции (Continuous Integration). Для публичных GitHub-репозиториев он бесплатен. Чтобы получить аккаунт на Travis CI, достаточно посетить https://travis-ci.org и войти, используя учетные данные GitHub.

Включить сборку по каждому Push- и Pull-запросам репозитория в Travis CI очень просто. Для этого нужно лишь передвинуть переключатель, расположенный напротив репозитория cicd-buzz (нажмите на ‘Sync account’, если репозитория еще нет в списке):

Последний шаг процедуры активации Travis CI заключается в добавлении файла ‘.travis.yml’ в корневую директорию проекта. Для нашего buzz-генератора он должен содержать:

language: python
script:
  - python -m pytest -v

Добавьте этот файл в Git, сделайте коммит и отправьте изменения на Github:

[cicd-buzz] $ git add .travis.yml
[cicd-buzz] $ git commit -m "Add Travis CI configuration"
[cicd-buzz] $ git push

Перейдите в панель инструментов Travis CI. В скором времени Travis оповестит вас об изменении кода и начнет сборку/тестирование кода. В журнале вывода можно увидеть результаты unit-тестов:

Шаг № 5: добавляем в цепочку Better Code Hub

Теперь, когда у нас есть хорошо смазанный механизм, который постоянно проверяет работоспособность кода с помощью автоматизированных тестов, очень хочется сфокусироваться на функциональности и забыть про качество кода. Better Code Hub — это облачный сервис, который проверяет качество кода согласно 10 рекомендациям по созданию поддерживаемого современного кода. Better Code Hub постоянно контролирует результаты разработки (буквально каждый push на GitHub) и сообщает о ситуациях, когда качество кода находится под угрозой.

Better Code Hub, как и Travis CI, бесшовно интегрируется с GitHub. Чтобы прикрепить его к репозиторию, зайдите на https://bettercodehub.com и выберите кнопку входа с надписью ‘Free’.

После того как вы вошли под учетными данными для GitHub, откроется список ваших GitHub-репозиториев. Найдите ‘cicd-buzz’ и нажмите кнопку ‘Play’. Better Code Hub спросит, запустить ли анализ со стандартными настройками. Нажмите ‘Go’ и подождите несколько секунд, после чего на экране должен появиться отчет.

Верхняя часть отчета на Better Code Hub

Если вы хотите, чтобы Better Code Hub выполнял анализ после каждого Push- и Pull-запросов (как Travis CI), щелкните по иконке с изображением шестеренки и передвиньте переключатель:

Шаг № 6: Превращаем buzz-генератор в простое веб-приложение

Отлично! Теперь у нас есть цепочка непрерывной интеграции, проверяющая работоспособность и качество кода. Далее надо настроить непрерывное развертывание прошедшего тесты кода.

Поскольку мы будем разворачивать веб-приложение на Heroku, чтобы научить buzz-генератор принимать HTTP-запросы и выводить HTML, сделаем для него обертку на Python Flask. Добавьте в корневую директорию проекта файл ‘app.py’, содержащий такой код:

import os
import signal
from flask import Flask
from buzz import generator

app = Flask(__name__)

signal.signal(signal.SIGINT, lambda s, f: os._exit(0))

@app.route("/")
def generate_buzz():
    page = '<html><body><h2>'
    page += generator.generate_buzz()
    page += '</h2></body></html>'
    return page

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=os.getenv('PORT')) # port 5000 is the default

Также добавьте еще одну строку в ‘requirements.txt’:

pytest==3.0.6
Flask==0.12

И установите новую зависимость:

(venv) [cicd-buzz] $ pip install -r requirements.txt

Теперь веб-приложение может быть запущено следующей командой:

[cicd-buzz] $ python app.py
* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Откройте в браузере ссылку http://localhost:5000 и насладитесь результатами своего труда. Чтобы немного повеселиться, обновите страничку несколько раз.

Наконец, не забудьте добавить коммит и отправить изменения на GitHub:

[cicd-buzz] $ git add app.py
[cicd-buzz] $ git add requirements.txt
[cicd-buzz] $ git commmit -m "Step 5"
[cicd-buzz] $ git push

Теперь можно с удовольствием наблюдать, как Travis CI и Better Code Hub подхватывают эти изменения и проверяют код.

Step 7: Контейнеризируем приложение с помощью docker

Docker поможет сделать из нашего приложения легко разворачиваемый контейнер. Для простой программки на Python и Flask это может показаться избыточным, но развертывание кода в виде контейнеров дает множество преимуществ, которые становятся очевидными по мере развития и роста проекта.

Если Docker у вас уже установлен, добавьте в корневую директорию проекта ‘Dockerfile’ с таким содержимым:

FROM alpine:3.5
RUN apk add --update python py-pip
COPY requirements.txt /src/requirements.txt
RUN pip install -r /src/requirements.txt
COPY app.py /src
COPY buzz /src/buzz
CMD python /src/app.py

Следуя этим инструкциям, docker возьмет базовый образ alpine, установит Python и pip, а также установит наше веб-приложение. Последняя строка инструктирует docker запускать веб-приложение при запуске контейнера.

Теперь Docker-образ должен без проблем собираться и запускаться:

[cicd-buzz] $ docker build -t cicd-buzz .
[cicd-buzz] $ docker run -p 5000:5000 --rm -it cicd-buzz

Полюбуйтесь результатами:

CI/CD buzz-генератор, работающий в Docker-контейнере

Опять же, не забудьте сделать коммит и отправить изменения на GitHub:

[cicd-buzz] $ git add Dockerfile
[cicd-buzz] $ git commmit -m "Step 6"
[cicd-buzz] $ git push

Шаг № 8: публикация на Docker Hub

Публикация в реестре Docker-образов, таком как Docker Hub, упрощает развертывание контейнеров в различных окружениях и их откат на предыдущие версии. Для выполнения этого шага вам потребуется учетная запись на https://docker.com, а также файл ‘deploy_dockerhub.sh’ в новой директории ‘.travis’ в корне проекта:

#!/bin/sh
docker login -e $DOCKER_EMAIL -u $DOCKER_USER -p $DOCKER_PASS
if [ "$TRAVIS_BRANCH" = "master" ]; then
    TAG="latest"
else
    TAG="$TRAVIS_BRANCH"
fi
docker build -f Dockerfile -t $TRAVIS_REPO_SLUG:$TAG .
docker push $TRAVIS_REPO_SLUG

Travis CI будет выполнять этот скрипт в конце каждой сборки, создавая таким образом ее Docker-образ. Обратите внимание на 3 переменные окружения. Их можно определить на вкладке ‘settings’ репозитория ‘cicd-buzz’ в Travis CI:

Переменные окружения для Docker в Travis CI

Чтобы Travis CI публиковал образ на Docker Hub после каждого коммита в репозиторий GitHub, измените ‘.travis.yml’ следующим образом:

sudo: required

services:
  - docker

language: python

script:
  - python -m pytest -v

after_success:
  - sh .travis/deploy_dockerhub.sh

После создания коммита и отправки этих изменений на GitHub (а также ожидания, пока Travis CI закончит свою работу) у вас появится возможность запустить контейнер с buzz-генератором прямо с Docker Hub:

[cicd-buzz] $ docker run -p5000:5000 --rm -it <YOUR_DOCKER_USERNAME>/cicd-buzz:latest

Шаг № 9: развертывание на Heroku

Heroku — это облачная платформа для размещения небольших масштабируемых веб-приложений. Сервис предлагает бесплатный тарифный план, поэтому переходите по ссылке https://signup.heroku.com и регистрируйтесь, если еще не сделали этого раньше.

Установите консольное приложение Heroku Toolbelt и в корневой директории проекта выполните следующие команды:

[cicd-buzz] $ heroku login
[cicd-buzz] $ heroku create
Creating app… done, ⬢ fathomless-inlet-53225
https://fathomless-inlet-53225.herokuapp.com/ | https://git.heroku.com/fathomless-inlet-53225.git
[cicd-buzz] $ heroku plugins:install heroku-container-registry
[cicd-buzz] $ heroku container:login
[cicd-buzz] $ heroku container:push web
[cicd-buzz] $ heroku ps:scale web=1

После этого у вас должна появиться возможность получить доступ к приложению по URL, выведенному командой heroku create.

CI/CD buzz-генератор, работающий на Heroku

Обратите внимание, что команда heroku container:push web размещает на Heroku тот же самый контейнер, который мы опубликовали на Docker Hub.

Чтобы автоматизировать процесс развертывания каждой сборки ветки master нашего проекта, добавьте файл ‘deploy_heroku.sh’ в директорию ‘.travis’:

#!/bin/sh
wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh
heroku plugins:install heroku-container-registry
docker login -e _ -u _ --password=$HEROKU_API_KEY registry.heroku.com
heroku container:push web --app $HEROKU_APP_NAME

Также добавьте следующую строку в файл ‘.travis.yml’:

after_success:
  — sh .travis/deploy_dockerhub.sh
  — test “$TRAVIS_BRANCH” = “master” && sh .travis/deploy_heroku.sh

Наконец, добавьте еще две переменные окружения в Travis CI. Heroku API можно найти в ‘Account Settings’, а heroku App name — в выводе команды heroku create.

Создайте коммит и отправьте изменения на GitHub. Новый Docker-образ после успешной сборки должен сразу попасть на Docker Hub и Heroku.

Шаг № 10: CI/CD для победы!

Теперь, когда у нас настроена современная цепочка разработки, можно начинать поставлять функциональность небольшими порциями, выполняя короткие итерации. Например, если мы решим сделать landing-страницу более привлекательной, типовой рабочий процесс будет выглядеть следующим образом:

1. Начните с создания новой задачи: https://github.com/robvanderleek/cicd-buzz/issues/1.
2. Создайте для этой задачи feature-branch: https://github.com/robvanderleek/cicd-buzz/tree/issue-1.
3. Здесь происходит магия кодирования.
4. Следите за сообщениями от Travis CI и Better Code Hub: https://github.com/robvanderleek/cicd-buzz/commits/issue-1.
5. Проверьте свое приложение локально, запустив самый свежий Docker-образ: docker run --rm -p5000:5000 -it robvanderleek/cicd-buzz:issue-1. Вы можете поделиться этим образом с другими людьми.
6. Если вы довольны новой функциональностью, откройте Pull Request. Теперь ваш код готов быть доставленным в production по цепочке CI/CD: https://github.com/robvanderleek/cicd-buzz/pull/2.

Ветка репозитория buzz-генератора в локальном Docker-контейнере

Счастливого кодинга и отгрузки в production!

Ссылки:

1. Оригинал: How to build a modern CI/CD pipeline
   
   using free and hosted services.
2. Репозиторий проекта на GitHub.

Что такое CI и зачем его использовать?

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

Что такое CI?

Прежде всего, что означает CI? Это означает непрерывную интеграцию. Непрерывная интеграция — это, по сути, практика, при которой вы объединяете работу всех своих разработчиков несколько раз в день. Каждая интеграция проверяется вашими автоматизированными тестами и строится (когда это необходимо, в основном для компилируемых языков).

Однако в наши дни «CI» обычно относится к серверной части процесса, где вы запускаете свои тесты и создаете свое приложение.

Зачем использовать CI?

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

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

CI-сервер обычно сообщает вам, все ли в порядке («зеленая» сборка) или вы что-то сломали («красная» сборка).Вы не хотите ломать сборку, но если вы это сделаете, вам нужно исправить это.

GitHub теперь обеспечивает хорошую интеграцию с CI. Вот примеры красных и зеленых сборок:

А как насчет непрерывного развертывания / доставки?

Большинство серверов CI теперь также могут выполнять непрерывное развертывание. Что такое непрерывное развертывание? Это последний штрих, чтобы двигаться еще быстрее. Вы можете настроить свой CI-сервер на развертывание программного обеспечения после каждой зеленой сборки, обычно это ветка master (с Git).Это может означать отправку кода / сборки на все ваши серверы, резервное копирование базы данных, запуск миграции базы данных, а затем перезапуск всего, что необходимо перезапустить, без какого-либо вмешательства человека.

Как мы используем CI в Rainforest

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

Запрос на вытягивание

Что происходит ежедневно — фактически много раз в день — это мы пишем код для функции или исправления ошибки. Мы делаем это в функциональной ветке. Когда это будет сделано, мы отправляем нашу ветку на GitHub и создаем запрос на перенос. Каждый запрос на вытягивание запускает сборку в Circle CI. После проверки кода одним или несколькими инженерами, когда у нас будет зеленая сборка, мы знаем, что слияние безопасно. Если сборка дает сбой, ее не следует объединять до исправления.

После слияния с ветвью development можно начать полностью автоматизированный процесс контроля качества и развертывания.

Развертывание

Процесс контроля качества и развертывания начинается с другого запроса на вытягивание к главному устройству из ветви разработки . Этот PR релиза важен, так как именно здесь мы запускаем наши тесты Rainforest. По сути, Circle CI получит обычную ловушку, но для этой ветки после того, как сборка станет зеленой для наших модульных тестов, мы развертываем в нашей промежуточной среде и среде QA, а затем запускается запуск Rainforest. Кстати, мы объяснили, как сделать эту интеграцию в предыдущем посте.Как только наш пробег в Rainforest завершен и станет зеленым, мы знаем, что его можно безопасно использовать.

В качестве последнего шага слияние этого пулреквеста с нашей ветвью master запустит процесс развертывания в Circle CI, подтолкнув его к производству.

Заключение

Как видите, для обеспечения качества (модульные тесты + контроль качества в нескольких браузерах) или развертывания было очень мало человеческого взаимодействия. Весь этот процесс позволяет нам двигаться быстро и быть уверенными в том, что мы отправляем, будь то на уровне единицы или для любого теста Rainforest, который у нас есть, тестирования с несколькими браузерами.

CI — это клей, обеспечивающий эффективность процесса. Мы думаем, что это идеальный рабочий процесс. Я рекомендую вам установить CI-сервер и начать поставки быстрее и спокойнее.

Надеюсь, это поможет вам максимально упростить процесс развертывания. Чтобы получить дополнительные советы от экспертов по более эффективному внедрению CI и CD, загрузите нашу бесплатную электронную книгу Getting to Continuous Deployment.

Спасибо за чтение!

Несколько инструментов

Итак, теперь, когда вы убедились, с чего начать? Это зависит от ваших потребностей и бюджета, но вот несколько из самых популярных вариантов.

Размещено:

Самостоятельно:

.

Что такое CI / CD? | Opensource.com

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

Краткое описание

Сборочная линия на заводе производит товары народного потребления из сырья быстрым, автоматизированным и воспроизводимым способом.Точно так же конвейер доставки программного обеспечения производит выпуски из исходного кода быстрым, автоматизированным и воспроизводимым способом. Общая схема того, как это делается, называется «непрерывной доставкой». Процесс, запускаемый с конвейера, называется «непрерывной интеграцией». Процесс, обеспечивающий качество, называется «непрерывным тестированием», а процесс, который делает конечный продукт доступным для пользователей, называется «непрерывным развертыванием». А эксперты по общей эффективности, которые заставляют все работать гладко и просто для всех, известны как практики DevOps.

Что означает «непрерывный»?

Continuous используется для описания множества различных процессов, которые следуют методам, которые я описываю здесь. Это не значит «всегда бегать». Это действительно означает «всегда готов к работе». В контексте создания программного обеспечения он также включает несколько основных концепций / передовых практик. Это:

• Частые выпуски: Целью непрерывных практик является обеспечение доставки качественного программного обеспечения через частые промежутки времени. Частота здесь варьируется и может определяться командой или компанией.Для некоторых продуктов раз в квартал, месяц, неделю или день может быть достаточно. Для других может быть желательным и выполнимым несколько раз в день. Непрерывный также может принимать вид «случайного, по мере необходимости». Конечная цель та же: доставлять высококачественные обновления программного обеспечения конечным пользователям в повторяемом и надежном процессе. Часто это может быть сделано практически без взаимодействия или даже без знания пользователей (подумайте об обновлениях устройства).

• Автоматизированные процессы: Ключевой частью обеспечения такой частоты является наличие автоматизированных процессов для обработки почти всех аспектов производства программного обеспечения.Это включает сборку, тестирование, анализ, управление версиями и, в некоторых случаях, развертывание.

• Повторяемый: Если мы используем автоматизированные процессы, которые всегда имеют одно и то же поведение при одинаковых входных данных, тогда обработка должна быть повторяемой. То есть, если мы вернемся и введем ту же версию кода в качестве входных данных, мы должны получить тот же набор результатов. Это также предполагает, что у нас есть те же версии внешних зависимостей (то есть другие не создаваемые нами результаты, которые использует наш код).В идеале это также означает, что для процессов в наших конвейерах можно создавать версии и заново создавать (см. Обсуждение DevOps позже).

• Быстрая обработка: «Быстрая» — здесь относительный термин, но независимо от частоты обновлений / выпусков программного обеспечения ожидается, что непрерывные процессы будут эффективно обрабатывать изменения от исходного кода к конечным продуктам. Автоматизация берет на себя большую часть этого, но автоматизированные процессы могут быть медленными. Например, интегрированное тестирование всех аспектов продукта, которое занимает большую часть дня, может быть слишком медленным для обновлений продукта, в которых есть новый выпуск-кандидат несколько раз в день.

Что такое «конвейер непрерывной доставки»?

Различные задачи и задания, связанные с преобразованием исходного кода в готовый к выпуску продукт, обычно объединяются в программный «конвейер», где успешное завершение одного автоматического процесса запускает следующий процесс в последовательности. Такие конвейеры называются по-разному, например конвейер непрерывной доставки, конвейер развертывания и конвейер разработки программного обеспечения. Общее приложение супервизора управляет определением, запуском, мониторингом и отчетностью по различным частям конвейера по мере их выполнения.

Как работает конвейер непрерывной доставки?

Реальная реализация конвейера доставки программного обеспечения может широко варьироваться. Существует большое количество и разнообразие приложений, которые могут использоваться в конвейере для различных аспектов отслеживания источников, построения, тестирования, сбора метрик, управления версиями и т. Д. Но общий рабочий процесс в целом один и тот же. Одно приложение оркестровки / рабочего процесса управляет общим конвейером, и каждый из процессов выполняется как отдельное задание или управляется этим приложением по этапам.Обычно отдельные «задания» определяются в синтаксисе и структуре, которые приложение оркестрации понимает и может управлять как рабочий процесс.

Задания создаются для выполнения одной или нескольких функций (сборка, тестирование, развертывание и т. Д.). Каждая работа может использовать разные технологии или несколько технологий. Ключ в том, что работа автоматизирована, эффективна и воспроизводима. Если задание выполнено успешно, приложение диспетчера рабочих процессов запускает следующее задание в конвейере. Если задание не удается, менеджер рабочего процесса предупреждает разработчиков, тестировщиков и других, чтобы они могли исправить проблему как можно быстрее.Благодаря автоматизации ошибки могут быть обнаружены намного быстрее, чем при выполнении набора ручных процессов. Такая быстрая идентификация ошибок называется «быстрой ошибкой» и может быть столь же полезной для достижения конечной точки конвейера.

Что означает «быстро сбой»?

Одна из задач конвейера — быстрая обработка изменений. Другой — отслеживать различные задачи / задания, которые создают релиз. Поскольку код, который не компилируется или не проходит тест, может задержать конвейер, важно, чтобы пользователи были быстро уведомлены о таких ситуациях.Под быстрым отказом понимается идея о том, что конвейерная обработка обнаруживает проблемы как можно скорее и быстро уведомляет пользователей, чтобы проблемы можно было исправить, а код повторно отправить для следующего прогона по конвейеру. Часто процесс конвейера может смотреть на историю, чтобы определить, кто внес это изменение, и уведомить человека и его команду.

Должны ли быть автоматизированы все части конвейера непрерывной доставки?

Почти все части трубопровода должны быть автоматизированы. Для некоторых частей может иметь смысл иметь место для человеческого вмешательства / взаимодействия.Примером может служить приемочное тестирование пользователей (когда конечные пользователи опробуют программное обеспечение и убедятся, что оно делает то, что они хотят / ожидают). Другим случаем может быть развертывание в производственной среде, где группы хотят иметь больший контроль со стороны человека. И, конечно же, требуется вмешательство человека, если код неправильный и ломается.

Имея это представление о значении непрерывной обработки, давайте рассмотрим различные типы непрерывной обработки и их значение в контексте программного конвейера.

Что такое непрерывная интеграция?

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

Цель CI — быстро убедиться, что новое изменение от разработчика «хорошее» и подходит для дальнейшего использования в кодовой базе.

Как работает непрерывная интеграция?

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

Как непрерывная интеграция обнаруживает изменения?

В наши дни процесс наблюдения обычно представляет собой приложение, подобное Jenkins, которое также управляет всеми (или большинством) процессов, выполняемых в конвейере, и отслеживает изменения в качестве одной из своих функций.Приложение для наблюдения может отслеживать изменения несколькими способами. К ним относятся:

• Опрос: Программа мониторинга постоянно спрашивает систему управления исходным кодом: «Есть ли у вас что-нибудь новое в интересующих меня репозиториях?» Когда в системе управления исходным кодом появляются новые изменения, программа мониторинга «просыпается» и выполняет свою работу по извлечению нового кода и его компоновке / тестированию.

• Периодичность: Программа мониторинга настроена на периодический запуск сборки независимо от того, есть ли изменения или нет.В идеале, если нет изменений, то ничего нового не строится, так что это не добавляет дополнительных затрат.

• Push: Это обратная проверка приложения мониторинга с помощью системы управления источниками. В этом случае система управления исходным кодом настроена на «отправку» уведомления приложению мониторинга, когда изменение фиксируется в репозитории. Чаще всего это можно сделать в форме «веб-перехватчика» — программы, которая «подключается» к запуску, когда добавляется новый код, и отправляет уведомление через Интернет в программу мониторинга.Чтобы это работало, программа мониторинга должна иметь открытый порт, который может получать информацию о веб-перехватчике через Интернет.

Что такое «предварительные проверки» (также известные как предполетные проверки)?

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

В качестве примера, инструмент под названием Gerrit позволяет проводить формальные проверки кода, проверки и тестовые сборки после того, как разработчик отправил код, но до того, как он будет разрешен в (удаленный Git) репозиторий. Геррит находится между рабочим пространством разработчика и удаленным репозиторием Git. Он «улавливает» запросы от разработчика и может выполнять проверки типа «прошел / не прошел», чтобы убедиться, что они прошли, прежде чем им будет разрешено попасть в репозиторий.Это может включать обнаружение предлагаемого изменения и запуск тестовой сборки (форма CI). Это также позволяет группам проводить формальные проверки кода на этом этапе. Таким образом, появляется дополнительная мера уверенности в том, что изменение ничего не сломает, когда оно будет объединено с базой кода.

Что такое «модульные тесты»?

Модульные тесты (также известные как «тесты фиксации») — это небольшие специализированные тесты, написанные разработчиками для обеспечения изолированной работы нового кода. «Изолированно» здесь означает отсутствие зависимости от другого кода, к которому нет прямого доступа, а также не зависящих от внешних источников данных или других модулей.Если такая зависимость требуется для запуска кода, эти ресурсы могут быть представлены mocks . Моки относятся к использованию заглушки кода, которая выглядит как ресурс и может возвращать значения, но не реализует никаких функций.

В большинстве организаций разработчики несут ответственность за создание модульных тестов, чтобы доказать, что их код работает. Фактически, одна модель (известная как разработка через тестирование [TDD]) требует, чтобы сначала были разработаны модульные тесты как основа для четкого определения того, что должен делать код.Поскольку такие изменения кода могут быть быстрыми и многочисленными, они также должны выполняться быстро.

Поскольку они относятся к рабочему процессу непрерывной интеграции, разработчик создает или обновляет исходный код в своей локальной рабочей среде и использует модульные тесты, чтобы убедиться, что вновь разработанная функция или метод работает. Обычно эти тесты принимают форму утверждения, что заданный набор входных данных для функции или метода производит заданный набор выходных данных. Обычно они проводят тестирование, чтобы гарантировать, что условия ошибки правильно помечены и обработаны.Доступны различные среды модульного тестирования, такие как JUnit для разработки на Java.

Что такое непрерывное тестирование?

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

Помимо этого, существуют различные формы тестирования, которые могут / должны выполняться.Сюда могут входить:

• Интеграционное тестирование подтверждает, что все группы компонентов и сервисов работают вместе.

• Функциональное тестирование подтверждает, что результат выполнения функций в продукте соответствует ожиданиям.

• Приемочные испытания измеряют некоторые характеристики системы по приемлемым критериям. Примеры включают производительность, масштабируемость, нагрузку и емкость.

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

Какие еще виды валидации можно проводить с кодом в конвейере, помимо тестирования?

В дополнение к аспектам тестов «годен / не годен» существуют приложения, которые также могут сообщать нам количество строк исходного кода, которые выполняются (покрываются) нашими тестовыми примерами.Это пример метрики, которую можно вычислить в исходном коде. Этот показатель называется охватом кода и может быть измерен с помощью инструментов (таких как JaCoCo для исходного кода Java).

Существует множество других типов показателей, таких как подсчет строк кода, измерение сложности и сравнение структур кодирования с известными шаблонами. Такие инструменты, как SonarQube, могут проверять исходный код и вычислять эти показатели. Помимо этого, пользователи могут устанавливать пороговые значения для того, какие диапазоны они готовы принять как «проходящие» для этих показателей.Затем обработка в конвейере может быть настроена для проверки вычисленных значений на соответствие пороговым значениям, и если значения выходят за пределы допустимого диапазона, обработку можно остановить. Такие приложения, как SonarQube, легко настраиваются и могут быть настроены для проверки только тех вещей, которые интересуют команду.

Что такое непрерывная доставка?

Непрерывная доставка (CD) обычно относится к общей цепочке процессов (конвейеру), которая автоматически получает изменения исходного кода и запускает их через сборку, тестирование, упаковку и связанные операции для создания развертываемой версии, в основном без какого-либо вмешательства человека.

Целями CD при производстве выпусков программного обеспечения являются автоматизация, эффективность, надежность, воспроизводимость и проверка качества (посредством непрерывного тестирования).

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

Как несколько версий идентифицируются / отслеживаются в конвейерах?

Управление версиями — ключевая концепция при работе с CD и конвейерами. Непрерывный подразумевает возможность частой интеграции нового кода и предоставления обновленных выпусков. Но это не означает, что всем всегда нужно «самое последнее и самое лучшее». Это может быть особенно актуально для внутренних команд, которые хотят разработать или протестировать известный стабильный выпуск. Таким образом, важно, чтобы конвейер версировал объекты, которые он создает, и мог легко хранить и получать доступ к этим управляемым объектам.

Объекты, созданные в конвейерной обработке из исходного кода, обычно можно называть артефактами . При создании артефактов к ним должны быть применены версии. Рекомендуемая стратегия присвоения артефактам номеров версий называется семантическим управлением версиями. (Это также относится к версиям зависимых артефактов, полученных из внешних источников.)

Семантические номера версий состоят из трех частей: основной, дополнительной и патч. (Например, 1.4.3 отражает основную версию 1, вспомогательную версию 4 и версию исправления 3.) Идея состоит в том, что изменение одной из этих частей представляет собой уровень обновления артефакта. Старшая версия увеличивается только при несовместимых изменениях API. Дополнительная версия увеличивается, когда функциональность добавляется обратно совместимым способом. Версия патча увеличивается, когда исправляются обратно совместимые ошибки. Это рекомендуемые руководящие принципы, но команды могут свободно отклоняться от этого подхода, если они делают это последовательным и понятным образом в рамках всей организации.Например, число, которое увеличивается каждый раз, когда выполняется сборка для выпуска, может быть помещено в поле патча.

Как «продвигаются» артефакты?

Команды могут назначать «уровень» продвижения артефактам, чтобы указать их пригодность для тестирования, производства и т. Д. Существуют различные подходы. Такие приложения, как Jenkins или Artifactory, могут быть включены для продвижения. Или простая схема может заключаться в добавлении метки в конец строки версии. Например, -snapshot может указывать на то, что для создания артефакта использовалась последняя версия (снимок) кода.Различные стратегии или инструменты продвижения могут использоваться для «продвижения» артефакта на другие уровни, такие как -milestone или -production , как показатель стабильности артефакта и его готовности к выпуску.

Как хранятся и доступны несколько версий артефактов?

Артефакты с поддержкой версий, созданные из исходного кода, могут храниться с помощью приложений, управляющих «репозиториями артефактов». Репозитории артефактов похожи на управление исходным кодом для построенных артефактов. Приложение (например, Artifactory или Nexus) может принимать артефакты с поддержкой версий, хранить и отслеживать их, а также предоставлять способы их получения.

Пользователи

Pipeline могут указать версии, которые они хотят использовать, и заставить конвейер извлекать эти версии.

Что такое непрерывное развертывание?

Непрерывное развертывание (CD) относится к идее возможности автоматически взять выпуск кода, вышедший из конвейера CD, и сделать его доступным для конечных пользователей. В зависимости от того, как код «устанавливается» пользователями, это может означать автоматическое развертывание чего-либо в облаке, предоставление доступа к обновлению (например, для приложения на телефоне), обновление веб-сайта или просто обновление списка доступных выпусков. .

Важным моментом здесь является то, что возможность непрерывного развертывания не означает, что каждый набор результатов, выходящих из конвейера, развертывается всегда. Это действительно означает, что посредством конвейера каждый набор результатов может быть «развернут». Это в значительной степени достигается за счет последовательных уровней непрерывного тестирования (см. Раздел «Непрерывное тестирование» в этой статье).

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

Какими способами можно протестировать развертывание перед полным развертыванием для всех пользователей?

Поскольку необходимость отката / отмены развертывания для всех пользователей может быть дорогостоящей ситуацией (как с технической точки зрения, так и с точки зрения пользователей), были разработаны многочисленные методы, позволяющие «опробовать» развертывание новых функций и легко «отменить» их, если проблемы обнаружены. К ним относятся:

Синий / зеленый Тестирование / развертывание

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

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

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

Аналогичным образом, если проблема обнаружена в последнем развертывании, а предыдущий производственный экземпляр все еще развернут в другой среде, простое изменение может направить клиентский трафик обратно на предыдущий производственный экземпляр, эффективно переводя экземпляр с проблемой в автономный режим. и откат к предыдущей версии.Затем новое развертывание с проблемой может быть исправлено в другой области.

Canary тестирование / развертывание

В некоторых случаях замена всего развертывания через сине-зеленую среду может оказаться невыполнимой или нежелательной. Другой подход известен как тестирование / развертывание canary . В этой модели часть клиентского трафика перенаправляется на новые части продукта. Например, новая версия службы поиска в продукте может быть развернута вместе с текущей производственной версией службы.Затем 10% поисковых запросов могут быть перенаправлены на новую версию для тестирования в производственной среде.

Если новая служба справляется с ограниченным трафиком без проблем, со временем к ней может быть направлено больше трафика. Если проблем не возникнет, то со временем объем трафика, направляемого на новую услугу, может быть увеличен до тех пор, пока на нее не попадет 100% трафика. Это эффективно «удаляет» предыдущую версию службы и вводит новую версию в действие для всех клиентов.

Переключение функций

Для новых функций, от которых может потребоваться легко отказаться (в случае обнаружения проблемы), разработчики могут добавить переключатель функций .Это программный переключатель if-then в коде, который активирует код, только если установлено значение данных. Это значение данных может быть глобально доступным местом, которое развернутое приложение проверяет, чтобы увидеть, должно ли оно выполнять новый код. Если значение данных установлено, он выполняет код; если нет, то нет.

Это дает разработчикам возможность удаленного «аварийного отключения» для отключения новых функций, если проблема обнаружена после развертывания в производственной среде.

Темный запуск

В этой практике код постепенно тестируется / внедряется в производство, но изменения не видны пользователям (отсюда и «темное» имя).Например, в производственном выпуске некоторая часть веб-запросов может быть перенаправлена ​​службе, которая запрашивает новый источник данных. Эта информация может быть собрана при разработке для анализа — без предоставления пользователям никакой информации об интерфейсе, транзакции или результатах.

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

Что такое DevOps?

DevOps — это набор идей и рекомендуемых практик по упрощению совместной работы групп разработки и эксплуатации над разработкой и выпуском программного обеспечения. Исторически сложилось так, что группы разработчиков создавали продукты, но не устанавливали / развертывали их обычным и повторяемым образом, как это делали бы клиенты. Этот набор задач по установке / развертыванию (а также другие задачи поддержки) был оставлен операционным группам, чтобы разобраться в конце цикла.Это часто приводило к путанице и проблемам, поскольку оперативная группа вовлекалась в цикл на поздних этапах цикла и должна была заставить то, что им было дано, работать в короткие сроки. Кроме того, команды разработчиков часто оказывались в плохом положении — поскольку они недостаточно протестировали функциональность установки / развертывания продукта, они могли быть удивлены проблемами, возникающими в ходе этого процесса.

Это часто приводило к серьезному разъединению и отсутствию сотрудничества между группами разработки и эксплуатации.Идеалы DevOps отстаивают способы делать вещи, в которых задействованы как разработчики, так и операторы с начала цикла до конца, например CD.

Как CD пересекается с DevOps?

Конвейер CD — это реализация нескольких идеалов DevOps. Более поздние этапы продукта, такие как упаковка и развертывание, всегда можно выполнять при каждом запуске конвейера, а не ждать определенной точки в цикле разработки продукта. Кроме того, сотрудники, занимающиеся разработкой и эксплуатацией, могут четко видеть, когда что-то работает, а когда нет, от разработки до развертывания.Чтобы цикл конвейера CD был успешным, он должен проходить не только через процессы, связанные с разработкой, но и через процессы, связанные с операциями.

Перенесенный на следующий уровень, DevOps предлагает рассматривать даже инфраструктуру, реализующую конвейер, как код. То есть он должен быть автоматически подготовлен, отслеживаться, легко изменяться и порождать новый запуск конвейера, если он изменяется. Это можно сделать, реализовав конвейер как код.

Что такое «конвейер как код»?

Pipeline-as-code — это общий термин для создания конвейерных заданий / задач с помощью программного кода, точно так же, как разработчики работают с исходным кодом для продуктов.Цель состоит в том, чтобы реализация конвейера была выражена в виде кода, чтобы его можно было хранить вместе с кодом, просматривать, отслеживать с течением времени и легко запускать снова, если есть проблема и конвейер необходимо остановить. Это позволяет несколько инструментов, включая Jenkins 2.

Как DevOps влияет на инфраструктуру для производства программного обеспечения?

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

За прошедшие годы были разработаны приложения для стандартизации систем инициализации (установки и настройки). Кроме того, виртуальные машины были разработаны как программы, имитирующие компьютеры, работающие поверх других компьютеров.Этим виртуальным машинам требуется управляющая программа для их запуска в базовой хост-системе. И для работы им требуется собственная копия операционной системы.

Далее пришли контейнеры. Контейнеры, хотя и похожи по концепции на виртуальные машины, работают по-другому. Вместо того, чтобы требовать для запуска отдельную программу и копию ОС, они просто используют некоторые существующие конструкции ОС для выделения изолированного пространства в операционной системе. Таким образом, они ведут себя аналогично виртуальной машине, обеспечивая изоляцию, но не требуют дополнительных затрат.

Поскольку виртуальные машины и контейнеры создаются из сохраненных определений, их можно легко уничтожить и воссоздать заново, не влияя на хост-системы, в которых они работают.Это позволяет воспроизводимой системе запускать конвейеры. Кроме того, для контейнеров мы можем отслеживать изменения в файле определения, из которого они созданы, точно так же, как и для исходного кода.

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

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

.

Что такое непрерывная интеграция | Atlassian

Фундаментальная зависимость CI — это система контроля версий (VCS). Если в целевой базе кода для установки CI нет VCS, первым шагом будет установка VCS. Отсутствие VCS должно быть очень маловероятным для современных кодовых баз. Некоторые популярные системы контроля версий — Git, Mercurial и Subversion.

После того, как контроль версий будет установлен, следующим шагом будет поиск хостинг-платформы для контроля версий. Большинство современных инструментов хостинга с контролем версий имеют встроенную поддержку и функции для CI.Некоторые популярные хостинговые платформы для управления версиями — Bitbucket, Github и Gitlab.

После того, как в проекте был установлен контроль версий, необходимо добавить шаги утверждения интеграции. Самый ценный этап утверждения интеграции — это автоматические тесты. Добавление автоматических тестов в проект может иметь начальные накладные расходы. Необходимо установить среду тестирования, затем разработчики должны написать тестовый код и тестовые примеры.

Некоторые идеи для добавления других, менее дорогих механизмов утверждения CI — это средства проверки синтаксиса, средства форматирования стиля кода или сканирование уязвимостей зависимостей.После того, как вы настроили систему управления версиями с некоторыми шагами утверждения слияния, вы установили непрерывную интеграцию!

CI не является чисто инженерным бизнес-процессом. Остальные подразделения организации, маркетинга, продаж и продуктов также получат выгоду от конвейера CI. Продуктовым командам нужно будет подумать, как распараллелить выполнение одновременных потоков разработки. Продукт и инженеры будут тесно сотрудничать, чтобы определить квалификационные требования к функциональным возможностям, которые войдут в состав автоматизированного набора тестов.

Маркетинг и продажи смогут ссылаться на конвейер CI для координации усилий и мероприятий по коммуникациям с клиентами. CI обеспечивает прозрачность для остальной части организации того, как продвигается выполнение инженерных работ. Эта утилита для обеспечения прозрачности и коммуникаций прекрасно интегрируется с гибким рабочим процессом разработки проектов.

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

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

Существует множество инструментов сторонних производителей, помогающих в управлении и установке CI. Есть много вариантов на выбор. Некоторые популярные варианты: Codeship, Bitbucket Pipelines, SemaphoreCI, CircleCI, Jenkins, Bamboo, Teamcity и многие другие. У этих инструментов есть собственные подробные руководства по настройке и документация, которые помогут начать работу.

Некоторые из лучших инструментов CI предоставляются Atlassian. Bitbucket pipelines и Bamboo — отличные утилиты для ускорения проекта с использованием современных функций CI.Jira — один из самых популярных в мире инструментов для управления гибкими проектами. Jira тесно интегрируется с другими проектами Bitbucket и в сочетании с конвейером CI может дать очень прозрачное представление о состоянии выполнения в организации.

.

Что означает CI?

:

000 CI:

0003

0004

Преступное намерение 9000 8

Правительственный »Право и право

3

3

Cubic Разное »Единицы измерения

.