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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка ведётся аналогично 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 и т. д.

Книги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Стремление к простоте - код, оргструктура и процессы не должны быть запутанно-сложными
2. Удовольствие от работы, условия, дающие возможность сфокусироваться на достижении результата
3. Постоянное совершенствование
4. Психологическая безопасность - открытое обсуждение проблем и выработка механизма их предотвращения вместо поиска крайнего
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) - анализ поведения приложения и контекста выполнения. Сканирование запросов и анализ их обработки приложением. Может не только сообщать о подозрительной активности, но иногда и блокировать её. Влияет на производительность, лучше не применять без других вариантов проверок безопасности.

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

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

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

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

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

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

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

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

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

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

Kief Morris - Infrastructure as code

Свободный аналог - 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):

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

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

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)

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