Припадки

В этой статье хочу поделиться опытом, как мы решили проблему “зависания” задач в нашей компании.

Я работаю в стартапе, который, как и все стартапы, переживает этап роста от 10 человек год назад до 35 человек сегодня, причем количество программистов за это время выросло с 5 до 25 человек и большинство из них пришли за последние шесть месяцев.

Структуру компании, несмотря на ее молодость, я бы назвал старомодной, так как никто и никогда не занимался выстраиванием процессов. При росте мы разделились на команду разработки, команду тестирования и команду девопсов, и все более или менее работало.

Процесс разработки, если его можно назвать “процессом”, был таким:

Работа разработчика заканчивалась, как только код прошел код-ревью и он смерджил его в develop.

Работа тестировщика заканчивалась, когда он протестировал и смерджил в master ветку.
Девопсы иногда нажимали на кнопку «Деплой на прод», после того как на дэйли проджект менеджер скажет: «чет не деплоили давно, может, задеплоим сегодня?».

Что хорошего:

• Много автоматизации, например, статусы в Jira синхронизированы с метками веток в GitLab, задача в Jira закрывается после деплоя на прод, код автоматически деплоится на тестовые и staging окружения при мердже в develop и master соответственно.
• Все вдоль и поперек покрыто тестами.
• Программисты сами пишут тест-планы и тестируют основной функционал.

Проблемы:

• Тестировщики могут неделю заниматься «ничем», т.к. задачи висят в статусе code_review. В конце недели программисты все-таки делают это ревью и в понедельник у тестировщиков куча работы.
• Так как после код-ревью все мерджится в develop и если что-то содержит баг, то мы ничего задеплоить не можем. Пока один разработчик фиксит этот баг, другой может смерджить другую фичу которая тоже содержит баг. Из-за этого мы, бывало, неделю-две ждали, пока эта бранча стабилизируется и тестировщик успеет ее смерджить в master до того, как кто-нибудь из разработчиков накоммитит в develop еще что-нибудь.
• Деплоим фичи большими пачками, что добавляет рисков плохо протестировать или словить что-то во время деплоя.

Опишу два случая, которые дали нам понять, что так дальше работать нельзя.

Так, например, в одну из пятниц у нас было 15 бранчей в статусе code_review, а в понедельник они все сменили статус на ready_for_test. Тестировщики рассказали на дейли, как сильно они нас любят. А еще мы три месяца не могли задеплоить на прод, в силу разных причин, и пары довольно больших фич.

В первую очередь мы разобрались с большим количеством code_review. Оказалось, решить эту проблему можно довольно просто благодаря следующим правилам:

1. В статусе code_review могут находится только три задачи. Это самое важное правило, которое нарушать нельзя.
2. Если программист закончил разработку и хочет перевести задачу в code_review, он смотрит, может ли он это сделать (см. правило 1).
3. Если в статусе code_review уже есть три задачи, то сначала он помогает своему коллеге сделать код-ревью. И если в процессе ревью у него есть замечания или предложения по изменению, то он идет заниматься парным программированием с коллегой, чью задачу он ревьюит.

Главная идея — не давать коду “зависать”, когда он уже написан, и обеспечить тестировщиков равномерным потоком работы в течение недели.

Это мы внедрили за один час: собрались, обсудили и пошли делать ревью и заниматься парным программированием.

Если случается так, что кто-то забывает (а иногда кто-нибудь обязательно забывает) про первое правило, то в чатик сразу же прилетает фраза «We have more than 3 PR in code_review. Let's review!!!». При этом нет специального человека, который следил бы за тем, чтобы не было больше трех пулл реквестов, это делают сами разработчики.

Несмотря на то, что эти изменения позволили не давать задачам зависать, у нас все еще оставались проблемы с деплоями и просачиванием багов в develop. Так как после код-ревью мы всегда мерджили в develop ветку, и она автоматически деплоилась на тестовое окружение для тестирования.

Это решение было своеобразным хотфиксом, а дальше нужно было внести основные изменения в процессы.

Главное, что мы решили сделать — это переместить зоны ответственности. Теперь в компании нет отдельно команды разработки, команды тестирования и команды девопсов, передающих задачи друг другу и отвечающих только за свою часть.

Мы организовали разработчиков в несколько команд: по одной на каждого клиента, так как у нас есть основной продукт, но он кастомизируется под каждого клиента довольно длительный срок (мы — гибрид продуктовой и сервисной компании). Теперь доставка фичи на прод — ответственность команды. Привычных команд тестирования и девопсов нет, зато есть QA as a service, и DevOps as a service.

QA as a service — это команда, которая не занимается тестированием, а обеспечивает качество продуктов. QA инженеры помогают разработчикам писать тест-планы и участвуют в сессиях тестирования. Так мы освободили их от ручного тестирования, и у них появилось время писать end-to-end тесты и разрабатывать тулы для помощи в тестировании. Также мы внедрили систему мониторинга.

DevOps as a service — это команда, которая занимается разработкой скриптов деплоймента, поддерживает работу тестовых окружений, занимается автоматизацией различных задач.

Новый процесс разработки такой:

1. Появляется задача, от заказчика, продакт менеджера или кого-то из топов.
2. На этапе планирования спринта мы берем ее в разработку.
3. Разработчик пишет код, в отдельной ветке для задачи и когда заканчивает переводит ее в статус code_review.
4. Кто-то из коллег делает ревью.
5. Когда задача прошла ревью, разработчик мержит в ветку с задачей все что накоммитили в develop и деплоит эту ветку на тестовое окружение.
6. Затем он планирует митинг который мы называем Test Session и приглашает на него QA инженера и коллег если есть необходимость.
7. QA инженер проверяет и уточняет тест-план до Test Session.
8. На Test Session разработчик в виде демонстрации проходит по всему тест-плану. Иногда тест-план разбивается на части и тогда мы тестируем параллельно. Главное, что это делается вместе, в отдельной комнате для митингов.
9. Если после тестирования багов не нашли, то разработчик мерджит свой код в develop ветку и сразу же в master-ветку (это то, что мы пока не поменяли, так как нужно еще обновить деплоймент скрипты). В будущем планируем оставить только master-ветку.
10. После этого разработчик запускает деплоймент на staging, просто чтобы проверить, что деплой все еще проходит на окружении идентичном проду.
11. Если все ок, то сразу деплоим на прод. Решение, деплоить или нет, принимает именно команда разработки, но у QA есть право остановить деплои если он посчитает, что необходимо дополнительное тестирование, либо что нужно подождать, в случае если необходимо пофиксить какой-то критический баг на проде.

Что интересно, эта трансформация запустила некоторые дополнительные изменения уже не в процессе разработки, а в планировании и изменило темы, о которых мы говорим на дейли.

Теперь, т.к. разработчик ответственный за доставку user story на прод, на планировании мы стали писать user story таким образом, что каждая является независимой от других, и могла бы быть задеплоена тоже независимо, такой deployable unit. User story стало больше, но они стали меньше.

Также на планировании, мы не оцениваем время на разработку, а говорим о том когда мы планируем задеплоить фичу.

На дейли, мы не говорим, что «я закончил разработку», а говорим «сегодня я собираюсь задеплоить фичу X», или “сегодня я забираю тестовое окружение, у кого есть время помочь мне на Test Session?”.

В итоге, у нас появились независимые команды разработки, которые владеют своими собственными тестовыми окружениями и сами планируют, что и когда деплоить.

Автор: sentyaev

Источник ^[1]