Герасимчук Михаил

*Было интересно на момент работы с проблемой (т.е. сейчас, некоторые решения, я бы возможно вычеркнул из этого списка)
- Привнес CI/CD практики, интегрировав запуски тестов/линтеров на уровне GitHub CI/CD
- Привнес и интегрировал на уровне CI/CD практики написания acceptance тестов на базе docker-compose и инфраструктурных моков с использованием gripmock(для gRPC API), wiremock(для HTTP API), LocalStack(для AWS инфраструктуры)
- Инициировал и провел миграцию с GitHub на GitLab
- Описал GitLab пайплайны содержащие этапы тестирования, сборки и доставки(с аппрувами) приложений на несколько окружений
- Создал главный лэйаут/шаблон для приложений
- Привнес практики чистой архитектуры
- Реализовал и интегрировал во все сервисы, возможность remote debug-а для golang приложений запускаемых в k8s. За счет введения дополнительных этапов в CI/CD по сборки и деплою приложения в специальном debug режиме. В рамках этой активности так же реализовал и live sync + rebuild сервисов в кластере с помощью reflex, rsync завернутых в кастомный докер контейнер, что позволило выполнять запуск sync-а в 1 клик
- Реализовал сбор Prometheus метрик и AWS XRay трэйсов, в разрезе операции репозитория, с дампом всех входящих параметров, имени метода а также возвращаемого результата+наличия ошибки. С помощью написания шаблона репозитория-декоратора и автогенерации декораторов gowrap-ом с последующей инициализацией в entrypoint-е приложения
- Реализовал silences feature на базе Alertmanager API для автотестов QA team

*Было интересно на момент работы с проблемой (т.е. сейчас, некоторые решения, я бы возможно вычеркнул из этого списка)
- Работа над отдельным продуктом - Abandoned Cart. Это b2b продукт, для которого я сделал MVP на Yii2. MVP позволял настроить брошенную корзину с отложенными сообщениями в facebook messenger, а так же позволял осуществлять сбор данных о пользователях facebook. Во время реализации MVP была интегрирована авторизация через FB и создано единое Facebook приложение. Когда кастомер создавал брошенную корзину, MVP автоматически вызывало FB API методы генерации маркеров доступа, которые требуются для уведомления пользователей о брошенной корзине в FB messenger-е. Так же в момент создания кастомером брошенной корзины, MVP проставлял webhook-и на Facebook страницу кастомера, для того чтобы принимать сообщения от его клиентов. А чтобы Facebook Checkbox plugin отображался на сайте кастомера, в MVP было интегрировано Facebook Page Settings API для установки whitelisted_domains поля страницы. MVP продукта я развернул в своем облаке, что позволило продемонстрировать бизнесу продукт, в том числе и дать им самим его использовать. В дальнейшем я запросил добавить поддомен для MVP на нашем основном домене, это позволило использовать его во время предпродажных демонстраций для потенциальных кастомеров. Так же сделал доступ к ресурсу по секретной куке, которую проверял на уровне nginx, что позволило скрыть MVP от посторонних глаз, не тратя при этом время на авторизацию. После создания и презентации MVP, мы разнесли все на Go сервисы, в которых уже использовали все взаимодействия с Facebook API, которые были налажены в MVP.
- Приемочные тесты на codeception с поднятием selenoid фермы в k8s - покрыл приемочными тестами позитивный главный кейс для нового продукта "Abandoned Cart", на selenoid ферме была сконфигурирована видео трансляция тестового сценария
- Помощь кастомерам с интеграцией продукта - писал кастомные JS решения по интеграции, для клиентов, у которых были проблемы с интеграцией продукта брошенной корзины
- Тестирование ClickHouse как потенциального хранилища для будущего хранения пользовательских событий кол-вом порядка 15-20млрд. Была выполнена миграция части текуших данных из mongoDB strorage-а в ClickHouse storage, и был реализован скрипт который выполняет ряд различных реальных запросов на разном кол-ве данных / разном временном диапазоне, и на основе скорости выполнения был сделан вывод, что данное хранилище удовлетворят потребностям.
- Написание js скрипта нормализации ~1.9млрд документов, размещенных в ~1.6K базах данных(~1.8Tb) одного mongoDB кластера. Требовалось нормализовать значения одного поля, содержащего массив объектов. Для этого был написан скрипт который проходится по всем базам данных кластера и в каждой БД делал полный проход по всем документам требуемой коллекции. Сразу же в скрипте были написаны тесты по нормализации документа, которые обязательно запускались перед стартом нормализации и должны были завершится с успехом + был организован live вывод статистики по кол-вам обработанных/заэфекченных документов как на уровне текущей БД так и общие числа по кластеру, так же был выполнен вывод потраченного и прогнозируемого времени работы. Был реализован dryRun режим в скрипте, и работа в режиме dryRun занимала ~30 чассов
- Реализация шаблона сервиса consumer-а для закрытия проблемы с boilerplate. В шаблон была сразу же заложена логика на основе управления простенькой сущностью пользователя для демонстрации того, как стоит комфортно организовывать роутинг ивентов из EventBus, а работа всех компонентов приложения в то числе и с демо сущностями пользователя была построена с использованием архитектурного подхода The Clean Architecture. В результате написания такого шаблона, разработчику, после генерации нового сервиса, очень просто видеть на примере, что и куда складывать, и на это уходит минимальное время.
- Настройка автоскейлинга для сервиса работающего в k8s, включая подбор оптимального кол-ва воркеров одного из компонентов сервиса + нагрузочное тестирования для проверки того, что поды множатся
- Реализация микросервиса с "горячей" реконфигурацией компонентов по хукам изменений конфигов из консула (изменяешь конфиг в consul-ui, микросервису приходит хук с новыми значениями, если ключ конфига поддерживает горячую реконфигурацию компонента, то stateful компонент останавливается, и запускается заново с новым конфигом, если же ключ не поддерживает горячую конфигурацию, сервис сам себя "убивает" и k8s под убивается, ну и потом новый поднимается)
- Обозначил и решил проблему с долгими ревью в команде с помощью реализации slack бота. Данный бот конфигурируется для конкретной команды и соответствующего канала команды в slack. Отправляет сообщение в канал команды, каждый день в 9 часов с напоминаниями о ревью - отмечая в каждом отдельном MR тех, кто не посмотрел его или упоминает, автора о том что пора мержить MR; демонстрирует статус последнего пайплайна для MR; указывает кол-во аппрувов и открытых дискуссий; указывает ссылки на задачу в JIRA, на сам MR, на репозиторий в который делается MR; сортирует MRы в особом порядке, с учетом успешности пайплайнов, кол-ва дискуссий/аппрувов, времени прибывания на ревью. А также обновляет всю вышеуказанную информацию в своем сообщений, на протяжении всего оставшегося дня. Что позволяет членам команды постоянно видеть актуальные MR-ы в одном месте, с указанием того, что каждому осталось посмотреть.

*Было интересно на момент работы с проблемой (т.е. сейчас, некоторые решения, я бы возможно вычеркнул из этого списка)
- Для валидации @throws phpDoc завернул PHPStorm в docker контейнер на alpine, и внедрил в drone CI;
- Для тестирования нового функционала, который был рискован, проводил нагрузочные тесты на боевое апи с помощью tsung и реальных пользовательских сценариев, которые были записаны;
- Сделал внутренний инструмент для авто тестов того, что правки в api не ломают старого функционала - например для задач по рефакторингу, или подобных, требуется получить выборку из access логов, закинуть ее в инструмент, указать виртуальные среды с production кодом, и с версией кода, в которую внесены правки, и система проверит, совпадения ответов. Инструмент позволяет изменять запросы/урлы/тела ответа с помощью php middleware-ов, которые находятся в веб интерфейсе;
- Для сокращения времени настройки remote debug-а в phpStorm, сделал расширение для данной IDE, которое, позволяет выполнять настройку xdebug в один клик (https://plugins.jetbrains.com);
- Для упрощения написания тестов, где требуется мокать внутренние апи клиенты, написал трэйт, после примеси которого, в унаследованном от реального апи клиента классе(моке), можно удобно и просто определять очередь ответов, так же можно добавлять в очередь и исключения, и ответы с ошибками.