# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт
Эта страница:
Ресурсы devops Суть CI/CD/CDP VM и Docker Контракты API CDC (Consumer Driven Contract) Оценка "величины" задачи Во фронт или в бэк? Уровень квалификации OOP - базис Распространённые ошибки
Другие страницы:
DevOps Frontend Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows Linux
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Разработка и эксплуатация
last update: 06-10-2020, 07:42
Ресурсы

Интерфейсы

devops

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Облачные решения:
    • Amazon AWS ECS
    • Azure Container Service (ACS)
  • On-premise решения:
    • Docker
    • Kubernetes
  • Оркестрация:
    • Docker Engine API
    • Kubernetes
    • Azure Service Fabric
  • Какое-то самописное решение: API-контейнеризация + ручная автоматизация
Контракты 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) - стандартное отклонение, используемое для расчета вероятностей.

Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 0.8 всё пойдёт так, как было и ранее в подобных случаях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OOP - базис

Объектно-ориентиированное программирование (ООП) = методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования/

Инкапсуляция = свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе. Некоторые языки (например, С++) отождествляют инкапсуляцию с Сокрытием, но большинство (Smalltalk, Eiffel, OCaml) различают эти понятия.
Инкапсуляция обеспечивается следующими средствами:

  • Контроль доступа. Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках.
  • Методы доступа. Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access - доступ), а по отдельности - геттерами (англ. get - чтение) и сеттерами (англ. set - запись)

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

Полиморфизм подтипов (иногда просто - "полиморфизм") = свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Класс - универсальный, комплексный (составной) тип данных, состоящий из тематически единого набора:

  • "полей" - переменных более элементарных типов;
  • "методов" - процедуров и функций, связанных с классом, для работы с его полями. Они определяют действия, которые можно выполнять над объектом такого типа, и которые сам объект может выполнять. То есть он является моделью информационной сущности с внутренним и внешним интерфейсами для оперирования своим содержимым (значениями полей).

Объект - cущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса. Взаимодействие объектов в абсолютном большинстве случаев обеспечивается вызовом ими методов друг друга.

Распространённые ошибки
  1. неосмысленные имена переменных;
  2. проверка наиболее возможной ситуации находится в конце списка проверок;
  3. отсутствие проверки "если ничего из указанного";
  4. отсутствие валидации параметров метода в самом начале метода;
  5. отсутствие валидации данных до выполнения операции с данными в БД типа update/insert (не отлавливаются пустые значения,..);
  6. обращение в БД с запросами вида "select * from A" (возвращает очень много данных);
  7. неоправданное и неаргументированное время жизни при использовании кэшей;
  8. ошибки с правами доступа (пароли лежат где-то в открытом виде,..);
  9. глобальные константы в коде классов;
  10. куча одинаковых(очень похожих) кусков кода не вынесены в функции;
  11. использование функции, когда не полностью известно(понятно) её предназначение и принцип работы (например, использование функции округления, не интересуясь в какую сторону она округлит);
  12. отсутствие комментариев на сложных участках;
  13. подключать/использовать библиотеки/функции дублирующие функционал друг друга, когда можно было бы обойтись чем-то одним из арсенала;
  14. оставлять в коммите код, использовавшийся для дебага (может тормозить систему, заполняет логи лишней информацией);
  15. размещение сложных условий в одну строку (нечитабельно, например t = y && p &&!q&&(!!l)?k?m:n :0);
    Никогда не пишите длинных if-ов
  16. при переборе массивов, особенно двумерных, каждый раз использовать обращение к элементу массива, а не присвоить его значение какой-нибудь переменной и работать с ней в пределах, даёт существенный прирост скорости в часто выполняемых операциях в том числе с клиентской стороны при обхода DOM-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.
Технологический налог