Компания
242,68
рейтинг
14 февраля 2013 в 17:02

Разработка → AIDA. Автоматизация работы с Git, JIRA и TeamCity

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

AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.

В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).

Git Workflow


В качестве системы контроля версий Badoo использует Git. Особенность нашей модели состоит в том, что каждая задача разрабатывается и тестируется в отдельной ветке. Её название состоит из номера тикета в JIRA и свободного описания задачи.
Релиз мы собираем и тестируем из отдельной ветки, в которую сливаем завершённые задачи. Так как код на боевые серверы выкладывается два раза в день, то создаются две новые ветки для релиза.
Наименование у релизной ветки простое: build_{дата релиза}_{время}

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

Ветка master для нас является копией production. Как только build обновляет код на серверах, он сливается в ветку master. Также из этой ветки раскладываются срочные фиксы на площадке.

Данная схема отображена на рисунке:



Тестирование идет в несколько этапов:
  • Devel — первый этап тестирования, каждая задача проверяется на development environment, её смотрят на тестовых базах и запускают unit-тесты.
  • Shot — проверяется задача в боевом окружении. Физически это папка на сервере, в которую выкачивается ветка репозитория и настраивается nginx; имеет свой домен первого уровня — .shot. На этом этапе генерируются переводы на основные языки.
  • Staging — релиз тестируется в боевом окружении, переводится на все языки, полностью мониторится. Повторно проверяются все задачи.

Если с задачей в релизе что-то не так, то мы откатываем ветку с ней при помощи git rebase. Эта функция используется не случайно: нам не подходит revert, так как после отката релизная ветка сольётся в master, а ветки с задачами постоянно из него обновляются. В итоге, когда разработчик проблемной задачи обновит свою ветку, его код пропадёт, и придётся делать revert на коммит revert.

AIDA и Git


Из-за большого количества веток в описанной выше модели возникает множество задач на слияние веток, формирование релиза и контроль кода. Рассмотрим их автоматическое решение:
  • Прежде всего AIDA создаёт ветку build. Она «слушает» ветку master, и если предыдущая ветка релиза сливается в master, то создается новая ветка.
    image
  • Затем в новую ветку релиза каждую минуту сливаются ветки с уже выполненными, протестированными и соответствующими шаблону в JIRA задачами. Если при слиянии происходит конфликт, разработчику и релиз-инженеру приходит уведомление о нём, а задача перенаправляется разработчику.
    image
  • Так как ветка master является копией кода, разложенного на боевых серверах, и в неё добавляются изменения, её нужно постоянно объединять с веткой релиза. AIDA выполняет это слияние, если зафиксировалось изменение в ветке master. При конфликте появляется соответствующее сообщение.
  • Если после слияния с веткой релиза разработчик добавит изменение в ветку с задачей, то этот коммит будет пойман и AIDA сообщит об этом.


AIDA и JIRA


Для контроля разработки, формирования релиза и тестирования мы используем JIRA. Workflow во всех проектах полностью проработан и формализован. В процессе разработки и тестирования часть работы в баг-трекере выполняет AIDA.
В основном она помогает нам перемещать задачи либо отображает ту или иную информацию в них. Вот несколько примеров:
  • разработчик фиксирует изменения кода в центральном репозитории, статус тикета автоматически меняется с Open на In Progress;
  • если для тикета создается Shot (код выкладывается в отдельное боевое окружение), то статус задачи автоматически меняется на In Shot;
  • Тикет автоматически открывается повторно при откате задачи из релизной ветки;
  • если задача прошла процедуру проверки кода и после этого следует изменение в ветке, то тикет возвращается на проверку.

Также она помогает поменять статус задачи, если есть определенные резолюции:
  • Fixed & Deploy on Production — тикет автоматически меняет статус на On Production

AIDA сообщает нам обо всех своих действиях с задачами.
Данная автоматизация значительно упрощает работу с workflow и избавляет от рутинных действий.

AIDA и TeamCity


При сборке и автоматическом развёртывании на тестовом окружении мы хотели полностью избавиться от рутинных действий, но приходилось вручную прописывать меняющиеся имена веток релиза в проектах CI-сервера. На данный момент TeamCity отлавливает изменения во всех ветках по заданной маске (в нашем случае это маска build_* ) и запускает сборку. К сожалению, существует одна проблема: мы не можем убрать из конфигурации проекта ветку default, и если туда приходят изменения, мы её просто игнорируем. При этом ветка вытягивается, а мы теряем ресурсы и время. Очень надеемся, что разработчики CI-сервера вскоре исправят эту проблему.
Ссылки на тикеты:
Support branch specification in the VCS trigger rule
Ignore default VCS branch, only use branch specifications for change tracking

Давайте посмотрим, что в итоге получается со сборкой и автоматическим развёртыванием:
  1. Проект в TeamCity настроен на ветки с маской build_*.
  2. После изменений в ветке релиза запускается автоматическая сборка.
  3. При успешном выполнении стартует скрипт развёртывания на тестовые сервера.
  4. С помощью быстрых smoke-тестов ( используем простой curl) проверяется тестовое окружение.
  5. Если тесты не проходят, версия релиза помечается как плохая и происходит откат на предыдущую (хорошую) версию релиза.



Вся процедура занимает три минуты. Тесты выявляют только фатальные ошибки. При этом все unit-, авто- и функциональные тесты запускаются параллельно.
Сделано это для того, чтобы тестировщик как можно быстрее увидел задачу в тестовом окружении.

Итоги


Давайте посмотрим, какие действия у нас автоматизирует AIDA:
  1. Работает с Git, создаёт ветки, сливает их, предупреждает нас, если что-то идёт не так.
  2. Взаимодействует с JIRA, автоматически меняет статусы и обновляет информацию в задачах.
  3. Помогает TeamCity запускать скрипты, тесты и производить развёртывание на тестовую среду.

AIDA умеет многое, но мы не останавливаемся на этом и хотим научить нашу помощницу следующим действиям:
  • автоматическое применение патчей для Git из специального интерфейса для сбора, контроля, учёта и формализации патчей, с полным перечнем информации и автоматическим оповещением;
  • полностью автоматический rebase задачи из build-ветки по смене статуса тикета в JIRA;
  • автоматический запуск unit-тестов для каждой ветки задачи в момент её завершения и после изменения статуса в баг-трекере с последующим отчётом в JIRA.

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

P.S Создавайте себе хороших помощников, которые не подведут вас в трудную минуту!
Автор: @vchernov
Badoo
рейтинг 242,68

Комментарии (52)

  • +9
    Фотка зачетная!
    • +1
      Ахмед, мёртвый программист.
  • +1
    Интересно, а размер самого репозитория при столь большом количестве веток сильно разрастается?
    Нет ли проблемы конечному разработчику банально все это выкачать в свое локальное окружение?
    • +1
      Так реп же Гитовый — там хранятся changeset'ы, а не версии файлов целиком.
      • +2
        Так реп же Гитовый — там хранятся версии файлов целиком, а не changeset'ы, отличная статья на эту тему: habrahabr.ru/company/badoo/blog/163853/
        • +5
          Вы оба правы и не правы одновременно :). Гит внутри себя предоставляет API, который оперирует объектами целиком, но при этом в .pack-файлах хранит уже с дельта-компрессией.

          Размер репозитория в git от количества веток не сильно зависит — важно только количество коммитов. Размер репозитория составляет около 500 Мб.
    • 0
      Можно выкачивать только нужные ветки, при желании.
      • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Выкачать нужно один раз, поэтому проблем особых нет. Со скоростью работы с таким репозиторием тоже особых проблем не ощущается — тот же git status на моей машине отрабатывает за 150 ms. Основной источник «тормозов» — это переключение между ветками в случае, если ветки «долгоживущие».
      • +2
        У меня git status на непрогретом кеше идёт 2 сек, затем по 200мс, checkout 4000 файлов древней ветки 5 сек, мерж свежего мастера 6 сек, меня это ни сколько не печалит, страшнее процесс git gc при котором можно идти пить чай ;-)

        Возможно сравнивается скорость работы с svn, при котором доступ к центральному серверу и его тормознутость способна вогнать в тоску…
    • +1
      «Цена» ветки в git — около 40 байт.
      Размер репозитория растёт не очень быстро. У нас за больше чем 5 лет развития проекта исходники занимают всё ещё больше места чем вся папка .git (которая содержит всю историю проекта).

      При выкачивании с нуля по сети передаётся примерно 70 Mb — 1-2 минуты, чтобы склонировать центральный репозиторий (включая время на локальную распаковку). Ежедневный инкрементальный pull из центрального репозитория занимает меньше 15-30 секунд.
  • 0
    Данная система, как я понимаю, подходит для небольших задач. Поправить то, добавить это.

    А как быть, если нужно сделать новую большую функциональность?
    Разработка которой требует пары недель, несколько разных программистов. Т.е. ветки будут передаваться друг другу и из надо периодически тестировать.
    Так вот — где их тетсировать до выкладки в build ветку?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Спасибо, неправильно осмыслил статью :)
        Воспринял, что шоты только после создания билд ветки, хотя в статье, даже с картинками все описано.

        Хотфиксы выкладываются вне очереди, или тоже ждут релиз?
        • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Хотфиксы выкладываются незамедлительно с помощью отдельного инструмента, который копирует по одному-два файла (mscp)
        • 0
          Так как для нас «master branch — копия продакшена», то да, если это действительно хотфикс — то выкладывается сразу разработчиком и коммитится в мастер релиз-инженером. Но есть и нюансы, связанные с исправлением статики и шаблонов — для них нужен полноценный билд.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Эх, про переводы бы статью :)
              • +1
                Не волнуйтесь, всё будет, со временем :).
            • 0
              Знаю-знаю, но всё же не просто mscp :)
    • +1
      И даже многомесячные ветки были. Если не забывать регулярно в долгие ветки подтягивать свежий мастер — никаких проблем.

      Тестируются до билда все ветки на девеле и (не ИЛИ, а именно И) в боевом окружении, в т.н. шотах. Шоты — тема для отдельной статьи, не буду отбирать у авторов этого великого творения право высказаться :)
    • 0
      Помимо шотов и одного стейджинга, для больших задач у нас есть ещё «запасной» стейджинг, на котором могут тестироваться большие и длинные задачи, которые не мержатся в общий build. Тем не менее, такое требуется весьма редко, обычно хватает описанной выше схемы (обратите внимание на функциональность шотов).
      • 0
        На HPC в прошлом году с удовольствием прослушал ваш доклад про быстрый деплой на 1000 серверов. Даже немного помучал вас вопросами.
        Там вы, в том числе, рассказывали про схему разработки.
        Я ещё немного помучаю про шоты:
        — Зачем шот тестировать на боевом окружении? Есть ведь staging. Почему не оттестировать шот на разработческих серверах?
        Каждая ветка-фича должна пройти шот?
        — Как получить доступ к своему шоту? Как я понимаю, что-то типа 112233.badoo.shot?
        — процесс выкладки шота полностью автоматический? Включая настройки nginx? Выкладывается сразу на все сервера? База в шотах боевая?
        • 0
          Зачем шот тестировать на боевом окружении? Есть ведь staging. Почему не оттестировать шот на разработческих сервера?

          У нас шоты — это отдельный staging для каждой задачи. Поэтому не имеет смысла говорить о «шотах на разработческих серверах», потому что само понятие шота означает работу в production-окружении. Как было сказано ранее, сначала задачи тестируются на девел-серверах, потом в «шотах» и только потом на staging-сервере. Первый шаг исполняется на девел-сервере, последние два — в production-окружении.

          Каждая ветка-фича должна пройти шот?

          В целом — да, но есть исключения (например, ветка затрагивает работу над системой деплоя).

          Как получить доступ к своему шоту? Как я понимаю, что-то типа 112233.badoo.shot?

          Да

          процесс выкладки шота полностью автоматический? Включая настройки nginx? Выкладывается сразу на все сервера? База в шотах боевая?

          Процесс выкладки шота полностью автоматический, но он выкладывается только на один сервер. Nginx настроен таким образом, что достаточно просто создать новую папку ".../shot/<shot-name>", и он становится доступен по адресу "<shot-name>.badoo.shot".
          • +1
            Т.е. шот тестируется уже с боевыми базами. Как тогда проверить какой-либо функционал, который использует записи в базе?
            Например, если написать blablabla в статусе то это увидят 100500 человек, хотя для них это не доступно (функционал ещё не введен).

            P.S. Спасибо за подробные ответы :)
            • 0
              Как тогда проверить какой-либо функционал, который использует записи в базе?

              Ну так ведь
              Как было сказано ранее, сначала задачи тестируются на девел-серверах


              А если какая-то фича ещё не введена, то обычно её сначала включают для разработчиков, потом для всех сотрудников, потом для фокус-группы. Ничего лишнего простой пользователь увидеть не должен. Это, в том числе, позволяет не делать очень долгоживущие ветки — можно релизить частями.
  • +2
    И ещё вопрос. Может невнимательно посмотрел, не увидел в статье.
    На каком моменте удаляются ветки? Они удаляются вручную или автоматически?
    Сколько у вас сейчас веток git branch --all?
    • +1
      Около 2500 веток, возможно более интересно сколько смержено с мастером и сколько нет: 2000 и 500 соответственно. Смерженные повисят некоторое время и удалятся автоматически.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ужас какой. Зачем вам столько веток? Почему бы не удалять смёрдженные сразу? Если нужна какая-то пометка, то целесообразнее использовать теги.
        Чем плохо такое кол-во веток? Ну например, выполните git branch --contains <hash>
        • 0
          Зачем удалять если можно не удалять :) Технически ветки ничем не отличаются от тегов, лишние телодвижения по созданию тега, удалению ветки только усложнят и без того не простой процесс.
          А баш-гит-комплитеру всё равно: он ищет и в ветках и в тегах.

          $ time b --contains de88e382df3041d43f2aabca9e68a3aee8d1a2d3 PLATFORM-4227_pause_in_edit real 0m1.996s
          Очевидно что эта команда роется только в локальных ветках, которых вовсе не 2000 штук, а не более 10. Возможно имелось ввиду git branch -a…
        • +1
          Мы весьма быстро удаляем смержденные ветки ;). У нас просто очень много тикетов в трекере, которые открыты одновременно и в которых ведется разработка.
  • +1
    А можете рассказать про миграцию БД? Она как-то привязана к этой схеме или используются другие механизмы для миграции и отката?
    • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      У нас миграции DB в большинстве случаев безопасные. Либо мы добавляем новое поле — и оно ничего не ломает, потому что еще нигде не используется. Либо удаляем поле — это делается уже после вычистки кода от использования этого поля. Вобщем миграции к выкладке почти не привязаны, ничего нетривиального в них нет и особых проблем с ними тоже нет.
    • +1
      На основном сайте миграцию БД (с остановкой сайта на время миграции) мы не используем. Во внутренних сервисах миграция БД производится «руками». Если требуется существенное изменение схемы, мы временно останавливаем работу соответствующего компонента.
  • +1
    На HTC вы рассказывали, что релиз у вас собирает релиз-мастер. Вы его уволили? AIDA вы настроили недавно получается?
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Как разработчик использует этот тул? Т.е. это демон, gui утилита или маленький гномик вылезающий ночью из норки?
    • 0
      JIRA — веб-интерфейс
      AIDA работает в виде демонов на разных серверах
      Создание шота и выкладка на production производится с помощью консольных утилит
    • 0
      С другой стороны, вариант с гномиком тоже хороший.
  • +1
    Какую часть этой автоматизации пришлось писать руками? Сколько это примерно заняло времени, если это создавалось разом. Или за какой период вы от нету автоматизации смогли прийти к вашему решению?
    Происходят ли сбои?
    • +1
      Большвя часть уже была написана, она была просто внедрена в teamcity в процесс автоматической сборки. Продумывание и реализация системы билдов, шотов, переходов между задачами было начато примерно год назад и продолжается по сей день, система всё ещё развивается. Автоматизация большинства вещей была сделана за пару месяцев.

      Сбои происходят, но исключительно редко: после того, как всё настроено, оно работает как часы.
  • +1
    Спасибо за статью, прочел с удовольствием. Есть над чем задуматься, но вот меня всегда мучает вопрос, как проходит деплой базы, при столь больших объемах
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Как происходит контроль версии БД, слияние, Перенос изменений БД stage -> production
        • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Сколько времени ушло на проектировку и настройку AIDA в вашей компании? + Сколько людей было задействовано в этом процессе?
    • +2
      Работы над системой сборки и деплоя начались где-то год назад и продолжаются до сих пор.
      AIDA спроектировали и сделали за пару месяцев, но она постоянно дорабатывается.
      Если оценивать проектирование, разработку и инфраструктуру под ней то 5-6 человек
  • 0
    Интересно, какие ещё пасхалки кроме 1pm и 7pm я проглядел?

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

Самое читаемое Разработка