DevOps

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

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

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

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

Waterfall - поэтапная модель. Хорошо документировано и спланировано, но долго, и очень трудно/дорого внести изменения по ходу или откатиться на предыдущий этап. Применяется при строго фиксированном бюджете или на простых проектах.
V-модель - на каждом этапе параллельно проводится тестирование. Мало ошибок, но опять же долго и трудно/дорого менять план. Применяется при необходимости непрерывного функционирования разрабатываемого ПО.
Agile - работающий продукт важнее документация, взаимодействие людей важнее процессов, работа с заказчиком важнее условий контракта, изменения важнее плана.
Scrum - постоянные мелкие улучшения.

Книги:
Джефф Сазерленд - 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 развёрнуто на тестовом сервере. Дополнительно у вас есть ветки окружений, содержимое которых соответствует содержимому ваших окружений. Обычно существует три окружения, но их может быть больше или меньше в зависимости от ваших требований:

Master/main - тестовое окружение
Preprod - опытное окружение
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 - это постоянный поиск улучшения процессов и снижение количества ненужных и неэффективных действий. Важно определить ценность продукта - то, что решает ключевую потребность (проблему, задачу) потребителя, и сосредоточиться на ней. Например, ценность мессенджера - в передаче текстовых сообщений, а не в смайлах и стикерах, и т. п.

Принципы:

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

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

Книги:

Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании. Джеймс П. Вумек, Дэниел Джонс
Continuous delivery. Практика непрерывных апдейтов. Эберхард Вольф
Непрерывное развёртывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ. Джез Хамбл

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

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

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

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

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

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

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

Scrum

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

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

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

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

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

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

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

Kanban

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

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

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

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

3 пути DevOps

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

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

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

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

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

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

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

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

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

5 идеалов

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

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

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

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

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

SAST (Static Application Security Testing) - т. н. «тестирование белого ящика». Это поиск уязвимостей в коде без его запуска. Для такой проверки необходим доступ к коду, ошибки обнаруживаются на раннем этапе, но возможны ложные срабатывания.
DAST (Dynamic Application Security Testing) - «тестирование чёрного ящика». Имитация атаки на систему - SQL-инъекции, некорректные запросы и т. п. Нужно работающее приложение, доступ к коду не нужен (соответственно, эта проверка не покажет, где именно ошибка). Требует больше времени, чем SAST. Также выявляет проблемы быстродействия на разных этапах, например, аутентификации.
IAST (Interactive Application Security Testing) - анализ работы приложения изнутри. Это мониторинг, собирающий данные о работе приложения и анализ полученных данных. IAST может выполняться на любом этапе - от сборки до работы готового приложения. Может указать место в коде, где содержится ошибка, хорошо интегрируется с CI/CD, влияет на работу приложения из-за тесной связи с ним.
RASP (Runtime Application Security Protection) - анализ поведения приложения и контекста выполнения. Сканирование запросов и анализ их обработки приложением. Может не только сообщать о подозрительной активности, но иногда и блокировать её. Влияет на производительность, лучше не применять без других вариантов проверок безопасности.

SonarQube

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

Анализ кода и поиск ошибок в популярных языках программирования
Отчёты об ошибках
Интегрируется с IDE (VSCode и т. п.) и репозиториями (Gitlab), встраивается в пайплайны (GitLab, Jenkins)
История показателей качества кода, графики
Плагины для расширения набора функций

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

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

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

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

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

Нет ручной настройки
Настройка (создание) инфраструктуры занимает гораздо меньше времени
Масштабируемость: один человек может управлять огромным количеством машин
Возможность использовать git для отслеживания изменений в инфраструктуре
Воспроизводимость: инфраструктура, поднятая с помощью скриптов всегда будет одинаковой
Ценность элемента инфраструктуры падает: проще поднять новую, чем восстанавливать старую

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.