Процесс разработки - ivelum/job GitHub Wiki
У нас несколько команд, работающих над разными проектами, и процессы в них могут отличаться. Тем не менее, у нас есть наш любимый подход, который описан ниже и к которому мы стремимся.
Практически все наши вакансии для разработчиков предполагают работу не только над беком и фронтом, но и самостоятельное тестирование своей работы и выкладку ее в продакшен. Мы выбрали такой курс много лет назад, и сейчас почти все наши разработчики — full-stack.
По нашему опыту full-stack подход существенно ускоряет разработку и улучшает внутреннее качество продукта. Он также позволяет держать команды небольшими и гибкими и упрощает управление проектом. Подробнее об этом в статье в нашем блоге.
Изначально слово DevOps означало такую организацию работы команды, при которой роли "dev" и "ops" не разделяются, а объединяются. Когда в середине 2010-х годов движение DevOps активно набирало популярность, многие компании, которые попробовали внедрить у себя этот подход, столкнулись с серьезными трудностями. Объединение "dev" и "ops" требовало радикальной перестройки того, как команды работают, и далеко не все оказались к этому готовы. Однако был найден весьма оригинальный выход — изменить само понятие DevOps. Так стали называть выделенную роль, упрощенно говоря, сисадмина со знанием Kubernetes и умением настроить CI/CD. Смысл понятия исказился практически полностью, но зато компании смогли отчитаться, что внедрили DevOps, не испытывая при этом серьезных потрясений.
Так вот, мы практикуем DevOps в его изначальном понимании, то есть не как конкретную роль в команде, а как ее отсутствие, чтобы не было разделения на "dev" и "ops". Это означает, что все разработчики имеют нужные навыки, понимают, как работает продакшен и CI/CD, и могут их настраивать, оптимизировать и решать возникающие проблемы.
Мы стараемся, чтобы в каждой команде было четко понятно, кто отвечает за продукт. Это может быть продакт-менеджер или представитель заказчика, или для небольших стартапов - основатель стартапа. От такого человека мы ожидаем постановки задач на бизнес-уровне, чтобы было понятно, что мы хотим сделать и зачем. Разработчики, в свою очередь, предлагают решения — как именно реализовать эту задачу. Если для некоторых задач автор уже указал предлагаемый путь решения, мы стараемся, чтобы это было открыто к обсуждению, чтобы разработчик мог предложить свои альтернативы.
Мы приветствуем прямую коммуникацию между инициатором задачи и ее исполнителем без посредников в виде менеджеров или аналитиков. Мы не любим играть в "испорченный телефон", поэтому стараемся, чтобы все наши разработчики имели возможность общаться напрямую с теми людьми, от которых исходит поставленная им задача. Тимлиды или продакт-менеджеры в наших командах, конечно, есть, но они выступают не как передаточное звено, а скорее, как модераторы дискуссии.
Также мы стараемся вести большую часть общения по проекту в открытом режиме, на виду у всей команды. Это могут быть командные чаты, таск-трекеры или же митинги, на которые приглашаются все желающие. Открытая коммуникация способствует быстрому распространению информации в команде, помогает выявлять противоречия и быстрее находить оптимальные пути решения.
Далеко не всегда это получается, но там, где возможно, мы стараемся избегать повальной оценки задач по срокам. Оценки замедляют работу команды и создают опасные ментальные искажения у людей, причастных к проекту. См. подробнее в видео на нашем канале:
Хорошо отлаженный процесс разработки подразумевает, что деплои в продакшен могут происходить по многу раз в день, не вызывая при этом никакого даунтайма и не создавая неудобств пользователям. Чтобы это действительно хорошо работало, требуется ряд условий:
- Полная автоматизация. Мы автоматизируем деплои в продакшен на CI/CD и применяем автоматизированное управление инфраструктурой (IaC) при помощи Terraform и CloudFormation.
- Zero-downtime deployment. Грамотно настроенная автоматизация позволяет исключить подавляющее большинство причин, по которым может произойти даунтайм во время деплоя, но некоторые случаи, тем не менее, все же требуют внимания со стороны разработчика. См. статью и видео в нашем блоге с подробным разбором.
- Культура тестирования. Важны и автоматизированное тестирование, и ручное, и код-ревью, и бета-тестирование первыми пользователями. Чуть ниже описано, как мы подходим к этому.
- Мониторинги продакшена. Почти на всех наших проектах мы используем Sentry для мониторинга ошибок в продакшене, также в зависимости от проекта применяем DataDog, New Relic, CloudWatch или другие средства для мониторинга производительности приложения и общего состояния системы. Раннее обнаружение аномалий помогает уменьшить или полностью предотвратить импакт для пользователей в случае возникновения проблем в продакшене.
Когда-то давно, много лет назад, у нас в компании были тестировщики. Однако с тех пор мы пересмотрели подход к тестированию и пришли к выводу, что качество продукта заметно улучшается, когда разработчики сами занимаются тестированием. Мы не единственные, кто пришли к такому выводу, например, см. книгу How Google Tests Software. Сейчас выделенных тестировщиков у нас нет, и в обозримом будущем не предвидится — мы не нанимаем на QA-позиции.
Наши разработчики сами проводят ручное и автоматизированное тестирование, делают код-ревью, стараются держать технический долг под контролем, используют автоматический мониторинг продакшена и пишут пост-мортемы в случае сбоев.
Мы стараемся избегать нескольких долгоживущих веток и работать в основном только с одной веткой — main (или master). Такой подход наилучшим образом совместим с Continuous Delivery и частыми релизами в продакшен. Также он стимулирует небольшие частые обновления вместо вливания больших кусков функционала в основную ветку, что снижает риски поломок и позволяет быстрее и проще выявлять проблемы при обновлениях.
Вместо фича-веток мы используем фича-тоггли, что позволяет вливать еще не завершенную работу в основную ветку и демонстрировать новый разрабатывающийся функционал прямо на продакшене, без использования стейджинга или другой демонстрационной среды.
Стейджинг замедляет разработку, ломает Continous Delivery и, парадоксальным образом, приводит к ухудшению общего качества продукта, не говоря уже о дополнительных трудозатратах на поддержание самого стейджинга. Смотрите подробный рассказ об этом в видео на нашем канале:
Пулл-реквесты — пожалуй, самый распространенный способ проведения код-ревью, но далеко не единственный. Есть как минимум две альтернативы:
- асинхронное неблокирующее ревью — код сначала вливается в основную ветку, и потом его кто-то смотрит;
- синхронное ревью в режиме телемоста — когда автор и ревьювер созваниваются и вместе смотрят на код.
Каждый вариант имеет свои преимущества и недостатки, и в зависимости от команды и ситуации мы используем разные подходы или их комбинации.