• Как работают и где применяются бессерверные вычисления (Function-as-a-Service)

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

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

      Читать далее
    • Как технологический радар помогает осознанному развитию корпоративной ИТ-экосистемы

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

        Читать далее
      • Как настроить дашборды в Azure DevOps, чтобы они приносили пользу

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

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

          Читать далее
        • Практика создания единого шаблона проектов на базе Azure DevOps (TFS)

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

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

            Читать далее
          • OLAP-куб для аналитики процессов техподдержки

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

              Читать далее
            • Как мы построили систему управления проектами на базе Azure DevOps

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

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

                Читать далее
              • Как токенизация упрощает работу с чувствительными данными

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

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

                  Читать далее
                • Как портал Feature Flags помогает бизнесу управлять ИТ-продуктом

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

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

                    Читать далее
                  • Автоматизация Release Notes в современной команде разработки

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

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

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

                      Читать далее
                    • Как быстро и легко интегрироваться с Active Directory

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

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

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

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

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

                        Читать далее
                      • Production Ready: как проверить работоспособность продукта

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

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

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

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

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

                          Читать далее
                        • Обзор фреймворков для оркестрации микросервисов: Conductor, Zeebe, Temporal

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

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

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

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

                            Читать далее
                            • –3
                            • 2,8k
                            • 5
                          • Снова про мониторинг продуктов: как Postman избавляет поддержку от написания кода

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

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

                              Читать далее
                            • Как наладить бизнес-мониторинг продукта

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

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

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

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

                                Читать далее
                              • Feature Flags и фабрика ПО

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

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

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

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

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

                                  Читать далее
                                • Шаблон микросервиса: зачем нужен и как его внедрить в разработку

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

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

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

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

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

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

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

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

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

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

                                    Читать далее
                                  • Мультитенантность: как вырастить из одного приложения линейку независимых продуктов

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

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

                                      Читать далее
                                    • Quality Gates: как мы встраиваем автоматические проверки кода в свои процессы

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

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

                                        Читать далее
                                      • Как мы построили динамические отчеты на SSRS 2014


                                          Мы уже рассказывали, как помогли одной производственной компании трансформировать процессы корпоративного обучения и развития персонала. Сотрудники заказчика, которые тонули в бумажных документах и Excel-таблицах, получили удобное iPad-приложение и веб-портал. Одна из самых важных функций этого продукта – создание динамических отчетов, по которым руководители судят о работе сотрудников «в поле». Это огромные документы с десятками полей и средними размерами в 3000*1600 пикселей.

                                          В этой статье мы поговорим о том, как развернуть эту красоту на базе Microsoft SQL Server Reporting Services, почему такой бэкенд может плохо дружить с веб-порталом и какие хитрости помогут наладить их отношения. Вся бизнес-часть решения уже описана в предыдущей статье, поэтому здесь мы сосредоточимся на технических вопросах. Начнем!

                                          Читать дальше →
                                        • Xcode 11 и XCFrameworks: новый формат упаковки фреймворков


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


                                            В случае разработки под платформу 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.

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

                                            Читать дальше →
                                            • +10
                                            • 9,5k
                                            • 2