Это второй пост, в котором подробно рассказывается о многих неудачах в GO-JEK Tech за последние 36 месяцев, когда мы выросли в 6600 раз. Для первого нажмите здесь
Нет модульных и автоматизированных интеграционных тестов
Есть история о нашей устаревшей монолитной службе, когда мы перестали проводить модульные тесты. Первое развертывание изменения кода прошло нормально. Когда к этому требовались некоторые изменения или требовались рефакторы, мы понимали, насколько запутанным был код. Одно небольшое изменение может повлиять на другие домены, создав огромный беспорядок.
Так родился Стэн Марш.
Пришлось снова начать создавать модульные тесты для кодовой базы. К этому времени код был слишком сложным и запутанным. Ему даже потребовались некоторые рефакторы кода, чтобы иметь возможность имитировать зависимости. Затем мы начали тестирование функций и исправлений, над которыми в настоящее время работаем. Запуск тестов для каждого теста для каждого класса - это нормально, но мы все равно терпели неудачу в целом. Это произошло из-за того, что макеты противоречили между тестами. И поэтому нам нужно было пропустить тесты в нашем конвейере сборки.
В результате мы по-прежнему не фиксировали зависимости между доменами, и сбои кода были склонны к возникновению. Казалось логичным переписать всю эту кодовую базу в кучу небольших сервисов, чем провести рефакторинг для ее исправления. Но нам потребовалось время, чтобы устранить первопричину.
Иногда мы снижаем приоритет для создания модульных тестов с надлежащим покрытием и во многом полагаемся на нашу команду QA. Одна из самых популярных причин: «Времени недостаточно, нам нужно больше времени на его создание». Дело в том, что ручные тесты, проводимые людьми, не будут масштабироваться по мере нашего роста, а когда мы программируем, в нашей логике всегда будут дыры.
Во-первых, регулярно выполнять одни и те же тесты вручную снова и снова, а также тестировать новые коды - это утомительный и трудоемкий процесс. Нам нужна помощь машин, чтобы проверить, как ведет себя наш код.
Во-вторых, мы можем измерить продолжительность начала разработки до ее завершения. Готово означает, что код начинает приносить пользу системам, операциям или бизнесу - другими словами, он означает развертывание в производственной среде. Затем мы можем сравнить продолжительность между созданием модульного теста на этапе разработки и выполнением «пинг-понга» разработки / исправления и ручных тестов между QA и разработчиком. В большинстве случаев хорошее покрытие модульных и автоматических интеграционных тестов делает работу быстрее или безопаснее, поэтому ее можно развернуть в производственной среде.
Модульные тесты также показывают свою мощь, когда возникает необходимость в рефакторинге. Поскольку все можно изменить, нам необходимо обеспечить доступность и согласованность системы при рефакторинге кода, чтобы сделать ее масштабируемой.
Изменчивое сотрудничество
Чтобы достичь ожидаемой скорости и сохранить уровень роста, нам пришлось масштабировать службы и команды. У каждой команды были свои цели и планы. Существует тенденция, что команда в конечном итоге будет работать изолированно, ограничивая общение с другими командами.
Мы должны были реализовать в распределенной системе, что каждая служба зависит друг от друга, от контракта API, задержки процесса, границы домена и т. Д. Существует так много движущихся частей, что требует, чтобы каждая команда выполняла задачи. При разделении монолита на микросервисы существует очень много случаев, когда между сервисами происходят рефакторы, чтобы получить идеальную границу домена. Такое общение между командами - огромная задача.
Иногда обновление услуги требует внесения некоторых изменений в другие службы. Это может быть просто добавление поля к существующему контракту или удаление части потока для переноса в другую службу. Время от времени это происходит между двумя или более командами, обслуживающими сервисы, у которых есть собственные планы развертывания. Это неотъемлемая часть суперприложения из 18 продуктов. Некоторые команды развертывают развертывание поэтапно, по проценту трафика, с использованием канарейки за машинными экземплярами или с большим взрывом. Зависимости - это проблема, с которой другие службы могут вносить связанные изменения.
План развертывания следует обсудить между командами. Переключатели функций обычно очень помогают в этом сценарии. Всегда следует учитывать обратную совместимость, и должна быть панель для мониторинга развертывания. После того, как все изменения службы будут полностью безопасно развернуты (откат не требуется), мы можем начать удаление старых реализаций.
Выгорание и не зная, когда остановиться
Это больше обо мне, но с уверенностью могу сказать, что я достаточно насмотрелся, пройдя этот цикл. Мы всегда должны уделять некоторое время тому, чтобы отвлечься, задуматься, сделать паузу и не думать о проектировании. Это наша собственная ответственность - знать пределы собственного «я». Я чувствую себя намного продуктивнее и делаю вдвое больше после хорошего перерыва. Большинство человеческих ошибок происходит из-за сгоревших людей, что может стоить больших денег, человеческого капитала, потенциальных убытков для бизнеса и даже постоянных клиентов.
Это не гонка. Если бы это было так, мы бы наняли тысячи и выиграли. Решение сложных задач требует интеллектуальной строгости. Для стимулирования творчества важны перерывы. Время от времени делайте передышку, и вы вернетесь более резким.
И многое другое!
Эти ошибки случаются между командами. Большинство из них исправлено, некоторые все еще находятся в стадии разработки. Медленно, но неуклонно и верно мы наблюдаем улучшения в наших предложениях. Сейчас мы намного стабильнее. Мы лучше связаны в том, как мы работаем лично и между командами. Эти ошибки делают нас лучше. Это не значит, что мы взломали код. Никто не делает. И мы не идеальны, мы всегда можем добиться большего. Мы постоянно стремимся к лучшему.
Это лишь некоторые из ошибок, которые мы совершили, и мы будем делать еще больше. Самое прекрасное в этих ошибках: это закреплено в наших Инженерных принципах. Мы не оглядываемся назад и не спорим о решениях. От нашего технического директора Группы Аджея Гор: Каждое решение правильное на момент его принятия. Один только этот принцип позволяет нам мыслить смело, брать на себя ответственность и масштабироваться.
Работа с GO-JEK - это потрясающий опыт из-за его культуры. Это весело, захватывающе, и вам стоит воспользоваться шансом поработать с компанией, которая расширяется в Юго-Восточной Азии. Поверьте мне, у нас одна из лучших инженерных культур и уникальные проблемы, которые зависят от масштаба. Присоединяйтесь к нам! Посетите gojek.jobs, чтобы узнать больше.
