Содержание

DevOps

MVP (Minimal Viable Product) - быстро написанное ПО/сервис, минимально покрывающее поставленную задачу. Нужно для проверки, взлетит проект или нет.

Жизненный цикл ПО - от планирования до прекращения использования.

  1. Планирование, анализ (технический, экономический, подходы)
  2. Определение требований (спецификация ПО)
  3. Проектирование архитектуры
  4. Разработка
  5. Тестирование
  6. Развёртывание и поддержка

Модели разработки определяют стиль и подход, наиболее подходящие для того или иного проекта.

Книги:
Джефф Сазерленд - Scrum. Революционный метод управления проектами
Эндрю Стеллман, Дженнифер Грин - Постигая Agile: ценности, принципы и методологии

git (VCS, version control system)

VCS обеспечивает хранение версий ПО и вносимые изменения каждого разработчика. Соответственно, это позволяет их отслеживать, откатываться, делить на ветки. Децентрализация - каждый разраб скачивает репозиторий на свою тачку, и если сервер не работает, можно переехать на другой, загрузив туда код. Самые популярные системы - Github, Gitlab, Bitbucket.

Сохранение состояния проекта - как снапшот, на который делается ссылка.

Книги:
Скотт Шакон - Pro Git

Ветвления

Trunk-Based Development

Trunk-Based Development - частые мелкие изменения прямо в master. Ветки feature короткоживущие и ведутся чаще всего одним разработчиком.

Подходит для мелких проектов и небольших команд, или когда нужно что-то быстро написать (MVP).

Feature Branch Workflow

Feature Branch Workflow - новые функции разрабатываются отдельно от master (где всегда содержится рабочий код), ветки feature существуют долго, в рамках этих веток делаются pull-реквесты для совместной работы.

Gitflow

Gitflow - основная разработка ведётся в ветке develop, ветки feature делаются от неё и сливаются с ней же. Master - это история релизов с единственной производной от неё - hotfix, где правятся баги. После исправления ошибок hotfix сливается с master и develop. Когда в develop достаточно изменений для релиза, создаётся ветка release и там код допиливается без добавления новых функций и пишется документация, затем она сливается в master (и в develop) и ей присваивается версия, а ветка release удаляется.

https://bitworks.software/2019-03-12-gitflow-workflow.html

Gitlab flow

Разработка ведётся аналогично GitHub flow — в отдельных ветках, которые также сливаются в master, но содержимое ветки master развёрнуто на тестовом сервере. Дополнительно у вас есть ветки окружений, содержимое которых соответствует содержимому ваших окружений. Обычно существует три окружения, но их может быть больше или меньше в зависимости от ваших требований:

  1. Master/main - тестовое окружение
  2. Preprod - опытное окружение
  3. Prod - пром

https://habr.com/ru/companies/intersystems/articles/354158/

Использование веток релиза нужно, если ПО выпускается для внешних пользователей. В этом случае ветки нужно называть с использованием минорной версии, например, 2.3-stable или 2.4-stable.

Сливать изменения в тематических ветках нужно именно в мастер (не в релиз!), а потом делать cherry-pick оттуда в релизные ветки, иначе баг останется в следующих версиях, когда из непропатченной мастер-ветки создадут новый релиз.

Слияние с основной веткой и последующий cherry-pick в релизную называется «upstream first» policy. После cherry-pick в релизной ветке нужно увеличивать патч-версию, устанавливая новый тег.

Некоторые проекты также имеют ветку stable, которая указывает на тот же коммит, что и последняя ветка release. В этом случае не принято иметь ветку production.

Бережливое производство

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

Принципы:

  1. Сформулировать ценность
  2. Организовать процесс её создания (планирование, распределение обязанностей, разработка, тестирование и т. д.)
  3. Обеспечить бесперебойную работу над реализацией - все должны быть заняты делом, а не простаивать и ждать друг друга
  4. Не работать без запроса - «впрок», и «чтобы было»
  5. Постоянно работать над улучшением

Применительно к разработке тормозом являются ручное развёртывание, тестирование и прочие рутинные неавтоматизированные операции. Есть ряд сервисов по автоматизации сборки, тестирования и деплоя - Travis CI, GitLab CI, Drone CI, TeamCity, Buildbot, Bamboo, Jenkins и т. д.

Книги:

Какие проблемы решает DevOps

DevOps нацелен на решение следующих проблем:

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

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

Книги: «Руководство по DevOps» Джон Уллис, Патрик Дебуа

DevOps = бережливое производство + Agile. Есть несколько методологий Agile:

Scrum

  1. Разделение цели на конкретные задачи (user-story), расстановка приоритетов для них.
  2. Разделение времени работы группы на спринты (1-2 недели) и показ работы, сделанной за это время.
  3. Согласование с заказчиком приоритетов и планов по результатам работы прошедшего спринта.
  4. Улучшение процесса после каждого спринта.

Скрам подразумевает ритуалы - совещания в неизменном составе, где ставятся задачи.

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

Стендап - короткая ежедневная встреча в рамках группы. Каждый участник отвечает на вопросы:

  1. Что я сделал вчера?
  2. Что я собираюсь сделать сегодня?
  3. Есть ли проблемы, нужна ли мне помощь?

В конце спринта - 2 больших совещания: демонстрация сделанного и ретроспектива - закрытая встреча группы, работа над улучшением процессов.

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

Kanban

Визуализация этапов, доска, разделённая горизонтальными полосами.

Задача Разработка
Лимит 3
Выполнено Тестирование
Лимит 2
Протестировано Развёртывание
Лимит 2
Работает Завершено
7 4 5 2 3 1
8 6
9

Каждый стикер (задача) находится на определённом этапе. Лимит (WIP - work in progress) - это кол-во одновременно возможных задач на этапе, зависит от кол-ва участников и т. п.

3 пути DevOps

Поток создания ценности

  1. Работа должна быть на виду, процессы - прозрачными. Определение, где возникают проблемы (видно на доске Канбана).
  2. Постоянный поиск и решение проблем. Автоматизация.
  3. Уменьшать кол-во делегирований. Чтобы устранить перебрасывание задач и ожидание.
  4. Уменьшать кол-во незавершённой работы. Сократить постоянную дерготню и переключение с задачи на задачу до передачи её на следующий этап.
  5. Уменьшать объём самих задач. С ними легче справиться, их быстрее можно обработать.

Обратная связь

Необходима связь как с клиентом, так и между участниками группы. Мониторинг, доступность информации, оперативность. Чем быстрее поступит обратная связь - тем лучше, быстрее можно будет что-то исправить.

Научный подход к новациям и ошибкам

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

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

Ошибки можно делать в контролируемой среде и намеренно с целью выявить слабые места, например, для K8s есть kube-monkey. Ещё есть Canary deploy - тест новой версии на части пользователей (уменьшение репутационного и финансового риска, если релиз кривой).

Книги: «Руководство по DevOps» Джин Ким

5 идеалов

  1. Стремление к простоте - код, оргструктура и процессы не должны быть запутанно-сложными
  2. Удовольствие от работы, условия, дающие возможность сфокусироваться на достижении результата
  3. Постоянное совершенствование
  4. Психологическая безопасность - открытое обсуждение проблем и выработка механизма их предотвращения вместо поиска крайнего
  5. Внимание к нуждам заказчика, не забывая и о нуждах своей компании

История создания Agile-манифеста
Мастер-класс Бориса Вольфсона. Основы Agile

Проверка кода

Существуют стандарты оформления кода (code conventions) - это правила, которые направлены на облегчение понимания и поддержки кода. Например, PEP 8 (Style Guide for Python Code) или Google C++ Style Guide. Проверки можно проводить как локально в редакторе, так и централизованно в репозитории. Централизованная проверка может быть реализована как с помощью самого репозитория (например, в Gitlab), так и с помощью подключаемых сервисов (SonarQube, Codacy).

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

SonarQube

Популярный сервис проверки кода. Что умеет:

Как происходит анализ:

  1. Сканеры (analyzers) определяют, на чём написан код и отправляют его на сервер
  2. Правила (rules) на сервере проверяют проект. Есть предустановленные, но можно сделать свои под специфику проекта. Правила сгруппированы к профили качества (quality profiles) - это наборы правил. Можно добавить свои профили, добавив туда нужные правила
  3. К проекту применяется профиль качества и выставляется уровень качества (quality gate), из которого можно понять, можно выпускать релиз или нет. Уровень качества можно задать под свои требования, например, чтобы повторяющихся строк было не более 15%
  4. По результатам анализа высылается письмо или webhook

Sonarcube VS GitLab
SAST
Настройка DonarQube для Maven
Открытый SonarQube

Инфраструктура как код (IAC)

Инфраструктура как код (IAC, IAaC от англ. Infrastructure as a Code) — подход к управлению и описанию инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах. Процесс настройки инфраструктуры становится аналогичен процессу программирования ПО. Границы между написанием приложений и созданием сред для этих приложений стираются. Используя IAC мы получаем много преимуществ:

https://martinfowler.com/bliki/SnowflakeServer.html

Vagrant для гипервизора (на сентябрь 2022 закрыт для РФ).

Kief Morris - Infrastructure as code

Terraform - управление инфраструктурой

:!: Свободный аналог - Opentofu. https://opentofu.org/, https://github.com/opentofu/opentofu.

Скачать: https://hashicorp-releases.yandexcloud.net/terraform/

export PATH=$PATH:/path/to/terraform/executable

Файл для скачивания доп. компонентов с серверов Яндекса вместо родного сайта.

~/.terraformrc
provider_installation {
  network_mirror {
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Далее нужно настроить провайдер (провайдер - с чем работаем: AWS, Linode, K8s и т. д.).

# Справка
terraform --help
terraform apply --help
 
terraform fmt # форматирование файлов Terraform в текущем каталоге
terraform init # подготовка необходимого для работы в текущем каталоге (установка провайдеров, указанных в конфигурации)
terraform validate # проверка файлов Terraform на синтаксические ошибки
terraform plan # вывод плана изменений
terraform apply # применение изменений конфигурации инфраструктуры
terraform destroy # удаление инфраструктуры, описанной в текущем каталоге
terraform output # вывод значений переменных состояния
terraform show # текущее состояние инфраструктуры
terraform state # манипуляции с файлами состояния
terraform version # версия Terraform
 
# Шаги при работе с Terraform
terraform init → terraform validate → terraform plan → terraform apply → terraform destroy

Terraform best practices — how to structure your Terraform projects

Управление конфигурацией

Системы управления конфигурацией (SCM) появились из необходимости автоматизации процесса конфигурации серверов. Это контроль и отслеживание изменений в системе: версий установленных пакетов, файлов конфигурации, настроек ОС. По аналогии с программным кодом такую конфигурацию можно хранить в git и управлять этой конфигурацией по процессам разработки (pull requests, сode review, тестирование).

Задачи SCM (software configuration management):

Вместо скриптов и консольных команд, с которыми возникают проблемы при их применении на большом количестве серверов, есть инструменты, такие как Ansible, Puppet, Chef, SaltStack.

Задачи SCM (software configuration management):

Ansible Puppet Chef SaltStack
Язык Python, любой для модулей Ruby Ruby, Erlang Python, ZeroMQ
Манифест yaml свой формат Ruby DSL yaml
Агенты нет (SSH/WinRM) требуется требуется требуется, но есть возможность работать по SSH
Инфраструктура простая сложная средняя средняя
Популярность большая средняя средняя низкая
Сложность освоения невысокая средняя средняя средняя

Введение в системы управления конфигурацией

CI/CD

Continuous integration (CI):
Build [auto]→ Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests

Continuous Delivery (CD):
Build [auto]→ Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests [manual]→ Deploy (prod)

Continuous Deployment (CD):
Build [auto]→ Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests [auto]→ Deploy (prod)

SaaS

Software as a Service - приложение как сервис, находящееся в облаке.

12 факторов, как построить приложение SaaS-friendly (Twelve-factor app)

  1. База кода - одно приложение - один репозиторий. Разрабы могут создавать ветки (не репозитории) и деплоить на тестовые стенды. Приложение не собирается из нескольких репозиториев одновременно, но если нужно несколько, то они указываются как зависимости.
  2. Зависимости - они все должны быть прописаны, не надо надеяться, что они установлены по умолчанию. Версии тоже надо прописывать. Изоляция, чтобы избежать конфлоктов версий - virtualenv в питоне и контейнеры.
  3. Конфигурация - переменные для подключения ко внешним сервисам нужно хранить в конфигах, внешние подключения определяются в переменных.
  4. Сторонние службы - любые изменения, касающиеся сторонних служб, должны происходить без изменения кода приложения. Например, изменение хоста для подключения к внешней БД.
  5. Сборка, релиз, выполнение - любое изменение в коде должно пройти эти этапы (сборка - создание артефакта, релиз - соединение с конфигурацией под среду запуска, выполнение - запуск и работа в целевой среде). Релизы нужно помечать версией для простого отката в прошлой версии в случае чего.
  6. Процессы - так как приложение может быть в любой момент масштабировано, перезапущено и т. п., любая stateful-информация должна храниться вовне - s3, БД и так далее.
  7. Привязка портов - каждое приложение должно иметь собственный порт для связи с ним.
  8. Параллелизм - приложение должно уметь масштабироваться не только вертикально (добавлением ресурсов), но и горизонтально (запуском нескольких копий).
  9. Утилизируемость - приложение по-максимуму независимо от состояния (stateless), если оно что-то кэширует, то на минимальное время. Завершается по SIGTERM, быстро и без проблем.
  10. Минимальная разница тест/прод - если все тесты завершены успешно, новый код может быть разлит на прод через минимальное время. Разрабы имеют доступ к проду, видят результаты работы. Стенды теста и прода должны быть максимально одинаковыми.
  11. Логи - пишутся в stdout, а не в файл, т. к. в облаках обработкой логов будет заниматься внешний сервис.
  12. Администрирование - возможность подключения к работающему приложению и запуска скриптов, которые должны иметь возможность использования переменных окружения.

https://12factor.net/ru/
https://www.redhat.com/architect/12-factor-app