Промышленное программирование

Системы сборки

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

Системы сборки

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

make

• make - вероятно, самая распространенная система сборки, предустанавливается на большинстве ОС семейства UNIX

• make можно посчитать достаточно простым, однако, с его помощью можно строить очень сложные сценарии сборки

• Цели, зависимости и правила описываются в Makefile

    paper.pdf: paper.tex plot-data.png
            pdflatex paper.tex
  
    plot-%.png: %.dat plot.py
            ./plot.py -i $*.dat -o $@
  

• Первая цель в Makefile - цель по умолчанию. Для ее сборки можно просто позвать make

• Можно позвать определенную цель: make plot-data.png

Управление зависимостями

• Современную разработку сложно представить без использования сторонних библиотек и инструментов
• Для версионирования зависимостей используется, зачастую, semantic versioning
• Сами зависимости распространяются через различные репозитории (pipy, npm, apt, brew, ...)
• Для разрешения зависимостей существует большое количество инструментов
• Обычно, зависимости указываются с некоторым набором ограничений - например, мажорная версия 1, минорная и фик версии - любые
• При этом у зависимостей так же могут быть зависимости, и, например, где-то будет указана необходимая минорная версия
• Обычно, кроме правил, есть фиксированный набор зависимостей (в lock файле), либо же определенные зависимости лежат уже рядом в репозитории

Continuous Integration

• Непрерывная интеграция - подход к разработке приложений, подразумевающий частое проведение сборок проекта и тестирование кода
• Цель — сделать процесс интеграции предсказуемым и обнаружить потенциальные баги и ошибки на ранней стадии, чтобы было больше времени на их исправление
• Впервые термин Continuous Integration появился в 1991 году (Гради Буч, создатель языка UML)
• Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем
• Позже в своей книге "Object-Oriented Analysis and Design with Applications" он сказал, что задача методики — ускорить выпуск «внутренних релизов»

Continuous Integration

• В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер
• Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl
• Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе

Continuous Integration

• Основу непрерывной интеграции составляют два инструмента — система контроля версий и CI-сервер
• Разработчики один или несколько раз в день загружают новый код
• CI-сервер автоматически копирует его со всеми зависимости и выполняет сборку и тестирование

Принципы CI

• Немедленно исправлять проблемы. Этот принцип пришёл в CI из экстремального программирования. Исправление багов — самая приоритетная задача разработчиков
• Автоматизировать процессы. Разработчики и менеджеры должны постоянно искать «узкие места» в процессе интеграции и устранять их. Например, часто «бутылочным горлышком» интеграции оказывается тестирование
• Проводить сборки как можно чаще. Раз в день, чтобы синхронизировать работу команды.

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

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

Инструменты CI

• Jenkins
• GitLab CI
• Drone CI
• Teamcity
• GitHub Actions

CI системы

GitHub Actions

• Workflow - автоматизированная процедура, добавляемая в репозиторий. Может состоять из нескольких задач, которые запускаются по какому-либо событию
• Event - специфичное событие, которое тригерит workflow. Список возможных событий
• Job - набор шагов, выполняемых последовательно или параллельно. Job может зависить от результата выполнения другой
• Step - индивидуальная задача, которая запускает команду (action). Данные от предыдущего шага доступны в последующих
• Action - набор шагов, который можно использовать как "кирпичик" в своем workflow
• Runner - сервер, на котором установлено соответствующее ПО для запуска задач. Может быть GitHub-hosted и self-hosted

GitHub Actions

    name: learn-github-actions
    on: [push]
    jobs:
    check-bats-version:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
    - run: npm install -g bats
    - run: bats -v

Continuous delivery

• Непрерывная поставка (Continuous Delivery) — это подход к разработке программного обеспечения, при котором все изменения, включая новые функции, изменения конфигурации, исправления ошибок и эксперименты, поставляются пользователям максимально быстро и безопасно
• Любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов
• Программист, избавившись практически от всей ручной работы, трудится продуктивнее

Continuous delivery

1. Разработчик отправляет свои изменения в систему контроля версии
2. На сервере сборки начинается процесс сборки поступивших изменений
3. Запускаются тесты
4. Собранный пакет после успешной интеграции выкладывается на тестовый сервер
5. Заинтересованные лица получают уведомления о выкладке новой версии ПО на тестовую площадку. Начинается вторая фаза тестирования, запускаются интеграционные, ручные, приемочные, UI тесты и тд
6. После успешного прохождения предыдущих шагов мы имеем готовый к публикации пакет новой версии ПО

Continuous delivery

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

Continuous deployment

• Непрерывное развертывание (deployment) располагается «на уровень выше» непрерывной доставки
• Все изменения, вносимые в исходный код, автоматически развертываются в продакшен, без явной отмашки от разработчика
• Как правило, задача разработчика сводится к проверке запроса на включение (pull request) от коллеги и к информированию команды о результатах всех важных событий
• Непрерывное развертывание требует, чтобы в команде существовала отлаженная культура мониторинга, все умели держать руку на пульсе и быстро восстанавливать систему

Continuous deployment

• Иногда возникает путаница, что означает аббревиатура «CD» в паре «CI/CD». Четкого ответа на этот вопрос нет, но в большинстве случаев эта пара понимается как «непрерывная интеграция и непрерывная доставка»
• Это логично, если учесть, что непрерывное развертывание – частный случай непрерывной доставки, применимый не в каждой системе

Docker

• Docker – open–source движок, автоматизирующий развертывание приложений в легковесные, переносимые, самодостаточные контейнеры, которые могут без изменений переноситься между серверами
• Он крайне легок в управлении, расширении, миграции и подходит для огромного спектра задач начиная от разработки приложений и сборки пакетов и заканчивая тестами-пятиминутками
• Тот же самый контейнер, который разработчик создает и тестирует на ноутбуке, может быть легко перенесен на продакшн-сервера в облако и так же легко смигрирован в другой регион при необходимости

Docker

• Docker — средство изоляции процесса(задачи), а это значит относиться к докеру как к виртуалке нельзя
• Но он имеет многие похожие фишки, как и у виртуализации: независимость (контейнер может быть перемещен на любую ОС с docker-службой на борту и контейнер будет работать) и самодостаточность (контейнер будет выполнять свои функции в любом месте, где бы его не запустили)
• Внутри контейнера находится минимально необходимый набор софта, необходимый для работы вашего процесса. Это уже не полноценная ОС, которую надо мониторить, следить за остатком места, ...
• Контейнер это инструмент обработки данных, но не инструмент их хранения. Данные не должны сохраняться внутри контейнера

Docker

• Контейнер живет, пока живет процесс, вокруг которого рождается контейнер
• Внутри контейнера этот процесс имеет pid=1
• Рядом с процессом с pid=1 можно порождать сколько угодно других процессов, но убив (рестартовав) именно процесс с pid=1, контейнер выходит
• Данные, создаваемые внутри контейнера остаются в контейнере и нигде более не сохраняются. Удалив контейнер — потеряете все ваши изменения. Поэтому данные в контейнерах не хранят, а выносят наружу, на хостовую ОС

Docker

• Docker – клиент-серверное приложение. Клиенты разговаривают с сервером (демоном), который непосредственно делает всю работу
• Для управления Docker можно использовать утилиту командной строки docker и RESTful API
• Можно запускать клиент и сервер на одном хосте или удаленно подключаться к Docker-серверу

Образы

• Свои контейнеры пользователь запускает из образов, которые являются частью процесса построения контейнера
• Docker хранит созданные вами образы в реестрах
• Существует два типа реестров: публичные и приватные. Официальный реестр называется Docker Hub
• Создав в нем аккаунт, можно сохранять свои образы в нем и делиться ими с другими пользователями

Контейнеры

• Контейнер - аналог процесса, только представляет собой приложение в совокупности. Контейнеры запускаются из образов
• Когда Docker запускает контейнер, слой для записи пуст. При изменениях они записываются в этот слой. Например при изменении файла он копируется в слой, доступный для записи (copy on write)

Dockerfile

• Описание шагов по построению образа
• Каждый шаг - новый слой
• Сборка образа - docker build -t [NAME]:[TAG] . (в директории с Dockerfile)

Docker compose

• Docker Compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов
• На практике реальные проекты состоят из большого количества связанных друг с другом контейнеров
• Технология Docker Compose, если описывать её упрощённо, позволяет, с помощью одной команды, запускать множество сервисов

Kubernetes

• Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров как единой системой
• Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров
• Предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение

Kubernetes

• Pod (под) - это группа из одного или более контейнера с общим хранилищем/сетевыми ресурсами и спецификацией как запускать контейнеры. Так же это отдельный инстанс приложения. Размещая контейнеры таким образом, Kubernetes устраняет соблазн втиснуть слишком много функций в один образ контейнера
• Service (Сервис) в Kubernetes используется для группирования нескольких подов, которые выполняют те же функции. Сервисы легко настраиваются для таких целей как обнаружение, горизонтальное масштабирование и балансировка нагрузки

Kubernetes

• Возможность обнаружения контейнеров
• Автоматическое развертывание и откаты
• Автоматическое распределение нагрузки
• Самоконтроль
• Управление секретами

Thank you