“Покращення вже сьогодні” или оптимизация процесса разработки

C ростом IT-компании разработчики все меньше начинают заниматься непосредственно написанием кода и все больше – сопутствующими задачами: заполнением метрик в системе трекинга ошибок, написанием огромного количества писем для того, чтобы договориться с разработчиками другого компонента, ожиданием ответов со стороны заказчика/QA/потребителя, развертыванием среды разработки, ручным тестированием и т.д. Так же с увеличением кодовой базы и накоплением взаимосвязей компонентов в продукте все труднее предсказать дату выхода новой версии. Подход с выпуском новых версий продукта “по готовности” всегда срывает все объявленые заказчику сроки, даже самые пессимистичные.

Ниже рассмотрен комплекс мер, направленных на увеличение эффективности разработки и снижение ее бюрократизации, примененный в компании PortaOne, Inc. и приведший к существенной оптимизации организационных процессов.

Практически все разработчики ПО – люди, которые любят писать новый код и не любят тратить время на сопутствующие этому процессу издержки.

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

• отменена заморозка веток в системе контроля версий;
• экстремально сокращено время необходимое на развертывание среды разработки;
• организован автоматический запуск юнит-тестов на каждый коммит;
• организован автоматический запуск тяжелых функциональных тестов;
• ускоренно получение отзывов (багрепортов) от отдела QA и заказчика.

Целью заказчика разработки (внешнего или внутреннего) является получение новых функциональных возможностей (фичей) как можно быстрее, при стабильно низком количестве программных ошибок (багов).

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

• организован выход новых версий продукта, с заказанными новыми функциональными возможностями, точно в срок, по календарю.
• так как новые функциональные возможности могут иметь ошибки, организован выпуск новых версий продукта только с исправлениями (без новых функциональных возможностей) точно в срок, по календарю.
• что бы уменьшить количество ошибок – все изменения, перед тем как попасть в центральный репозиторий, проходят процедуру рецензирования и автоматически проверяются тестами.
  
  

Отмена заморозки веток в системе контроля версий

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

Назовем запрет на добавление новой функциональности – желтой зоной. А запрет на любые изменения – красной. Логическим завершением красной зоны является выход новой версии продукта.

Такой подход создает искусственные временные издержки на фиксацию (коммит) готовых изменений в репозитории. Разработчик, который написал новый код, не может зафиксировать изменения, в результате он должен не забывать о них довольно продолжительный период времени. Когда разработчиков много, количество зависших коммитов может увеличиваться до нескольких сотен.

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

Главная ветвь разработки (trunk/master) всегда открыта для приема любых новых функциональных возможностей.

В определенный момент времени (по календарю) от главной ветви “отщепляется” новая ветвь, в которой будет проходить стабилизация готовых на тот момент программных возможностей. Эта ветвь сразу становится желтой, т.е. в неё запрещено добавлять новые функциональные возможности, только стабилизировать текущие.

В определенный момент времени от желтой ветви отщепляется красная ветвь. В красную ветвь можно коммитить только по запросу QA отдела.
В определенный момент времени (по календарю), на красной ветви проставляется аннотированная метка (тег) нового релиза.
К этому моменту QA отдел должен завершить тестирование новой версии продукта. Если какие-то новые программные возможности не готовы и блокируют выпуск новой версии, они должны быть удалены.

Если после проставления аннотированной метки, заказчик или отдел поддержки/эксплуатации находит критический баг, тогда отдел QA запрашивает коммит с исправлением в красную ветвь. После этого на красной ветви проставляется аннотированная метка хотфикса.
Данный подход позволяет разработчикам фиксировать изменения в любой момент времени, потому что главная ветка проекта всегда готова к приему любых изменений, желтые ветки в любой момент готовы к приему исправлений.

Наращивание новых функций и стабильность

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

Для первого типа заказчиков предлагается раз в год выпускать Long Term Support (LTS) релиз (релиз – это нулевой билд, x.0 версия), который будет стабилизироваться в течении года выпуском 6 билдов (версии x.1, x.2 и т.д.) только с исправлениями.
Для второго типа заказчиков предлагается переходить на обычные релизы по мере их выхода. Зачастую в очень сложных проектах новые программные возможности не всегда удовлетворяют заказчика с первого раза. Потому, чаще всего, после сдачи новых возможностей, заказчику нужно немного исправить поведение продукта. Поэтому для каждого обычного релиза выпускается один стабилизационный билд.
Заказчику нужно некоторое время для запуска новой версии продукта в промышленное использование, потому после выхода нового релиза команда разработчиков сразу приступает к выпуску стабилизационного билда к предыдущему релизу. Одновременно с этим разработчики бекпортируют все правки в LTS релиз и выпускают стабилизационный билд для LTS тоже. Т.е. разработчики не ждут отзыва заказчиков для которых был выпущен новый релиз, а исправляют предыдущий релиз на который к этому моменту собраны жалобы.

Данный поход позволяет:

1. дать стабильность в LTS релизах;
2. держать высокий темп выхода новых версий для заказчиков;
3. продолжать заниматься разработкой, а не ожидать фидбека/багрепортов;
4. стабилизировать новые версии по мере получения фидбека/багрепортов.
   
   

Цикл разработки

Заказчики хотят получать оплаченные новые возможности точно в срок.
На первый взгляд опыт разработки показывает, что это невозможно. Но это не так. Любые даже самые большие задачи могут быть разбиты на мелкие подзадачи, время на разработку которых возможно подсчитать. При относительно большом цикле (спринте), количество мелких задач, которые могут быть выполнены за определенный срок, стабильно. Не все задачи будут выполнены, но при правильном подсчете этот процент будет мал. В процессе фактической разработки может возникнуть определенное количество новых задач, они тоже должны быть заложены в план. Правильный подсчет времени и количества мелких задач, которые может выполнить отдел разработки в целом, зависит от грамотности лидеров групп (team lead).

Был предложен следующий цикл разработки:

Создание спецификаций

Невозможно гарантировать разработку новых возможностей вовремя, если конечному разработчику не понятны требования заказчика. Потому никакие запросы на новые возможности не будут приняты от заказчика (и не будут названы сроки) пока не будет создана исчерпывающая спецификация, которую примет и заказчик и лидеры групп в отделе разработки. Спецификация должна быть полностью понятна лидерам групп, которые разобьют ее на подзадачи и подсчитают сколько нужно времени на реализацию каждой из них, только после этого заказчику будут названы сроки.

Быстрое развертывание среды разработки

Используемые OpenSource решения – Jenkins, VirtualBox, Vagrant.

Каждому разработчику, что бы начать исправлять ошибку или писать код, нужно иметь личную систему с установленной копией продукта который он разрабатывает. В больших и сложных продуктах довольно долго подготавливать правильно установленный и настроенный продукт (например, базу данных Oracle), это может длиться от нескольких часов до нескольких суток. При высоком темпе выпуска новых версий эта проблема многократно усиливается. Чтобы ускорить процесс развертывания среды разработки был полностью автоматизирован процесс создания образов виртуальных машин для всех версий продукта, для всех платформ с помощью Jenkins CI. Эти образы используются в самом Jenkins для запуска тестов во всех поддерживаемых версиях продукта на всех возможных платформах. С помощью vagrant, гигабитной офисной сети и SSD разработчики могут разворачивать за считанные десятки секунд полностью готовую среду разработки из образа, который имеет актуальный код на нужной платформе.

Автоматизация тестирования

Используемые OpenSource решения – Jenkins.
Код покрыт следующими видами тестов:

• Unit test
• Functionality test
• Performance test
• Syntax test
• Style test
• Code analysis
• Compile test
• Memory leak test (valgrind)
  
  

Стабильный транк

Используемые OpenSource решения – Git, Gerrit, gerrit-tools, Jenkins CI.

Чтобы улучшить стабильность кода, был предложен следующий подход:

• разработчик делает фиксацию изменений (коммит) в локальном git репозитории и запускает команду “git review”, которая отправляет изменения в gerrit.
• Gerrit задерживает изменения, не давая их отправить в центральный репозиторий до тех пор пока изменения не будут проверены рецензентами и автоматическими тестами в Jenkins.
• Gerrit тригерит запуск тестов в Jenkins, результат которых выставляется в виде положительной или негативной оценки.
• рецензенты могут комментировать код и выставлять оценки от -2 до +2. Код, который не имеет оценки +2 или имеет оценку -2 – не может попасть в центральный репозиторий.
• когда рецензенты и Jenkins проставили положительные оценки, появляется кнопка “Submit” с помощью которой можно пропустить изменения в центральный репозиторий.
• раз в день запускаются тяжелые функциональные тесты, которые могут длиться всю ночь.
• на основе кода формируются образы виртуальных машин, которые с утра будут загружены разработчиками и QA.
  
  

Выводы

Предложенные организационные изменения были проведены в компании PortaOne, Inc. на команде разработчиков из 50 человек и позволили разработчикам больше заниматься любимым делом и выдавать на 30% больше кода. Отношения с клиентами улучшились благодаря выходу точно в срок новых версий продукта с заказанными функциональными возможностями. Стабильность кода увеличилась за счет введения процедуры review и автоматизации тестирования.