Что такое ci (continuous integration)

Continuous Delivery

Автоматизированная доставка новой версии программы к конечным пользователям.

CD-сервис берет код из основной ветки, собирает из него нечто, что следует доставить (например, Docker-контейнер) и отправляет потребителю. Если речь идет о веб-приложении — отправляет собранное приложение на сервер.

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

Зачем

Очевидно, что настройка CI/CD занимает время. Но это делается только один раз для проекта, зато ускоряет процесс разработки, программисты не отвлекаются на побочные задачи, исчезает одно место где можно ошибиться и допустить ошибку. Тематическая статья “Лучше день потерять”.

Выбор сервиса

Мы храним исходный код на GitHub, поэтому искали сервис легко интегрирующийся с ним

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

Travis CI

69$, одна запущенная задача, нет ограничений по времени;

• бесплатно, одна запущенная задача, 1000 минут в месяц;
• 50$, две запущенные задачи, нет ограничений по времени.

AppVeyor

59$, одна запущенная задача, нет ограничений по времени.

Недавно GitHub запустил свой CI/CD сервис — GitHub Actions. Он пока недоступен для организаций, но мы внимательно следим за его развитием, постоянно тестируем и в будущем планируем попробовать на каком-нибудь проекте. Было бы здорово отказаться от стороннего сервиса и получить всю функциональность внутри интерфейса GitHub.

Что именно делаем

Большая часть наших приложений написана на TypeScript. Он легко поддается статическому анализу, и мы пользуемся этим по максимуму.

Используем ESLint и Stylelint. Чтобы не заботиться о переносе конфигурации между проектами, используем @solid-soda/scripts — это пакет, который прячет внутрь себя настройки всех инструментов.

Автоматические тесты тоже запускаются на каждое изменение кода. Наши приложения не покрыты тестами на 100%. Но мы пишем много юнит-тестов на функции в которых легко допустить ошибку. Недавно начали внедрять тесты на основе свойств и е2е-тестирование.

Прежде чем код попадет в мастер-ветку запускаются все возможные проверки. Так мы находим потенциальные проблемы и уязвимости до попадания кода в общую кодовую базу.

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

Как именно делаем

В этом разделе будет много штук специфичных для JavaScript, если вы используете другие технологии — поищите в интернете аналоги. Все примеры будут тесно связаны с CircleCI, если вы используете другой сервис — поищите в интернете аналоги.

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

Spinnaker

Spinnaker is a multi-cloud continuous delivery platform that supports releasing and deploying software changes across different cloud providers, including AWS EC2, Kubernetes, Google Compute Engine, Google Kubernetes Engine, Google App Engine, etc.

Spinnaker key features:

• Creates deployment pipelines that run integration and system tests, spin up and down server groups, and monitor rollouts. Trigger pipelines via Git events, Jenkins, Travis CI, Docker, cron, or other Spinnaker pipelines
• Create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues
• Tie your releases to monitoring services such as Datadog, Prometheus, Stackdriver, or SignalFx, using their metrics for canary analysis
• Install, configure, and update your Spinnaker instances with Halyard – Spinnaker’s CLI administration tool
• Set up event notifications for email, Slack, HipChat, or SMS (via Twilio)

License: Open-source

CI в тестировании

Если мы говорим о разработке своего приложения, то тестирование входит в стандартный цикл. Вы или ваши разработчики пишут автотесты, которые потом гоняет CI. Это могут быть unit, api, gui или нагрузочные тесты.
Но что, если вы тестируете черный ящик? Приложение есть, исходного кода нету. Это суровые реалии тестировщиков интеграции — поставщик отдает вам новый релиз приложения, который нужно проверить перед тем, как ставить в продакшен.
Вот, допустим, у вас есть API-тесты в Postman-е. Или GUI-тесты в Selenium. Можно ли настроить цикл CI для них?
Конечно, можно!
CI не ставит жестких рамок типа «я работаю только в проектах с автотестами» или «я работаю только когда есть доступ к исходному коду». Он может смотреть в систему контроля версий, а может и не смотреть. Это необязательное условие!
Написали автотесты? Скажите серверу CI, как часто их запускать — и наслаждайтесь результатом =)

Изоляция и защита среды CI/CD

С точки зрения операционной безопасности система CI/CD отражает наиболее важную инфраструктуру для защиты

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

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

Требуемые стратегии изоляции и защиты зависят от топологии сети, инфраструктуры и требований к управлению и разработке

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

Continuous testing goes beyond test automation

Automated testing frameworks help quality assurance engineers define, execute, and automate various types of tests that can help development teams know whether a software build passes or fails. They include functionality tests that are developed at the end of every sprint and aggregated into a regression test for the entire application. These regression tests then inform the team whether a code change failed one or more of the tests developed across all functional areas of the application where there is test coverage.

A best practice is to enable and require developers to run all or a subset of regressions tests in their local environments. This step ensures that developers only commit code to version control after regression tests pass on the code changes.

Regression tests are just the start. Performance testing, API testing, static code analysis, security testing, and other testing forms can also be automated. The key is to be able to trigger these tests either through command line, webhook, or web service and that they respond with success or fail status codes.

Once testing is automated, continuous testing implies that the automation is integrated into the CI/CD pipeline. Some unit and functionality tests can be integrated into CI that flags issues before or during the integration process. Tests that require a full delivery environment such as performance and security testing are often integrated into CD and performed after builds are delivered to target environments.

Bamboo

Bamboo is a continuous integration server that automates the management of software application releases, thus creating a continuous delivery pipeline. Bamboo covers building and functional testing, assigning versions, tagging releases, deploying and activating new versions on production.

Bamboo key features:

• Supports up to 100 remote build agents 
• Run batches of tests in parallel and get feedback quickly
• Creates images and pushes into a registry
• Per-environment permissions that allow developers and testers to deploy to their environments on-demand while the production stays locked down
• Detects new branches in Git, Mercurial, SVN Repos and applies the main line’s CI scheme to them automatically
• Triggers build based on the changes detected in the repository. Pushes notifications from Bitbucket, a set schedule, the completion of another build or any combination thereof.

License: Bamboo pricing tiers are based on agents or “build slaves” rather than users. The more agents, the more processes it can run concurrently – either in the same build or different builds. 

Прекращение конвейера CI/CD в единственный способ развертывания в производственной среде

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

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

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

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

Конвейер защищает целостность как плановых обновлений, так и экстренных обновлений, призванных устранить текущие проблемы. Такое использование системы CI/CD также дает еще одну причину обеспечить .

CircleCI

CircleCI is a CI/CD tool that supports rapid software development and publishing. CircleCI allows automation across the user’s pipeline, from code building, testing to deployment. 

You can integrate CircleCI with GitHub, GitHub Enterprise, and Bitbucket to create builds when new code lines are committed. CircleCI also hosts continuous integration under the cloud-managed option or runs behind a firewall on private infrastructure.

CircleCI key features:

• Integrates with Bitbucket, GitHub, and GitHub Enterprise
• Runs builds using a container or virtual machine
• Easy debugging
• Automated parallelization
• Quick tests
• Personalized email, and IM notifications
• Continuous and branch-specific deployment
• Highly customizable
• Automated merging and custom commands for package uploading
• Fast setup and unlimited builds

License: Linux plans start with the option to run one job without parallelism at no charge. Open-source projects get three additional free containers. During signup, you will see the pricing to decide which plan(s) you need.

Как методы непрерывной интеграции и разработки через тестирование вписываются в практику гибкой разработки

Сегодня большинство людей слышало о методах гибкой разработки. Идеи, которые они внесли в разработку программного обеспечения, изменили подход к организации работ, адаптации к меняющимся требованиям и выпуска программного обеспечения. Непрерывная интеграция предназначена для гибкой разработки, так что гибкий подход служит контекстом любых разговоров о CI. Она организует разработку с помощью функциональных пользовательских легенд (user stories). Этих легенды образуют отдельные группы задач, спринты (sprints).

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

По словам Мартина Фаулера из ThoughtWorks, непрерывная интеграция ― это практика разработки программного обеспечения, которая требует от членов группы частой интеграции их работы. Каждый занимается интеграцией, по крайней мере, ежедневно, что приводит к множеству актов интеграции в день. Интеграция проверяется путем автоматической сборки с прохождением регрессивных тестов для скорейшего выявления ошибок. Этот подход приводит к значительно меньшему числу проблем интеграции и позволяет разработкам быстрее согласовать свое программное обеспечение.

Так мы подходим к последней детали, которая делает процесс CI успешным. Если идея непрерывной интеграции ― быстро выявить проблемы, так чтобы каждый разработчик видел результат своей работы, то должен быть способ быстро оценить эту работу. Эту задачу решает разработка через тестирование. Вы создаете тест, и затем разрабатываете функциональность до тех пор, пока код этот тест не пройдет. При каждом дополнении к коду в набор тестов добавляются испытания для него, и этот набор применяется к результату. Это гарантирует, что дополнения не нарушат то, что уже сделано, а те разработчики, чей код «нарушает сборку», быстро узнают об этом. Типичное сочетание непрерывной интеграции и разработки через тестирование иллюстрируется на рисунке 1.

More than a process

Continuous Integration is backed by several important principles and practices.

The practices

• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Every commit should build on an integration machine
• Keep the build fast
• Test in a clone of the production environment
• Make it easy for anyone to get the latest executable version
• Everyone can see what’s happening
• Automate deployment

How to do it

• Developers check out code into their private workspaces
• When done, commit the changes to the repository
• The CI server monitors the repository and checks out changes when they occur
• The CI server builds the system and runs unit and integration tests
• The CI server releases deployable artefacts for testing
• The CI server assigns a build label to the version of the code it just built
• The CI server informs the team of the successful build
• If the build or tests fail, the CI server alerts the team
• The team fixes the issue at the earliest opportunity
• Continue to continually integrate and test throughout the project

Team responsibilities

• Check in frequently
• Don’t check in broken code
• Don’t check in untested code
• Don’t check in when the build is broken
• Don’t go home after checking in until the system builds

Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.

Continuous Deployment

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.

«Essentially, it is the practice of releasing every good build to users”, explains Jez Humble, author of Continuous Delivery.By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software.
With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fueling real change in your organization, and turning your release process into a business advantage.

TeamCity

TeamCity is a JetBrains’s build management and continuous integration server. 

TeamCity is a continuous integration tool that helps building and deploying different types of projects. TeamCity runs in a Java environment and integrates with Visual Studio and IDEs. The tool can be installed on both Windows and Linux servers, supports .NET and open-stack projects.

TeamCity 2019.1 provides a new UI and native GitLab integration. It also supports GitLab and Bitbucket server pull requests. The release includes token-based authentication, detection, reporting of Go tests, and AWS Spot Fleet requests.

TeamCity key features:

• Provides multiple ways to reuse settings and configurations of the parent project to the subproject
• Runs parallel builds simultaneously on different environments
• Enables running history builds, viewing test history reports, pinning, tagging, and adding builds to favorites
• Easy to customize, interact, and extend the server
• Keeps the CI server functional and stable 
• Flexible user management, user roles assignment, sorting users into groups, different ways of user authentication, and a log with all user actions for transparency of all activities on the server

License: TeamCity is a commercial tool with both free and proprietary licenses.

Поддержание высокой скорости конвейеров

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

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

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

Настройка CI/CD

Предварительный шаг

• мы перешли на git-flow. Оказалось, что наша кастомная vcs-workflow, по-сравнению с «классикой», избыточна и сложна, особенно для новичков;
• наш недельный спринт — это новая версия продукта. Каждая задача, будь то баг или фича, в таск-менеджере прикрепляется к конкретной версии. У каждого репозитория в конце спринта появляется тэг с новой версией, даже если именно в данной репе для данной версии ничего и не делали. Исключение, если ни один репозиторий из проекта за спринт не трогали;
• запретили напрямую пушить в ветки master, develop и release, только через пул-реквесты;
• повесили хук на пул-реквесты в вышеуказанные ветки для сборки и тестирования в Jenkins;
• запретили слияние пул-реквестов без удачного тестирования Jenkins’ом и без одобрения Code Review.

Второй шаг. Настройка дополнительного devops-репозитория

./projects/PROJECT/docker/ci-apicommand./ansible

• develop.yml — настройки по разворачиванию всего проекта локально;
• make-images.yml — создание docker-образов с определённой версией проекта и пуш в докер-registry;
• deploy-and-run-images.yml — разворачивание проекта на серверах с разным окружением.

./ansible/plays/group_vars/all.yml

• какие репозитории относятся к данному проекту;
• какой docker-registry использовать, какие логин-пароль к нему;
• индивидуальные настройки для каждого окружения и пр.

projectsdocker/releasedocker/developdocker/release

• возможность клонирования любого репозитория и запустить develop-версию
• каждый репозиторий проверяется Jenkins’ом;
• есть общий репозиторий, которая запускает интеграционные тесты по всем репозиториям по общей версии;
• ansible playbook: разворачивает локально и запускает все репозитории проекта в develop-режиме;
• ansible playbook: собирает образы в зависимости от выбранной схемы окружения и отправляет в докер-registry;
• ansible playbook: на сервере настраивает проект;
• ansible playbook: на сервере запускает приложение.

• todo_todo — форк с проекта todobackend.com. Изменил структуру и добавил тесты. Создаёт todo’шк;
• todo_crm — создаёт пользователей, отправляет запрос в todo_todo, создаёт todo и привязывает его к пользователю;
• todo_ops — devops-репозиторий с конфигами

Travis CI

Travis CI is a CI service used to build and test projects. Travis CI automatically detects new commits made and pushed to a GitHub repository. And after every new code commit, Travis CI will build the project and run tests accordingly.

The tool provides support for many build configurations and languages like Node, PHP, Python, Java, Perl, and so on.

Travis CI key features:

• Quick setup
• Live build views for GitHub projects monitoring
• Pull request support
• Deployment to multiple cloud services
• Pre-installed database services
• Auto deployments on passing builds
• Clean VMs for every build 
• Supports macOS, Linux, and iOS
• Supports multiple languages, such as Android, C, C#, C++, Java, JavaScript (with Node.js), Perl, PHP, Python, R, Ruby, and so on.

License

Travis CI is a hosted CI/CD service. Private projects can be tested on travis-ci.com on a fee basis. Open-source projects may be applied at no charge on travis-ci.org. 

Выполните только одну сборку и разверните результаты через конвейер

Основная цель конвейера CI/CD — обеспечить уверенность в изменениях и минимизировать вероятность непредвиденного негативного воздействия

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

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

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