🚆 Релизный процесс. Кратко

Релизный процесс — это совокупность действий, которые необходимы для выпуска новой или обновленной версии программного продукта. Релизный процесс может быть разным в зависимости от типа продукта, методологии разработки, организации команды и других факторов.

К артефактам релиза относятся любые продукты, результаты или документы, которые создаются в ходе релизного процесса.

Артефакты релиза можно условно разделить на две категории:

🔹 Релизные объекты – это физические или логические компоненты, которые составляют релиз, например, исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.

🔸 Документация релиза – это документы, которые описывают релиз. Сюда входят: Release Notes (описание того, что изменилось), план релиза протокол тестирования, отчёт о релизе и т.д.

Управление релизами охватывает все этапы от разработки и тестирования до развертывания.

Этапы релиза могут быть разными, но обычно включают в себя следующие:

1️⃣ Планирование релиза. На этом этапе определяются цели, сроки, приоритеты, ресурсы и ограничения релиза. Также формируется документация, в которой фиксируется список функций, задач, ответственных, рисков и критериев качества релиза. План релиза должен быть согласован с заинтересованными сторонами. Новые фичи полезно оборачивать в тоглы – это специальные механизмы, которые позволяют включать или отключать определенные функции или части релиза без необходимости изменять код или перезапускать приложение.

2️⃣ Сборка релиза. На этом этапе происходит создание и упаковка релизных объектов, таких как исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.

3️⃣ Приемочное пользовательское тестирование (UAT). Финальное тестирование, выполняемое перед выпуском в продуктив. После проведения тестирования руководство вместе с разработчиками принимают окончательное решение о выпуске продукта.

4️⃣ Развертывание релиза. На этом этапе код собирается в исполняемый файл или пакет, который может быть развернут на сервере или облачной платформе. Для этого могут использоваться различные инструменты и методы, такие как непрерывная доставка, контейнеризация, автоматизация и т.д. Цель этого этапа — упростить и ускорить процесс развертывания и обеспечить его надежность и безопасность.

5️⃣ Мониторинг и обратная связь. На этом этапе разработчики и операторы отслеживают работу веб-приложения, собирают данные о его производительности, доступности, ошибках и поведении пользователей. Для этого могут использоваться различные инструменты и сервисы, такие как системы логирования, аналитики, оповещения и т.д. Цель этого этапа — улучшить качество и удовлетворенность веб-приложения, а также выявить и исправить возможные проблемы.

📎 Материалы
1. Всë, что вам нужно знать об управлении релизами
2. Релизный цикл ПО для самых маленьких
3. Автоматизация процесса релиза (+ видео)
4. От пул-реквеста до релиза. Доклад Яндекс.Такси
5. Рецепт гладкого релиза: PMy на заметку
6. Управление релизами, когда и зачем нужно?
7. Как мы автоматизировали процесс генерации Release Notes — опыт МТС
8. Чек-лист: что нужно было делать до того, как запускать микросервисы в prod
9. Релизный поезд. Доклад Яндекса

#devops #управление_релизами

🟦 Нотация C4. Подборка материалов

С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.

1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.

2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.

3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.

4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.

Главные преимущества C4

✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.

✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.

⛔️ Недостатки C4

➖ Нотация не предъявляет строгих требований, поэтому диаграммы могут выглядеть по-разному в зависимости от автора. Для большего единообразия требуются дополнительные правила на уровне соглашения архитекторов.

➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.

➖ Модель предполагает, что система может быть полностью описана четырьмя уровнями детализации, но это не всегда так. В зависимости от размера, сложности и характера системы, может потребоваться больше или меньше уровней, а также различные способы перехода между ними.

➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.

📎 Материалы

🌐 Официальный сайт

📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4

⏯️ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown

🎓 Бесплатный курс

#проектирование #архитектура #подборка

P of EAA: Patterns of Enterprise Application Architecture
(Шаблоны корпоративных приложений)

✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.

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

#проектирование

📚 Подборка книг по UML на русском языке

1️⃣ Мартин Фаулер. UML. Основы.
Совсем небольшая книга, написана простым языком. Подходит для новичков в UML.

2️⃣ Буч Грэди. Язык UML. Руководство пользователя.
Более подробная чем первая, тоже подходит для новичков.

3️⃣ Дж. Шмуллер. Освой самостоятельно UML за 24 часа.
За 24 часа, конечно, вряд ли освоите, но азы в этом книге растолкованы неплохо.

4️⃣ Крэг Ларман. Применение UML и шаблонов проектирования.
В книге основной упор делается на объектно-ориентированный анализ и проектирование. UML является лишь удобным дополняющим инструментом. Для более продвинутых пользователей.

5️⃣ Джим Арлоу. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование. Книга посвящена использованию UML в связке с RUP. Вы узнаете о роли моделирования в цикле разработки ПО, и эти знания помогут вам ответить на вопрос: как и когда использовать (или не использовать) UML, чтобы найти оптимальное решение для своего проекта. Авторы приводят множество примеров и дают рекомендации по разработке моделей.

6️⃣ М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка. Книга помогает научиться мыслить в глобальном понимании проектирования любого приложения, от самого высокого уровня абстракции и до момента написания кода. Книга написана подробно (иногда чересчур) и доступно, особенно раздел, посвященный моделированию. Благодаря сквозному примеру, можно связать все модели логически, что облегчает понимание.

7️⃣ Александр Леоненков. Самоучитель UML. Можно использовать в качестве полного справочника по UML. Для новичков может быть избыточная информация, редко встречающееся на практике.

Скачать можно все книги из поста выше.

🏴‍☠️ опять напиратили

#проектирование #uml

У багов тоже есть чувства

🔐 Авторизация и аутентификация. Обзор

Авторизация и аутентификация — это два разных, но тесно связанных процесса, которые обеспечивают безопасность и доступность данных и ресурсов в системе.

🆔 Идентификация — это процесс установления личности пользователя, то есть получение его идентификатора, такого как логин, email, номер телефона и т.д. Идентификация является первым шагом аутентификации, так как без нее система не знает, с кем имеет дело.

🔑 Аутентификация — это проверка подлинности личности пользователя, то есть подтверждение того, что он является тем, кем себя представляет.

🔐 Авторизация — это определение прав пользователя на доступ к определенным данным и ресурсам в системе, то есть установление того, что он может делать после аутентификации.

Пример: когда Вася хочет войти в конфлюэнс и вводит свою почту, система понимает, что аккаунт с таким email существует. Это идентификация. Затем система отправляет на Васин номер СМС с одноразовым паролем, а Вася вводит пароль и тем самым доказывает, что это именно он. Это аутентификация. Система понимает, что Вася настоящий и перенаправляет его на главную страницу – это авторизация, ведь Вася авторизован (то есть имеет право) на чтение главной страницы, как и любой другой сотрудник.

Способы аутентификации

🔗 OAuth 2.0 — это протокол авторизации, предназначенный для организации доступа клиента к ресурсам или данным на другом сервисе. После выполнения процедуры входа клиент получает от сервера access_token, который позволяет клиентскому приложению получать доступ к ресурсу для выполнения определенных действий от имени пользователя и refresh_token – необходимый для обновления access_token. refresh_token обычно имеет длительный срок действия (исчисляется в месяцах) и обменивается на новый по истечению срока действия.

Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается access_token, который затем обменивается на JWT-токен.

📜 JWT (JSON Web Token) – это открытый стандарт для создания и передачи данных в формате JSON, которые могут быть подписаны и/или зашифрованы. Поскольку информация конфиденциальна, такой токен хранится обычно несколько минут.

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

🔑 API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Ключ обычно передается в заголовке или параметре запроса.

Существует два вида ключей API:
1. Публичный ключ (открытый). Используется для шифрования данных при обращении приложения к серверу.
2. Секретный ключ (закрытый). Известен только пользователю и владельцу сайта. Используется для расшифровки данных, отправленных приложением.

API-ключи применяются при ассиметричном шифровании. Такое шифрование обеспечивает большую безопасность: если злоумышленник получит публичный ключ, то все равно не сможет пройти аутентификацию без секретного ключа.

🔒 mTLS (mutual TLS) — это расширение протокола TLS, которое позволяет обеим сторонам взаимодействия (клиенту и серверу) аутентифицировать друг друга с помощью цифровых сертификатов. Это повышает уровень безопасности и доверия между сторонами, так как исключает возможность подмены или перехвата данных. mTLS часто используется для аутентификации между микросервисами или API.

Есть две пары сертификатов и два закрытых ключа.
1-й закрытый ключ находится на сервере и позволяет расшифровывать данные, которые шифруются открытым ключом, как при обычной работе TLS.
2-й закрытый ключ устанавливается на клиенте, а сервер при ответах клиенту также шифрует данные его открытым ключом. Таким образом, к серверу могут обращаться только те клиенты, у которых есть закрытый ключ для расшифровки данных.

Это не полный перечень всех способов, будем делать отдельные подборки про SSO, SAML, OpenID Connect.

Подборка материалов в следующем посте ➡️

#архитектура #безопасность

SEBoK — свод знаний по системной инженерии

Все знают про существование BABOK для бизнес-аналитиков, но не каждый знает, что и системные аналитики тоже имеют собственный свод знаний — SEBoK.

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

SEBoK регулярно обновляется, последняя версия выпущена 20 ноября 2023 г. Изменения можно отслеживать на официальном сайте, там же можно почитать свод знаний в формате вики-страниц.

#свод_знаний

По сети разлетелся пример того, как Zoom AI Companion составляет тестовое содержание встреч. Если это не фейк, то вещь незаменимая