Припадки


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

    Я работаю в стартапе, который, как и все стартапы, переживает этап роста от 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?”.

    В итоге, у нас появились независимые команды разработки, которые владеют своими собственными тестовыми окружениями и сами планируют, что и когда деплоить.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 8

      0
      Я работаю в стартапе
      Кем если не секрет? Всегда интересно узнать точку зрения на проблему с разных команд. Может получиться что будут по кругу вину передвигать друг на друга.

      Было бы интересно ещё стэк продуктов указать, что помогает, что не очень нравится.

      По поводу код ревью — у вас минимум один человек должен провести или нужно/можно несколько? Используются ли специфичные инструменты для ревью? Данные по результатам ревью вообще как-то используются или провели ревью и забыли что там было.

      Как в команде отношение — как к необходимому злу или ценят фидбэк?
        0
        Кем если не секрет? Всегда интересно узнать точку зрения на проблему с разных команд. Может получиться что будут по кругу вину передвигать друг на друга.

        Официально я Software Developer. В этом я вижу плюсы работы в стартапе, эти изменения появились как результат разговора программиста и тестировщика. Те изменения которые мы уже сделали в структуре компании как раз направлены на то, чтобы команд небыло. Т.е. компания состоит из независимых команд.

        Было бы интересно ещё стэк продуктов указать, что помогает, что не очень нравится.

        Ничего интересного, GitLab, Jira, Confluence, Jenkins. Это же просто инструменты. Но я не уверен правиль ли я понял вопрос.

        По поводу код ревью — у вас минимум один человек должен провести или нужно/можно несколько? Используются ли специфичные инструменты для ревью? Данные по результатам ревью вообще как-то используются или провели ревью и забыли что там было.

        Как в команде отношение — как к необходимому злу или ценят фидбэк?

        Договорились что минимум два аппрува.
        Я не понимаю зачем использовать данные по результатам, могли бы привести примеры?
        У меня есть личное отношение к ревью, я не считаю его сколько нибудь полезным в компании, где нанимают только опытных разработчиков. Я стараюсь заниматься парным программированием, в этом случае смысл в ревью пропадает, но не всем это нравится. Поэтому бывает парное программирование, бывает ревью. Но все люди взрослые, по крайней мере в этой компании, и на ревью обсуждаются только важные вещи.
        0

        Проблема "успеть смержить develop пока туда не накоммитили" вообще-то в gitflow решается заведением релиз-веток. При принятии решения о заморозке фич очередного релиза от develop форкается ветка release-x.y.z, и все работы по исправлению ошибок в дальнейшем идут в ней.

          0
          Мы делаем continious delivery, у нас нет релизов, и мы не используем каноничный gitflow.
          Так было вначале, но с ростом числа разработчиков этот процесс стал сбоить, но нам хочется продолжать деплоить фичи на прод, как только так сразу, и не ждать даты релиза.

          Мы еще это не сделали, но пытаемся отработать схему, где у нас будет только master b feature_branch ветки, и каждый коммит в мастер автоматически деплоит на staging с последующем промоушеном на прод.
            0
            Девопсы иногда нажимали на кнопку «Деплой на прод», после того как на дэйли проджект менеджер скажет: «чет не деплоили давно, может, задеплоим сегодня?».

            Что-то не очень не похоже на continious delivery :-)


            но нам хочется продолжать деплоить фичи на прод, как только так сразу, и не ждать даты релиза

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

              0
              Что-то не очень не похоже на continious delivery :-)

              Собственно да, поэтому и нужны были изменения.

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

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

                0

                Ну, пока удаётся удерживать фичи независимыми это даже будет работать...

        Only users with full accounts can post comments. Log in, please.