Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.

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

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

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

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

Некоторое время назад мы решили перестроить управление доступом к рабочему пространству мобильных команд. Изучили рынок и обнаружили, что бесплатная Google Cloud Platform вполне может составить конкуренцию платным решениям. В этой статье мы делимся своим опытом и даем инструкции по подключению. 

Уже около года команда поддержки одного из наших высоконагруженных продуктов использует ML-систему нашей собственной разработки – Problem Detection Platform (PDP). Этот сервис умеет анализировать логи и автоматически классифицировать возникающие ошибки. В результате саппорт получает из логов не тонны сырой информации, а данные, с которыми можно быстро и удобно работать.

Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.

Некоторое время назад появилась задача обновить монолит фронтенда большой высоконагруженной системы, работающей 24/7 – перевести с устаревшего фреймворка Knockout на современный React. Задача возникла, когда старая архитектура перестала соответствовать требованиям бизнеса. Команде поставили задачу реализовать новые функции, но в существующей архитектуре сделать это оказалось практически невозможно.  Хотим поделиться своим опытом, как сделать такой проект проще.

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

Технология Backend-for-Frontend упрощает разработку сервисов, с которыми одновременно работают множество разных клиентов: компьютеры, смартфоны и планшеты со всеми возможными ОС.

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

Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.

Термин «бессерверные вычисления» отчасти вводит в заблуждение – конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS – это абстракция оборудования, контейнеры – абстракция приложений, то FaaS – это абстракция бизнес-логики сервиса.

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

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

Рассказывать будем на примере Azure DevOps (TFS), который с этого года используют все наши команды. В разное время мы перебрали разные системы управления проектами, и в итоге поняли, что именно Azure DevOps объединяет в себе практически всё, что нужно разработчику: управление проектом, репозиторий кода, управление сборками, тестами и релизами.

В одной из прошлых статей мы писали, как всей компанией перешли на единый трекер на базе Azure DevOps (TFS). Это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как наш проектный офис разработал логику, по которой сейчас работают все наши команды.

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

Мы внедрили OLAP-куб, чтобы в реальном времени анализировать процессы техподдержки в наших продуктах. Рассказываем, как работает эта система и какие преимущества она нам обеспечила.

За 15 лет работы мы встречались с различными трекерами: от экзотических FogBugz и Mantiss до современных, которые активно использовали до 2019 года - TFS, Jira, Redmine, даже GitLab. В прошлом году мы за несколько месяцев перевели 200 человек на работу с Azure DevOps. В этой статье рассказываем, как это произошло.

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

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

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

Продолжаем рассказывать про feature flags (FF) – переключатели в коде, которые запускают и деактивируют функции продукта. На этот раз хотим вам рассказать про наше решение – портал фиче-флагов, который  позволяет бизнес-заказчикам управлять состоянием FF, а значит функциональностью продукта.

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

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

Мы в 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?