# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps: - DevOps | Ресурсы | Что такое "devops" | Суть CI/CD/CDP | VM и Docker | Поясняющая схемка OS, Istio, k8s | Аутентификация к API OS через curl | Контракты API | CDC (Consumer Driven Contract) | Оценка задач | Во фронт или в бэк? | Уровень квалификации + Frontend + Apache web-server + Регулярные выражения + git + Javascript + Perl + Python + Ruby + Rust + Полезности в Windows + Linux Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Разработка и эксплуатация
latest update of the page: 27-01-2024, 09:53 UTC
Немного информации, чтобы иметь общее представление.
Ресурсы

Интерфейсы

Полезное

  • istio_codes.png - Istio response-flags на распечатку.
  • protocols_poster.pdf - постер с почти всеми протоколами. Распечатывать минимум на А3, ибо мелко и много.
Что такое "devops"

DevOps = красивое название для ПРОЦЕССОВ активного взаимодействия разработчиков с администраторами (БД и систем) и автоматизаторами тестирования
, которые (процессы) максимально стандартизированы с помощью договорённостей в командах и обеспеченностью сред для разработки
и автоматизированы за счёт использования специальных инструментов поставки, прогона тестов, развёртывания.

В общем случае, счастье достигается за счёт:

  • ускорения и упрощения оргпроцедур по получению техники для разработчика с уже установленной или быстро устанавливаемой/обновляемой IDE и другого необходимого инструментария, а также по получению необходимых сетевых доступов с рабочих станций.
  • упрощения и ускорения процедур по выделению и масштабированию мощностей для стендов, необходимых для развёртывания ПО и его тестирования
    , обычно за счёт использования облачных решений (Amazon AWS, Google Cloud, Microsoft Azure, SberCloud, Yandex.Cloud)
  • использования средств автоматизации операций для всего процесса поставки (Jenkins, TeamCity, рукописные скрипты)
  • использования средств виртуализации и контейнеризации (Docker, Kubernetes)
  • внедрения практики CI/CD/CDP и неизбежно с ней связанной автоматизацией тестов (unit, API, web-API, regress)
  • внедрения решений по мониторингу как целых стендов, так и отдельных хостов, ВМ, веб-сервисов и приложений
  • перехода на микросервисную архитектуру и service mesh с автотестированием контрактов многочисленных API (особенно если используется модный сейчас gRPC, например-например)

N.B. В повседневности словом devops чаще обозначают РОЛЬ администратора, который сопровождает стенды разработки и тестирования, управлением всеми этими средствами автоматизации поставки CI/CD/CDP (см. ниже).

Суть CI/CD/CDP
скачать схему в формате diagrams.net (бывший draw.io)

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

  1. чекина изменений в репозиторий;
  2. статического анализа кода: на уязвимости, на соответствие требованиям и стандартам;
  3. компиляции и формирования билда (сборки);
  4. передачи обратной связи об успехе/неудаче билда в виде уведомлений по выбранным каналам;
  5. деплоев на dev / test / staging / prod;
  6. всех необходимых тестов (unit, smoke, acceptance, regression, integration, end-to-end);
  7. заведения issue в СУП в случае ошибок;
  8. слияния изменений с нужной веткой в случае "зелёных" тестов.

Continuous integration, CI = автоматизированная интеграция программного кода в существующий проект в репозитории с последующей компиляцией, формированием сборки и прогоном базовых автотестов.
Считается, что должно занимать <= 10 минут.

Сontinuous delivery, CD(L) = CI + автоматизированная поставка готовой сборки ПО с изменениями на сервера разработки и тестирования с прогоном автотестов.

Сontinuous deployment, CDP = CD + автоматизированное развёртывание изменений в Пром.

Всё это счастье достигается посредством использования таких инструментов как, например, GitLab CI, BitBucket Pipelines, AWS CodeBuild, Bamboo, TeamCity, Jenkins и сильно облегчающей деплои контейнеризации (Docker).

Зачем всё это может быть нужно разрабу-одиночке на личном проекте?

Один раз помучаться, сделав правильный контейнер и настроив GitLab CI/CD, а потом пушить в нужную ветку, и у тебя через 5 минут всё обновилось на рабочих серверах.
Второй проект — чуть меняются скрипты и всё.
Потом вот пример: есть небольшой проект, надо добавить одну мелочь в дороге, ноута с собой нет. Зашел через веб-интерфейс в GitLab с телефона, поправил, сохранил — а дальше само всё обновилось!
© комментарий на habr.

VM и Docker
Что почитать на тему:

Суть

Контейнер = набор процессов, изолированный от остальной ОС, и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы (runtime & supporting files). Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.

А разве это не просто виртуализация?
Не вполне:

  • Виртуализация обеспечивает одновременную работу нескольких операционных систем на одном компьютере;
  • Контейнеры используют одно и то же ядро операционной системы и изолируют процессы приложения от остальной системы.

Разница между Виртуальной машиной и Контейнером

скачать схему в формате diagrams.net (бывший draw.io)

Примеры решений контейнеризации

  • Облачные решения:
    • Amazon AWS ECS
    • Azure Container Service (ACS)
  • On-premise решения:
    • Docker
    • Kubernetes
  • Оркестрация:
    • Docker Engine API
    • Kubernetes
    • Azure Service Fabric
  • Какое-то самописное решение: API-контейнеризация + ручная автоматизация
Поясняющая схемка OS, Istio, k8s

Поясняющая схемка некоторых сущностей Openshift, Istio, k8s для себя.
Доразобраться с Route и Gateway.

скачать схему в формате diagrams.net (бывший draw.io)

Аутентификация к API OS через curl

  1. Делаем запрос на получение OAuth token, используя, например, basic-аутентификацию OS User'ом curl -X GET "https://master-address:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token" -H "Content-Type: application/json" -H "X-CSRF-Token: XXX" -u [username] -ikL
  2. Из ответа из header'а < Location: https://10.64.33.43:8443/oauth/token/implicit#access_token=TOKENSCHMOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer берём значение TOKENSCHMOKEN (можно сразу grep'ать вместе с запросом выше), это и будет наш Bearer-токен для последующих запросов к API OS.
  3. Выполняем нужный нам запрос, например почитать yaml какого-то Deployment'а curl -X GET "https://api.master-address:8443/apis/apps/v1/namespaces/[namespace]/deployments/[deployment]" -H "Content-Type: application/json" -H "Authorization: Bearer TOKENSCHMOKEN" -ik , и в ответе получаем искомый yaml.

Контракты API

API = application programming interface = опубликованный программный интерфейс компонента/системы, позволяющий другим компонентам/системам получать доступ к какой-либо функции.

Контракт API = зафиксированная и документированная ответственность поставщика и ожидания потребителя.
Включает в себя две составляющие:

  • Функциональная (сигнатура и семантика):
    1. Название API
    2. Входные данные / параметры вызова (протокол, URI)
    3. Возвращаемые данные
    4. Семантика (описание функциональности)
    5. Шаблон интеграционного взаимодействия
    6. Потребитель
  • Нефункциональная (SLA):
    1. Доступность (availability, %)
    2. Время ответа (latency, ms) = время, необходимое приложению, чтобы ответить на запрос
    3. Пропускная способность (throughput, transactions per second, tps) = количество транзакций (запросов), которое приложение может обработать в течение секунды
    4. Какие-либо ограничения (по размеру сообщения, безопасности и т.п.)

Обычно контракты API ведут как в Confluence, так и в специальных системах — реестр API.

CDC (Consumer Driven Contract)

CDC (Consumer Driven Contract) = контракт потребителя сервиса.
Представляет из себя соглашение между сервисом-поставщиком и сервисом-потребителем в том, что
сервис-поставщик обязуется уметь принимать на вход от сервиса-потребителя определённую структуру данных определённых типов, сериализованную JSON/XML/binary/...
и гарантирует возвращать в ответ определённую структуру данных определённых типов, также сериализованную.

скачать схему в формате diagrams.net (бывший draw.io)

CDC фокусируется на поведении и данных, которые важны Потребителю, т.е. требования исходят от Потребителя: мне нужно вот это.

Сам контракт в явном виде описывается с помощью некоторого IDL (interface desciption language), например:

Этот подход когда-то реализован в виде WSDL/WADL-сервисов
, развивался для REST HTTP в виде, например, OpenAPI с его .yaml-файлами контрактов (Contract-First API Development with OpenAPI Generator and Connexion)
, а сейчас его популярность сильно возросла в связи с активным продвижением gRPC и его .proto-файлами контрактов (статьи GRPC сервис на примере генератора паролей и gRPC — фреймворк от Google для удалённого вызова процедур)

Что почитать на тему:
Оценка задач

Метод трёх точек (3-point estimation)

Метод для расчёта временных затрат в проектах с уникальными задачами в условиях неопределённости и при наличии нескольких типов рисков. Используется в IT достаточно широко.
Для того, чтобы начать применять этот метод, нужно проанализировать предмет доработки и описание реализации. Попытаться провести аналогии с ранее выполненными задачами с похожим скоупом. Определить риски и описать мероприятия по устранению этих рисков (что делаем, если сработал тот или иной риск).

WM = (O + 4*BG + P) / 6
О (opitimistic) — оптимистичное время выполнения задачи, если все пойдет хорошо, т.е. если не наступит ни один из выявленных и зафиксированных рисков.
BG (best guess) — наиболее вероятное время, или средняя продолжительность выполнения аналогичной задачи, при условии выполняли её уже много раз.
Р (pessimistic) — пессимистичное время выполнения задачи, если сработали все выявленные риски.
WM (weighted mean) — взвешенное значение с учетом рисков и последствий воздействия негативных и позитивных факторов.
SD (standard deviation) — стандартное отклонение, используемое для расчета вероятностей.

Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 4/6 всё пойдёт так, как было и ранее в подобных случаях, с учётом менее вероятных (по 1/6) отклонений в стороны "всё будет плохо" и "всё пройдёт идеально".

Чего позволяет добиться метод трёх точек:

  • Точности (используется 3 оценки вместо одной)
  • Повышения ответственности членов команды за оценку, поскольку они должны учитывать риски
  • Получить описание рисков в каждой задаче

Метод "Объём неясен, дам заведомо большую оценку, поторгуемся"

Суть в том, что по некоторым задачам ты вроде бы не знаешь даже примерно сколько она займёт трудозатрат, но готов назвать запредельно большую оценку (чувствуешь в ней внутреннюю уверенность, хоть и боязно произнести), за которую вы уж точно сделаете, но которая точно не понравится вопрошающему (заказчику работ).
Что это даёт — это выкладывает на стол переговоров повод для торга "ты мне уточнение входных данных, я тебе уточнение оценки".
Например, "Слушай, я не знаю во сколько её оценить, давай на все непонятные CR напишем по 500 часов, потом поторгуемся с возмущённым Клиентом, пусть разъяснит".

Кастомный метод для T-Shape оценки "размера" задачи

Связан с методологией Kanban.
Набросокъ:
"Размер" задачи Затрагиваемые Бизнес-процессы Потребность в степени вовлечения Заказчика и сторонних стейкхолдеров Объект доработки — тип компонента ПО
L (список наиболее суровых развестистых бизнес-процессов) высокая
(почти ничего не известно, размытые бизнес-требования, требуется информация от контрагентов)
  • Интерфейсы (интеграция с новыми Системами)
M (список бизнес-процессов "средней руки") средняя
(уже есть вопросы, чуются подводные камни в бизнес-требованиях, нет чётких кейсов воспроизведения ошибки)
  • данные (в БД, файлах)
  • формы GUI
  • интерфейсы (интеграция с другими Системами)
  • периодические задания (SSIS-пакеты, job'ы, cron'ы)
  • вспомогательные (плагины, хранимые процедуры SQL)
S (список коротких прямолинейных бизнес-процессов) минимальная
(уже всё понятно, и нам сообщено, есть чёткий кейс воспроизведения ошибки)
  • сообытийные процедуры для форм GUI
  • те или иные отчёты
  • подсистема управления правами

Размер задачи оценивать в максимальный из получившихся оценённых параметров, например:
У нас есть

  • предполагаются изменения в БП = Регистрация Клиента (S)
  • но потребность в вовлечении заказчика = средняя (M)
  • и объект доработки = форма GUI, событийные процедуры для форм GUI, данные (M)
, значит оцениваем задачу как М.

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

Потенциал для совершенствования: если суммируются несколько признаков одного уровня (например, объекты доработки), то оценка по этому признаку уходит на уровень выше.

Во фронт или в бэк?

Проверка введённых значений на соответствие логическим критериям, а не формальным — это занятие для бэка.
Пример:

  • проверка что в форму для числа введено число, а не срока — это чистый фронт;
  • проверка по КЛАДР -однозначный бэк;
Также сомнительно тиражировать единый алгоритм проверки в нескольких местах.

Уровень квалификации

Junior — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.

Middle — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.

Senior — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.

Технологический налог