Делимся своим опытом о том, как мы собираем отчёты по релизам – быстро, корректно и без ручного труда.

Мы в True Engineering начали автоматизировать подготовку Release Notes несколько лет назад. Нашей целью было привести их к единому для всех команд стандарту, избавить тимлидов и PM-ов от ручной работы по подготовке материалов, застраховаться от возможных ошибок, которые обязательно возникают, если что-то делается вручную.

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

Active Directory использует большинство наших заказчиков, так что необходимость интегрироваться с ней появляется практически в каждом проекте. Чтобы командам не приходилось каждый раз решать эту задачу заново, разработчики True Engineering создали сервис, который мы теперь можем в готовом виде встраивать в другие продукты. Делимся опытом.

У любого продукта есть пользователи, и их информацией надо как-то управлять - создавать учётные записи, сохранять пароли, добавлять пользователей в группы и т.д. Пользовательские данные хранятся в Active Directory, так что разработчикам новых продуктов нужно выстроить связи с этой службой, прописать все необходимые процессы, позаботиться о безопасности.

Эту часть работы мы сейчас и автоматизировали в рамках отдельного микросервиса AReS – от Account Registration Service. Он умеет заводить в AD новых пользователей, отправлять им письма с регистрационной информацией, напоминать о необходимости придумать пароль. Это законченный компонент, и его можно копировать практически в любой продукт.

Архитектура процесса

Когда пользователь регистрируется в системе, его данные поступают в RabbitMQ, откуда их подхватывает AReS. В пакете вся информация, которая нужна для создания учётной записи:

Сегодня мы поделимся критериями, которые используют команды True Engineering, чтобы удостовериться в качестве продукта при поставке на Prod.

Что значит «продукт готов»? У каждого разработчика может быть свой ответ на этот вопрос. И хотя в общем и целом представления могут совпадать, рано или поздно любой команде понадобится выработать некий язык, который позволит смотреть на продукт с одних и тех же позиций и выдавать стабильный результат.

Эти единые представления и составляют понятие Production Readу. Когда команда договаривается о требованиях, которым должен соответствовать продукт, разработчикам становится проще работать. Все вкладывают в понятие готовности единый смысл, значит результат не меняется от разработчика к разработчику – не будет такого, что кто-то не стал делать логирование, потому что посчитал, что почему-то не нужно. У менеджера проекта меньше головной боли – он знает, в каком состоянии получит продукт и что можно гарантировать заказчику.

Наш набор критериев Production Ready объединил и наши собственные знания, и лучшие практики из «внешнего мира» разработки. Этот момент стоит отдельно подчеркнуть – необязательно брать под копирку чужой опыт, у вашей команды может быть свой стиль работы. Главное, чтобы он был эффективным и соответствовал единому стандарту.

Итак, как мы понимаем, что наш продукт действительно Production Ready?

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

При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.

Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.

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

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

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

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

Именно с мониторинга стоит начинать постановку продукта на техподдержку. И уже на этом фундаменте выстраивать технологию обработки обращений (Incident Management) и развивать системный подход к решению проблем (Problem Management).

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

В общем и целом мониторинг отвечает на два главных вопроса:

Наши команды практикуют подход Trunk Based Development – новый код сразу добавляется в мастер-ветку, сторонние ветки живут максимум несколько дней. А чтобы коммиты не мешали друг другу, разработчики используют фича-флаги (Feature Flags) – переключатели в коде, которые запускают и останавливают работу его компонентов.

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

Если вы стремитесь сокращать Time-to-Market, это недопустимо долго. Чем раньше вы получите обратную связь от пользователей, тем скорее вы исправите ошибки, тем меньше времени вы тратите на неудачные идеи, тем больше ресурсов можете уделить идеям удачным.

Чтобы обновления быстрее доезжали до прода, одна итерация должна включать одну фичу. Именно поэтому нужно сокращать срок жизни веток.

Проблемы долгоживущих веток

Сегодня речь пойдёт про шаблоны, которые позволяют нашим командам создавать новые микросервисы буквально за несколько минут. Рассказываем, как он устроен и почему эта история не только про автоматизацию ручного труда, но про эффективность разработки как таковой.

В том или ином виде шаблоны используют многие разработчики. Чаще всего, чтобы сэкономить время, они копируют код из старых проектов. С нашей точки зрения, у такой практики есть сразу несколько недостатков:

1. Можно выбрать неудачный микросервис для копирования - с недостающими элементами, некорректными настройками и т.д.

2. Если у разработчиков нет эталона, повышается риск дополнительных ошибок. Значит, кому-то придётся потратить лишнее время, чтобы их исправить.

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

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

Что даёт шаблон микросервиса

Шаблон микросервиса – это кирпичик программного продукта, конструктивный элемент, который можно переиспользовать от проекта к проекту.

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

А с точки зрения бизнеса это возможность лучше распоряжаться своими ресурсами, чтобы конвейер разработки двигался быстрее и более гладко:

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

В первую очередь мультитенантность нужна SaaS-продуктам, но не только. Этот подход применяется везде, где компания параллельно поддерживает несколько версий одного продукта.

Quality Gates – это автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки. Рассказываем, как работает эта технология, и поделимся дорожной картой, которую мы составили, чтобы внедрить Quality Gates во всех наших командах.

Принцип Quality Gates – буквально «ворота качества» – помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Если в коде есть дублирование, обнаруживаются проблемы с переменными или не хватает тестов, он не «проходит в ворота» и возвращается автору. В результате код становится чище и понятнее, баги оказывается проще исправлять, да и появляются они реже.

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

В случае разработки под платформу iOS, да и в целом, экосистему Apple, есть два варианта подключать библиотеки в качестве зависимостей:

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

При выборе второго подхода становится логичным использовать CI/CD системы для сборки библиотек в готовые к употреблению артефакты.

Однако, необходимость собирать библиотеки под несколько платформ или архитектур процессора в экосистеме Apple, зачастую, требует проводить не всегда тривиальные операции, как при сборке библиотеки, так и конечного продукта, который её использует.

На этом фоне, было сложно не заметить и крайне интересно изучить, одно из нововведений от Apple, представленное на WWDC 2019 в рамках презентации Binary Frameworks in Swift — формат упаковки фреймворков — XCFramework.

XCFramework имеет несколько преимуществ, в сравнении с устоявшимися подходами:

1. Упаковка зависимостей под все целевые платформы и архитектуры в единый bundle из коробки.
2. Подключение bundle в формате XCFramework, как единой зависимости для всех целевых платформ и архитектур.
3. Отсутствие необходимости в сборке fat/universal фреймворка.
4. Нет необходимости избавляться от x86_64 слайсов (slice) перед загрузкой конечных приложений в AppStore.

В этой статье мы расскажем, зачем был внедрён этот новый формат, что он из себя представляет, а также, что он даёт разработчику.

1. как стартует этот процесс,
2. синхронизация с Git-репозиторием заказчика,
3. сборка бекенда и фронтенда,
4. автоматическое развертывание приложения в тестовой среде,
5. автоматическое развертывание на Prod.

• регистрацию,
• контроль подключения к API,
• мониторинг того, как пользователи используют конечную систему,
• учёт бизнес-показателей.

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