Всем привет! Меня зовут Артем. Я Android QA Engineer в команде Банки.ру.

Было ли у вас такое, что unit-тесты в проекте есть, но на практике ими почти никто не пользуется? Разработчики их пишут, но для QA это “что-то где-то в коде”: нельзя нормально посмотреть результаты, оценить покрытие или использовать в регрессе.

В статье рассказал, как мы решили эту проблему: сделали unit-тесты видимыми через Allure, связали их с тест-кейсами и встроили в реальный процесс тестирования.

Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.

Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.  

Всем привет! Меня зовут Саша. Я тимлид команды разработки личного кабинета пользователя в Банки.ру.

В какой-то момент я понял, что мы тратим слишком много времени на однотипные изменения в коде: обновления зависимостей, правки после breaking changes, синхронизация между проектами. Всё это делается через поиск, регулярки и ручное редактирование и быстро начинает масштабироваться в боль.

В статье разобрал, как можно подойти к этому иначе: использовать codemod и jscodeshift, чтобы автоматизировать такие изменения и применять их сразу ко всей кодовой базе. Как это работает через AST, и посмотрим на примере, как писать свои трансформации.

Вы когда-нибудь писали плагин для semantic-release? А хотели бы? Если да, то идем дальше. Расскажу, как это сделать и самое главное это не сложно. А в конце Вас ждет репозиторий, который вам поможет начать проект.

Привет! Меня зовут Алексей, я работаю в команде Авторизации Банки.ру. Сегодня хочу познакомить Вас с тем, как можно написать свой плагин для semantic-release.

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме.

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

Всем привет! Меня зовут Рома, я DevOps в команде «Платформа» в Банки.ру.

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

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

Всем привет! Меня зовут Марина, я QA в компании Банки.ру и сейчас занимаюсь продуктами личного кабинета, но успела поработать и в других командах. 

В IT все по-разному представляют работу тестировщика:

– Кто-то видит человека, который по 8 часов кликает на кнопки (я, честно говоря, так же представляла разработку, что уж скрывать…).
– Кто-то – душного охотника на баги, который только и делает, что пытается что-нибудь сломать.
– Кто-то вообще считает, что это просто начальная ступень в IT, чтобы потом пойти в разработку.

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

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

Всем привет! Меня зовут Андрей, с Банки.ру я связан уже больше 14 лет, а сейчас руковожу командой Платформы и забочусь о гильдии девопсов.

Итак, в течение своей работы я очень часто сталкивался с разными инцидентами продакшена. Конечно, в моменте бывало невесело: многие факапы были сложными и требовали довольно много времени на расследование.

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

Привет! Меня зовут Никита Титков, я бэкенд-разработчик в Банки.ру. 

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

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

Давайте разбираться!

Привет! Меня зовут Анна и я QA-инженер в Банки.ру. В этой статье я расскажу о том, как мы сделали инструмент нагрузочного тестирования доступным для каждого инженера в компании.

Представьте: команда запускает новый микросервис, который будет отдавать информацию о банковских продуктах. Сервис покрыт автотестами, билды зеленые, все работает штатно. Но через пару часов после деплоя в прод сервис начинает падать под наплывом пользователей, время ответа превышает 10 секунд, разделы лежат, ПАНИКА!

Знакомо? У нас было подобное. В статье расскажу подробно про наш опыт!

Привет! Меня зовут Антон, я iOS-разработчик в Банки.ру. Когда я только начинал изучать Combine, он казался для меня магией. Пара команд – и вот у тебя уже есть какие-то данные. Чтобы Combine перестал оставаться черным ящиком давайте заглянем внутрь. Эта статья – мое виденье этого фреймворка.

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

Давайте рассмотрим Combine изнутри!

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

Всем привет! Меня зовут Артем, я фронтенд разработчик в Банки.ру. Недавно перед нашей командой встала задача внедрить SSO-аутентификацию через Keycloak для клиентских сервисов. Помимо базовой настройки важно было полностью переработать стандартные формы входа, чтобы они соответствовали корпоративному стилю и UX-требованиям.

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

Привет! Меня зовут Андрей, я разработчик из команды контента в Банки.ру.

Как человек, который постоянно изучает новые технологии и читает тонны документации, я давно устал тратить часы на ручное конспектирование. Перепробовал кучу способов — от блокнотов до сложных систем управления знаниями, пока не наткнулся на идеальную связку Obsidian + Zotero.

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

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

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

– Почему часть важных изменений в команде не приживается и откатывается к началу, хотя, кажется, мы все вместе нашли консенсус?
– Да каким образом мы снова не попали в сроки проекта, хотя у нас прекрасная опытная команда.
– Какова причина нежелания команды переходить на актуальный стек? Или наоборот, почему члены команды упорно тащат в ключевой проект сырые фреймворки и необкатанные подходы?
– Снова по итогам проекта у нас переусложненная и запутанная архитектура. Что мы делаем не так?

Давайте разбираться!

Привет! Меня зовут Алиса, я руковожу командой машинного обучения в Банки.ру и занимаюсь проектами, связанными с внедрением ИИ.

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

Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру. Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).

Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.

В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить,  что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему — технический долг и как с ним работать.

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

Потом я структурировал, что есть по этой теме у нас в Банки.ру и решил написать статью. Будет много ссылок на англо- и русскоязычные статьи и доклады, рекомендую изучить каждую ссылку для полноты понимания.

Привет! Это Александр, DevOps инженер из Банки.ру. В прошлой статье я рассказал про сборку сетевого хранилища на базе XPenology. Сегодня продолжу тему Proxmox и XPenology и поделюсь историей о неудачном апгрейде инженерными CPU мини-ПК Lenovo из первой статьи и чем она закончилась.

Всем привет! Меня зовут Женя. Я инженер поддержки бизнес-приложений в компании Банки.ру.
Не так давно мы в направлении Мобайл решили прокачать технический и продуктовый мониторинг и с этой целью начали использовать Zabbix. В результате всю логику алертинга перенесли из Grafana в новый инструмент. Благодаря этому и родилась идея поделиться опробованными фишками Zabbix с сообществом. 

В этой статье я:

• расскажу об интересных возможностях Zabbix;
• поделюсь кейсами их использования и примерами настроек;
• сравню Zabbix и Grafana и расскажу, как мы применяем их в тандеме.

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