Технологии | Леруа Мерлен Цифровые Технологии

Леруа Мерлен
Цифровые Технологии

Технологии

Рассказываем, как внедряем новые технологии, зачем пишем код в соответствии с требованиями InnerSource и почему тестирование так же важно, как разработка.

1. Весь код соответствует минимальным требованиям InnerSource

  • Код доступен для каждого сотрудника и хранится в GitHub.
  • Всё, что не соответствует требованиям InnerSource, считается техническим долгом.
  • Код-ревью — это обязательно.

Практики и ритуалы:

Правило 30% Правило 30% Каждый инженер может использовать часть рабочего времени на исследовательские задачи, работу над техническим долгом или обучение. Процент времени определяет технический лидер совместно с продуктовой командой. Правило Бойскаута Правило Бойскаута У настоящих бойскаутов есть правило: оставляй поляну чище, чем она была до тебя. Наша версия: оставляй код лучше, чем он был до тебя. Как говорил Дядюшка Боб, беспорядок в коде нужно порицать так же, как мусор на улице. Правила контрибуции Правила контрибуции В каждом репозитории описано, как обрабатывать изменения в коде. Например, работа с пулл-реквестами, процесс код-ревью и настройки защищённых веток в гите.

2. Автоматизируем по возможности всё

  • Предпочитаем автотесты ручному тестированию.
  • Осуществляем билд и деплой с помощью CI-инструментов

Практики и ритуалы:

DevOps DevOps Дружба между разработчиками и опсами :) Если серьёзно, то рекомендуем книгу. IaC IaC Infrastructure as Code — инфраструктура как код. Мы используем автоматические конфигурационные файлы вместо простого накликивания через веб-интерфейс. Эти файлы содержат сценарий подготовки инфраструктуры, билда и деплоя приложения.

3. Согласуем выбор технологии с Таблицей технологий

  • Таблицу поддерживает Технологический комитет.
  • Все движения в основной таблице зарегистрированы в таблице движений.
  • Поддерживаем тестирование новых технологий.

Практики и ритуалы:

Технологический Комитет Технологический Комитет Это сообщество архитекторов предприятия, технических архитекторов и технических лидеров команд разработки и IT-инфраструктуры. Комитет собирается минимум раз в месяц и отбирает технологии, которые помогут эффективнее использовать ресурсы компании. Это могут быть языки программирования, платформы и библиотеки, инструменты и подходы в контексте конкретных сценариев использования.

4. Фронтовые приложения следуют Дизайн-системе

  • Дизайн-система доступна пока только из внутренней сети.
  • Все бизнес-настройки конфигурируются через веб-интерфейс.

Практики и ритуалы:

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

5. Строим надёжные приложения и инфраструктуру

  • Узнаём о проблемах в проде быстрее пользователей.
  • Предпочитаем stateless приложения, запускаем их в контейнерах и используем оркестратор.
  • Приложения корректно переносят частичные отказы.
  • Приложения и базы данных реплицированы и поддерживают шардинг.
  • Приложения корректно обрабатывают некорректные входящие запросы и отдают только корректные ответы.
  • Сервисы предоставляют и контролируют SLO.
  • Инфраструктура ключевых систем построена по принципу мастер-мастер репликации.

Практики и ритуалы:

VALET VALET Гугловский способ измерения SLO.
Volume (traffic) — Объём трафика — какой объём бизнес транзакций сервис может обработать?
Availability — Доступность — насколько сервис готов бесперебойно обслуживать посетителей?
Latency — Задержка — насколько быстро отвечает сервис?
Errors — Ошибки — правильно ли ведется учет и «расходование» бюджета ошибок?
Tickets — Тикеты — насколько часто необходимо обслуживать сервис в ручном режиме? Фича флаги Фича флаги По-другому этот подход называют feature toggling. Суть в том, чтобы добавлять новую функциональность как подключаемый модуль, который можно отключить в любой момент. Распределённый Трейсинг Распределённый Трейсинг Каждый запрос на входе получает уникальный трейс-ID — этот идентификатор передаётся в каждом последующем вызове. Телеметрия Телеметрия Приложения выставляют наружу эндпоинт с показателями жизни для анализа и мониторинга. Канареечное развёртывание Канареечное развёртывание Канареечное развёртывание помогает снизить негативное воздействие релизов, в которых пропущены баги. Суть стратегии: сначала развёртывать изменения на небольшом подмножестве серверов, а после теста — на остальных серверах. Читать больше

6. Тестирование так же важно, как разработка

  • Тестирование начинается на этапе формирования требований.
  • В каждой продуктовой команде есть минимум один QA-инженер.
  • Код покрывается тестами сразу — тестирование не откладывается в бэклог.

Практики и ритуалы:

Динамические тестовые окружения Динамические тестовые окружения Проводим тестирование системы на динамически поднятом окружении — оно включает в себя все необходимые зависимости (внешние зависимости лучше заменять моками). Доступ к таким окружениям ограничен, чтобы ничто не могло повлиять на тестирование. После тестирования удаляем окружение. Мокирование Мокирование В тестировании лучше избегать зависимости от внешних систем — они нестабильны, а доступ к тестовым данным может быть ограничен. Вместо них можно использовать мок-эмулятор системы, который повторяет её поведение в необходимом объёме, но не воспроизводит внутреннюю логику. Тестирование производительности Тестирование производительности Вид тестирования, при котором тестируется не логика системы, а её быстродействие.В качестве критериев производительности бэкенда используются следующие метрики:
- количество запросов в секунду;
- время отклика;
- процент ошибок;
- утилизация ресурсов системы.
Для тестирования производительности фронтэнда используют Google Lighthouse и его метрики. Бэкенд лучше тестировать при помощи Gatling.