Процесс разработки
Смотрите запись нашего вебинара "Как деплоить в прод по многу раз в день и ничего не ломать" - в нем разбираются многие из аспектов, которые вкратце перечислены ниже.
Cкорость и качество разработки - наши главные приоритеты. Эти два требования часто противоречат друг другу, но далеко не всегда. Мы постоянно пробуем что-то новое, и стараемся находить такие решения, которые обеспечат оптимальный баланс скорости и качества. Почти все, что перечислено ниже, вносит тот или иной вклад в ускорение разработки или повышение ее качества.
Наша ключевая методология работы над проектом - привлечь к проекту грамотных людей, и дать им организовать процесс так, как они считают нужным. Несколько лет назад, когда SCRUM был на пике моды, мы тоже не избежали искушения его попробовать, и попробовали. Больше не будем :) Если вам интересно почему - статья Об оценках сроков в разработке ПО подробно разбирает данную тему.
Все наши разработчики имеют возможность общаться с заказчиком напрямую. Нет никаких испорченных телефонов в виде менеджеров, аналитиков, и пр. Менеджеры у нас есть, но они занимаются не передачей информации от одних людей к другим, а решают различные организационные вопросы, помогая разработчикам полностью сфокусироваться на проекте и не отвлекаться на несвязанные с разработкой детали, а также помогают решать проблемы в коммуникации когда они возникают.
В общении с заказчиком мы стараемся придерживаться максимальной прозрачности нашей работы и частой демонстрации результатов. Взамен на нашу открытость мы просим заказчиков, по возможности, не требовать от нас оценок по срокам. Оценки по срокам негативно влияют на процесс разработки, они замедляют его и формируют у участников проекта искаженные представления о реальности. Если требуется четко уложиться в какой-то определенный срок, мы стараемся следовать подходу Fix Time and Budget, Flex Scope.
У нас нет специально выделенных тестировщиков. Раньше они были, но постепенно мы пришли к тому, что разработчики должны сами тестировать свою работу, потому что так получается быстрее и эффективнее. Естественно, мы активно полагаемся на автоматизированное тестирование. Рекомендуемая литература по этой теме:
Весь код хранится на GitHub, и не только код. Параметры настройки серверов, скрипты развертывания, документация, вики - все здесь.
Большинство наших проектов размещены на хостинге Amazon Web Services, и мы активно используем возможности этой платформы.
Мы следуем концепции "ничего не делать на серверах вручную". Вся настройка серверов и выкладка кода в продакшен полностью автоматизированы. Для любых ценных данных, которые могут храниться на серверах, мы обязательно предусматриваем автоматизированное резервное копирование. Благодаря этому, а также хостингу на облачной платформе, отказ любого из наших серверов не является катастрофой, мы всегда можем автоматически развернуть точно такой же новый за считанные минуты.
Настройка полностью автоматизирована на основе Docker Compose и вспомогательных скриптов. Для разработки мы используем тот же самый образ окружения проекта, который работает в продакшене.
На всех наших проектах мы применяем непрерывную поставку кода в продакшен. Коммиты в ветку master приводят к тому, что Jenkins немедленно начинает автоматизированную сборку проекта, прогоняет критические тесты, и, если все в порядке, тут же выкладывает новую версию в продакшен.
Скрипты сборки в продакшен настраиваются таким образом, чтобы пользователи ничего не замечали, мы стараемся свести вероятность даунтайма к нулю. Это дает нам возможность выкладывать код в продакшен очень часто, по нескольку раз или даже десятков раз в день, и мы этим постоянно пользуемся.
Хорошо настроенные скрипты выкладки очень помогают с обеспечением Zero Downtime, но о некоторых вещах разработчикам приходится помнить самостоятельно, в частности, о подходе к миграции базы данных. Вот рекомендуемая статья по теме, как мигрировать базу данных в проде без даунтайма:
Мониторинги - важнейшая деталь в обеспечении стабильной работы продакшена. Мы используем Sentry для мониторинга ошибок, Datadog, New Relic и AWS CloudWatch для мониторинга серверов и приложений.
Во многих проектах общепринятой практикой является создание ветки для работы над новыми крупными фичами. Идея при таком выборе заключается в том, что дестабилизация из-за нового кода не будет влиять на других разработчиков и пользователей. Когда фича завершена, она вливается в master, после чего обычно следует период нестабильности пока устраняются интеграционные вопросы.
У нас этот подход не работает, поскольку мы используем Continuous Deployment и релизимся по несколько раз в день. Во-первых, внезапное появление больших блоков нового кода в master нежелательно, поскольку это затрудняет ревью кода и увеличивает вероятность ошибок. Во-вторых, проект движется вперед с такой скоростью, что для разработчиков очень непрактично оставаться изолированными на своей ветке на долгий промежуток времени. К тому времени, когда они начнут вливать свою ветку, master уже будет выглядеть настолько по-другому, что интеграция будет трудоемкой и легко подвержена ошибкам.
Иногда в отдельных исключительных случаях мы создаем дополнительные ветки к master, но стараемся, чтобы они жили недолго и были удалены как можно скорее. Если вы еще не очень хорошо освоились в нашем процессе разработки, то вот примерное правило - как определить, можно ли вам создать новую публичную ветку: "нет, нельзя". Естественно, это относится только к веткам в главном репозитории на Github. Если по каким-либо причинам вам удобно работать с ветками в вашем локальном окружении разработки, то это пожалуйста. Но в главный репозиторий никакие ветки попадать не должны, равно как и следы их использования (коммиты типа "merge").
Мы используем неблокирующие код-ревью, которые проводятся пост-фактум, уже после попадания кода в master. По нашему опыту, это наиболее оптимальный вариант, который обеспечивает наилучший баланс качества, скорости разработки и комфорта для разработчиков.
В случае блокирующих код-ревью разработчики вынуждены ждать (порой по нескольку дней), пока их код пройдет ревью, и, соответственно, на время ожидания переключаться на какую-то другую работу, а после получения результатов ревью - возвращаться к своей прежней задаче. Если постараться минимизировать задержки на блокирующие код-ревью, то это приведет к частым отвлечениям ревьюверов, т.к. они будут вынуждены прерывать свою текущую работу, чтобы побыстрее посмотреть очередную порцию коммитов.
Основным аргументом за блокирующие код-ревью, как правило, называется снижение вероятности попадания проблемного кода в основную ветку. Однако, в нашей практике эффективность такого подхода мала. Во-первых, благодаря автоматизации мы заметно сужаем круг проблем, которые могли бы обнаруживаться на код-ревью. Нарушения код-стайла у нас блокируются линтерами, встроенными прямо в деплой. Регрессии основной функциональности обнаруживаются тестами. Во-вторых, по опыту мы практически не находим критичных проблем на код-ревью. Типовые проблемы, которые мы находим - это не совсем оптимальный или неконсистентный код, или же упускание каких-то краевых случаев. Исправление подобных проблем пост-фактум не несет в себе каких-то серьезных рисков для общей стабильности системы, но в то же время дает возможность разработчикам поставлять свой код гораздо быстрее и с минимумом переключений.
English
Русский