Привет, я фронт, и за десять лет разработки в энтерпрайзах, стартапах и некрупных компаниях я впервые деплою свой код сам и отвечаю за его эксплуатацию, а не только за проектирование и разработку сервиса. О том, как я до этого дошел и почему не собираюсь останавливаться, в этой статье.
В нашей компании самостоятельный деплой это часть workflow многих разработчиков. Такая практика типична, скорее, для стартапов и редка в средних и крупных компаниях. Почему? Мне кажется, решение о полной передаче деплоя выделенным специалистам, играющим роль релиз-инженеров, происходит по вполне понятным причинам:
Разделение ответственности в ряде случаев ответственность за деплой оказывается высокой.
Необходимость в дополнительных навыках обычно нужно неплохо знать платформу, через которую происходит деплой, или хотя бы разбираться в скриптах вроде Capistrano.
Сложность инфраструктуры при деплое приходится учитывать массу поддерживающих сервисов, таких как меш-сети, очереди, воркеры, базы данных и т. д.
В Учи.ру был создан собственный инструмент для выкатки сервисов и настройки стейджей под названием Шаман по сути кастомный интерфейс к HashiCorp Nomad. Несколько лет назад он помог уйти от исполнения скриптов на локальных машинах, автоматизировать процесс деплоя и позволил разработчикам создавать тестовые конфигурации максимально быстро. Об этом мои коллеги из команды инфраструктуры написали отдельную статью.
С самого начала вся разработка у нас велась внутри одного-единственного монолитного репозитория, поэтому Шаман умел собирать его и выкатывать, при этом отлично справляясь со своей задачей. Но компания росла, а вместе с ней осваивались рынки, запускались новые проекты, добавляя перекрестные логические связи и в без того сложный код.
Но аве прогрессу подходы к разработке эволюционируют вместе с нами. Поэтому в какой-то момент, наевшись боли от того, что в монолит коммитят 200 человек, мы потихоньку начали откусывать от него небольшие семантически связанные куски и выносить их в сервисы. Со временем сервисов отпочковывалось все больше, а им, естественно, нужно как-то коммуницировать друг с другом сложность настройки приложений экспоненциально увеличивалась.
И здесь Шаман действительно выручил, потому что настраивать такие связки вручную правильно и предсказуемо довольно непростая задача. Он абстрагировал сложность управления новыми машинами с массой параметров, раскладку на них сервисов через докер-контейнеры, настройку и регистрацию эндпоинтов этих сервисов в оркестраторе в общем, кучу вещей, которые объять каждому разработчику мозгом будет проблематично, да и, положа руку на сердце, не нужно. Вместо этого я вижу суровый, минималистичный, но тем не менее довольно понятный интерфейс, освобождающий меня от необходимости заглядывать в глаза бездне низкоуровневого администрирования.
А что делать, если тебе нужно поднять копию среды для тестирования второго релиза? Не создавать же всю связку целиком заново? А если ее незначительно видоизменить? Для подобного в Шамане есть возможность создать шаблон конфигурации, в котором с помощью YAML описана вся россыпь машин, сервисов и эндпоинтов. В результате, если ваша команда поддерживает свой шаблон, поднятие нового инстанса развесистой связки сервисов становится тривиальной задачей.
И, кажется, коллеги со мной согласны:
Лично для меня в деплое нет ничего сложного. И учитывая, что иногда мне приходится делать больше десяти тестовых выкаток в день, а также развертывания совершенно новых приложений, я очень рад, что не нужно каждый раз подключать кого-то из отдела инфраструктуры. Приложений у нас много, и возможность самостоятельной выкатки сильно упрощает жизнь и ускоряет работу, Роман Литвинов, ROR разработчик.
На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше Шаман подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?
И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в Шаман чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!
Понятное дело, что после выкатки кода на прод надо убедится, что он ведёт себя так, как задумано. И тут у нас чуть хуже с автоматизацией, но тем не менее всё под контролем. Для мониторинга мы используем сервис Sentry, который нотифицирует как о новых индивидуальных ошибках, так и об изменениях общего фона. Ну и продуктовые дашборды с метриками никто не отменял. А Шаман, в свою очередь, быстро и непринужденно позволяет откатить бажную версию фронтового приложения в случае серьезных проблем.
Мой ответ да, если есть подобная система, упрощающая жизнь. Потому что твой сервис твоя крепость. И за него нужно нести ответственность на всех этапах, в том числе и в контексте выкаток. Да, это требует больше знаний, но наш отдел эксплуатации сделал крутую абстракцию, скрывающую большинство низкоуровневых процессов.
Такая схема позволяет не аккумулировать сделанные задачи в большие релизы, которые долго тестируются, а выкатывать их по мере готовности. Больше контроля и меньше вероятность ошибки.
Ну и вопрос времени: деплоить самому куда быстрее, чем отдавать релиз выделенным инженерам. Но, естественно, с допущениями:
Сервисы приходят и уходят, соответственно, шаблон связки сервисов нужно держать актуальным, иначе поднятие новых тестовых стендов превратится в боль.
Стоит держать в голове, что мы работаем с in-house-решением со всеми вытекающими: оно может сломаться. Поэтому здесь нужно быть достаточно открытым и помогать коллегам чинить проблему, а не бранить решение.
Такой подход требует высокого уровня развития процедур и процессов для сохранения качества и стабильности сервиса при высоком ритме выкаток, а также определенной смелости от ключевых стейхолдеров.
Как происходит деплой в вашей компании? Считаете ли вы наш подход с одной кнопкой оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.
Мария:
Год назад с каждой командой нужно было общаться по-разному. Например, у логистического продукта были планирования раз в две недели. С R&D не было планирования. Мы сидели за соседними столами и нормально всё решали. У остальных команд были разные процессы в зависимости от количества заказчиков, которых нужно подружить между собой и поделить ресурсы, и от количества исполнителей у каждой из команд.
Антон:
Ежедневно мы проводим встречи с коллегами из операций, бизнеса, разработки и с менеджерами других продуктов для обсуждения новых идей и поиска решений для их реализации. Каждый видит это по-своему: менеджеры продуктов хотят сделать удобно, понятно и доступно, разработка думает с точки зрения архитектуры. Приходилось каким-то образом договариваться со всеми. Это было неудобно: ты говоришь с одним человеком и не учитываешь мнение других. Как следствие, многие фичи и проекты решали проблемы одних коллег, но порождали для других.
Стас:
До внедрения GIST у нас применялся классический подход, когда компания находится в стадии переходного периода, внутри продуктов часто творился хаос. У менеджеров продукта был свой roadmap, но у разработчиков не было к нему доступа. Product-менеджеры где-то что-то фиксировали и с этим работали. Выдержки в виде продуктового описания приносили командам разработки, которые формировали технические требования. Появилась потребность весь этот хаос упорядочить, потому что работать становилось очень сложно.
Антон:
На нескольких первых планированиях было мягко говоря непросто. Все приходили, изначально друг с другом не договорившись. В течение большей части встречи творился хаос и борьба за ресурсы команд разработки. От многих звучали фразы: Я отказываюсь, я не хочу, чтобы мы вот это брали, а мне нужно вот это и срочно.
Часто запросы конфликтовали друг с другом: какая-нибудь из задач, призванная улучшить целевую метрику одного заказчика, при этом могла негативно повлиять на целевые метрики второго. Такое до сих пор бывает, но сейчас у нас в процессе GIST рождается истина. Все понимают, какие есть риски, что принесёт каждая задача, что она может ухудшить. Раньше такой прозрачности не было.
Мария:
За 1,5 года количество команд разработки выросло в два раза, а количество людей примерно в три. У них уже тогда было какое-то количество заказчиков. Проблема в том, что заказчиков было больше, чем ресурсов. В такой ситуации всегда возникает делёжка. В нашем случае она была не слишком структурирована: всё зависело от силы заинтересованности конкретного человека в решении конкретной задачи.
Были моменты, когда люди друг другу рассказывают и выясняют, чья задача важнее, почему это сейчас нельзя не делать. Участникам более широкого собрания это не нравится, потому что они не понимают, о чём спор, хотят видеть конечный результат.
Мария:
Хорошо помню переход на GIST. Сначала было больно, потому что новый процесс ставил людей в новые рамки. Каким бы они ни были благом для конкретного человека, воспринимались в штыки. Выгоды были понятны, но когда ты их ещё не получил, а ограничения уже есть, это вызывает протест. Когда внедряли GIST в первой команде, люди сопротивлялись. А когда дошли до третьей команды, люди уже сами просили внедрить GIST.
Антон:
Сначала нужно было свыкнуться с тем, что у тебя есть соседи по целям и проектам, и с ними придётся делиться ресурсами. Мы аккуратно, постепенно ко всему этому приходили. Начали с доски, в которой мы заводили задачи и описывали их, то есть приучали бизнес к тому, что задачи надо завести. Раньше они просто набрасывали свои идеи, а менеджеры всё заводили.
Затем мы создали отдельную доску, на которой все, кто хочет, могут завести идеи менеджер продукта, разработчик, коллеги из бизнеса. Мы открыты к обсуждению, и даже стали проводить специальные встречи для этого.
Стас:
Чтобы процесс проходил менее деструктивно внутри команд, мы стали заводить задачи разработки в продуктовые эпики. Они же потом стали формировать список проектов Step-Projects. После того, как все привыкли к Step-Projects, мы ввели следующий этап Идеи. Идея, в свою очередь, может состоять из нескольких этапов нескольких Step-Projects.
В тот момент как раз поступила крупная задача на 2,5-3 месяца разработки. Мы её оформили в Идею, выделили MVP это и был наш Step-Project. Дальше его поделили на таски и попытались поставить их на продакшен за два спринта в составе Step-Projectа. Поняли, что идея нам подходит, есть прогресс со стороны бизнеса. Дальше сформулировали следующий этап итерации.
Пока мы делали этот большой эпик, все поняли, какой элемент для чего нужен, где что должно находиться, куда и за какой информацией идти. Примерно отладили процесс. У нас появились регулярные этапы предпланирования, когда мы приоритизировали и проверяли идеи, то есть этап питчинга. Думаю, это и был момент запуска GIST в нашей логистике.
Мария:
Есть очевидный плюс: все команды приоритизируются одинаково, процесс знаком всем сотрудникам в любой команде. Каждый может посмотреть, чем занимается другая команда. Это добавляет прозрачности. Все понимают, что делает команда, и что она делает благо: у задач есть спрогнозированный результат для бизнеса. Все радуются, что эта команда принесёт нам дополнительный прирост KPI там, где он нужен.
Второе это про другой аспект прозрачности: понятно, когда будет сделана задача, которую ты ждёшь. Либо она взята в работу, либо нет. Не нужно звонить менеджеру раз в неделю и спрашивать, когда 1 из 20 задач будет сделана. Это новый и более формализованный способ коммуникации, у которого есть простые и понятные правила. Людям становится намного легче общаться, причём не разговаривая. Всё собрано на одной доске. Экономится куча времени. Важно любить время других людей и уважать его. Не только своё.
У меня есть и личные профиты: в моей жизни стало меньше ответов на вопросы, меньше стресса от того, что нужно много раз людям объяснять. Сейчас даже если задают этот вопрос, можно кидать ссылку.
Антон:
Я не зря возлагал на GIST много надежд. Новый процесс привнёс прозрачность для всех. Все понимают, что мы хотим сделать, зачем это делать, какие ожидаем результаты и сколько это будет стоить.
Да, в редких случаях всё ещё бывают плохо проработанные идеи, у которых понятна ценность, но не проработаны требования. Как правило, мы стараемся не пропускать такие идеи в разработку и просим коллег довести их описание до требуемого состояния. Это описание не для того, чтобы было. Доска служит историей для любого человека, который придёт в компанию или не погружён в текущую задачу. У любого человека в компании должна быть возможность зайти на доску, открыть любую реализованную идею и понять: зачем её брали в работу, что она дала компании, как она работает.
Стас:
У меня не было чётких ожиданий перед внедрением. У меня были проблемы, которые я хотел решить с помощью GIST. И они действительно решились. Но при этом я точно знаю, что у GIST большой потенциал, если его продолжать внедрять. Останавливаться не стоит.
Из плюсов: был прецедент, когда ребята из разработки сами предложили какие-то идеи. У них появился для этого прозрачный механизм. Есть доска идей, есть правила оформления и прохождения через весь этот процесс. Когда у кого-то есть идея, он знает, что нужно зайти, создать задачу, довести её до нужного статуса, указать все необходимые элементы. А потом по этой задаче придёт product-менеджер с вопросами, и дальше она пойдёт в приоритизацию.
Собеседование только полдела. Наинтервью невсегда очевидно, как насамом деле будут устроены рабочие процессы, иреальность может оказаться нетакой радужной. Как выбрать тот проект, где будешь по-настоящему счастлив? НаStack Overflow пользуются тестом Джоела это 12вопросов, которые должны помочь оценить качество работы команды.12простых вопросов, да/нет ответы. Ноэтому списку уже 20лет, иGergely Orosz пообщался сомножеством разработчиков иадаптировал тест ксовременным реалиям. Приводим перевод нескольким блоков икомментарии разработчика: онкак раз недавно вышел работать вновую компанию.
Есть три пункта, которые Джерджели называет базовыми: без них невозможно комфортно работать иразвиваться нановом месте.
психологическая безопасность: чувствуютли себя люди вбезопасности, высказывая мнение, которое отличается отмнения остальной команды?
достойная вашего труда компенсация: получаютли зарплату, которая
соответствует рынку?
гибкие рабочие часы: могутли гибко организовывать своё рабочее
время?
Последний пункт кажется неочевидным, новковидные времена произошло резкое увеличение количества позиций наудалёнке. Поэтому чтобы конкурировать между собой залучших специалистов, компании обязаны проявлять гибкость ввопросах графика.
Начиналось всё неплохо: позвали внебольшой проект. Развивается стремительно, укоманды хороший технический уровень это очень воодушевляет. Апотом всё куда-то скатилось.
Атмосфера нездоровая вечные политические игры. Например, уволили двух коллег, которые впахивали больше всех остальных, причин необъясняли. Даивообще команда малопроизводительная когда никто нехочет работать, становится скучно, хотелось задач поамбициознее.
Они стали релоцировать всех сотрудников вПрагу, иябыл вшаге оттого, чтобы подписать документы нозадумался. Ахочули яподписывать контракт надва года иоставаться скомандой идальше? Неособо.
Доэтого ягод работал вIT-гиганте большая машина, много бюрократии, если появляются свои идеи, как улучшить продукт ихтрудно продвинуть. Планы уменеджеров расписаны надва года вперёд. Поэтому решил придерживаться своей линии: искать какой-то стартап.
Хотелось, чтобы было достаточно много свободы, чтобы команда несоздавала видимость загруженности, адействительно работала. Это должно быть место, где люди горят своим делом.
Аещё мне нравится работать удалённо. Возможность выбирать свой ритм жизни хотелось сохранить.
Может, работникиIT посравнению сдругими специальностями иизбалованы: новедь сдругой стороны, если все компании примерно выровнялись поуровню компенсации, кофе иплюшкам накухне IT-специалисты реально могут себе позволить выбирать тот проект, который по-настоящему откликается, чьи ценности тыразделяешь. Зачем терпеть скучный проект инеприятную команду? Артём С.
Самостоятельные икреативные люди процветают вкомпаниях, где есть ясность процессов, возможность автономности содной стороны исотрудничества сдругой. Накакие стороны работы команды Джерджели предлагает обратить внимание? Могут выполняться 4пункта из5.
За12лет вIT яуспел поработать ивкрупных, ивмелких компаниях. Бросил какое-то место, просто потому что понял, что нецепляет. Ипришёл работать встартап почти бесплатно: потому что попал всуперскую идейную команду. Команда горела: вгод чемпионата пофутболу вРоссии мызапартнёрились сFIFA, Apple сделал фичеринг ивсё это без бюджетов, наодном энтузиазме. Найти правильную схему для монетизации несмогли, поэтому решили разбежаться, носама атмосфера это было круто.
Язадумался обэтом, когда увидел Wheely знал оних идопоиска работы, уменя там есть знакомые. Случайно увидел вакансию, поговорил сребятами, откликнулся через бота так действительно было удобнее. Решил, что нехочу ехать вПрагу, хочу нормально работать.
Ещё ипоидеологическим представлениям совпали: Wheely отказались предоставлять данные опередвижении своих пользователей.
Можно работать наудалёнке иэто правильно, как мне кажется. Яверю, что если человек работает, онбудет работать откуда угодно. Аесли увиливает отответственности, тоивофисе найдёт возможность еёнасебя небрать, Артём С.
Стабильная инженерная культура чтобы специалисты неперегорали наработе инебыли разочарованы. Это принципы, которых придерживается большинство IT-проектов иразработчики могут быстро развиваться внутри компании. Могут выполняться 4пункта из5.
Настаром месте работы было очень много встреч спродактами, бесконечные обсуждения, постоянно что-то разбирали иобговаривали. Ноникак неудавалось наладить процессы внутри команды, что-то постоянно кому-то мешало. Люди были недовольны.
Аоказывается, можно созваниваниваться только раз вдень по15минут, иэтого достаточно всем. Так вообще работает? Все Agile, Scrum ипрочие методологии неработают при разлаженности команды. Достаточно самого минимального усилия, чтобы запустить процессы икоманде было удобно работать.
Ичтобы двигаться дальше, стремиться кчему-то новому нужна эмоциональная составляющая, без неё неполучится. Если проект впринципе неинтересен, успеха, скорее всего, небудет. Вобщем, корпоративная культура формирует заинтересованность разработчика, как мне кажется, Артём С.
Помимо этих двух, автор отдельно выделяет блок про развитие карьеры вконкретной компании: наличие культуры обратной связи, карьерной лестницы, менеджеры стехническим бэкграундом.
Список хорош, нонасколько онприменим напрактике? Джерджели говорит, что судя поего опыту общения сразработчиками изразных стран вполне, имногие инновационные ибыстро развивающиеся компании отFAANG доуспешных стартапов используют эти принципы.
Акак вам кажется, это возможно? Ичто важнее всего вкомпании? Напишите, пожалуйста, вкомментариях.