От задачи до production – Bitworks Software – Инструменты разработки

View Github Repository Open presentation in a new window

foxel

See all presentation from foxel

От задачи до production – Bitworks Software – Инструменты разработки

0 0

gorod.it.2014

On Github foxel / gorod.it.2014

От задачи до production

или "Как мы ведем разработку"

Andrey F. Kupreychik @ Bitworks

Bitworks Software

Основана в 2005 году в Томске

В штате более 50 сотрудников

Направления:

  • Высокопроизводительные системы высокой доступности
  • Контентные проекты
  • Data mining
  • ЦОД и облачные услуги (NetPoint)
    • Dedicated/VPS/Hosting
    • Хранение и обработка данных
    • Системное администрирование

Инструменты разработки

Наш минимальный набор:

  • Continuous integration система (Jenkins)
  • VCS (git + gitolite)
  • Project management система (redmine)
Для управления процессом мы используем небольшой набор инструментов, я бы даже сказал минимальный. Для управления кодом мы используем гит. Он прост в освоении и практически является стандартом для командной разработки. Для управления задачами - redmine. Continuous integration система, используемая у нас - Jenkins. Также мы можем видеть выделенный для разработки web-сервер, здесь крутятся экземпляры проекта, различные его версии.

***

От задачи до production

Любая идея проходит несколько этапов прежде чем стать частью продукта. Не будем подробно останавливаться на процессе генерации идеи в мозгу заказчика, будем рассматривать этот процесс как атомарный, за которым следует формализация задачи (бага/хотфикса). На этом этапе мы получаем тикет (задачу) в redmine. Кроме самого заказчика “генератором” тикетов может быть отдел QA, постоянно бдящий работоспособность продукта, или техническая поддержка заказчика.

Redmine workflow

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

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

Задачи и GIT

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

Тысяча и одно окружение

Наиболее интересная, на мой взгляд, фича нашего подхода - маленькие тестовые окружения для каждой ветки. Они создаются автоматически, в тот момент когда gitolite получает обновление в репозиторий. Hook дергает jenkins-задачу развертывания ветки, которая вытягивает код и разворачивает новое окружение на тестовом сервере. Окружение может включать даже отдельную базу данных, однако в текущий момент мы на таком экономим и шарим базу между ветками. Каждый контейнер достаточно автономен.

Поддержка со стороны проекта

Конфиг по домену (например ticket1111.test.project.com):

  • namespace для БД
  • Имена очередей
  • Префиксы имен загружаемых файлов
  • и так далее...
Со стороны проекта поддежка тестовых окружений заключается в поддежку подоменных конфигов. Эти конфиги генерятся сборочным скриптом и содержат настроки ресурсов для разделения, например namespace для БД, имена очередей AMQP и т.п.

Развертывание и свертывание

  • База данных
  • Файлы
  • Код
  • Сервисы окружения
Как только gitolite получает изменения в ветку, он посредством API запускает Jenkins задачу развертывания тестового окружения. Процесс включает копирование кода из репозитория, развертывание базы, подготовку папок, поднятие нужных сопуствующих сервисов. Как только gitolite обнаружит удаление ветки, запускается процесс свертывания окружения, при котором производятся обратные дейтсвия: опускаются сервисы, стирается код, удаляются копии базы данных.

А для apache это просто:

## ticket1214.test.project.com
ServerName test.project.com
ServerAlias *.test.project.com
VirtualDocumentRoot /var/www/vhosts/%-4.0/public_html

Code-review и unit-тестирование

Для того, чтобы поддерживать код в хорошем состоянии, мы практикуем code-review и unit-тесты. Что дает код ревью? На самом деле это очень важный момент. Эта методика позволяет отловить неочевидные баги и откровенные костыли. Код ревью в команде занимаются по большей части люди, знающие архитектуру проекта максимально хорошо. Что же касается unit-тестирования, этот процесс у нас автоматизирован - тесты запускаются перед развертыванием окружения ветки и их падение приводит к отказу в развертываниии. Тестами покрувается как код серверной части, так и клиентский javaScript.

Ручные тесты и автотестирование

  • Быстрое ручное тестирование нового кода
  • Функциональное автоматизированное тестирование
  • Три этапа тестирования:
    • отдельно
    • в составе релиза
    • на production
Кроме Unit-тестирования у нас есть QA отдел, отвечающий за функциональное тестирование системы. Все задачи так или иначе проходят через QA, понимая это разработчик всегда должен предоставить список подсистем, задетых изменениями. Также QA занимается разработкой автоматизированных функциональных тестов. Для тестирования web-интерфейса мы используем selenium. Для тестирования API интерфейсов используются автоматизированные тесты с обширным набором юзкейсов. Каждый релиз обязательно подвергается полному набору функциональных тестов для выявления возможных регрессий.

Сборка релизов

Сборкой релизов занимается отдельный человек. Не подумайте что мы изолируем знания внутри кучки избранных, распространение знаний поощряется. Однако с точки зрения эффективности, постоянный ответственный человек лучше. Сборка релиза включает в себя сливание веток всех тикетов релиза, решение конфликтов, обновление базы данных и git push. Дальше ветка релиза разворачивается так же как и остальные ветки в своем отдельном окружении. Релизы проходят второй этап тестрования, для исклчения конфликтов между фичами. Когда релиз готов команда технических писателей составляет release notes для итерации, публикуемый для клиентов.

Заливка в прод

git checkout production
git pull
git merge --no-ff origin/ticket3333 # release ticket
git push origin production
Данный процесс даже проще чем сборка релиза. Все что нужно сделать - слить ветку релиза в production и услужливый Jenkins развернет все изменения на живые сервера.

Облегчаем свою жизнь

  • Любая задача подчиняется процессу, абсолютно любая!
  • Изменения в БД только через миграции.
  • Соблюдайте принципы, бейтесь за архитектуру.
  • Код не понятен - код-ревью не пройден.
  • Писать тесты - полезный навык

Немного фактов

  • Счетчик тикетов в редмайне скоро отсчитает 30000 тикетов
  • У нас бывает до 50 разрабатываемых/тестируемых фич одновременно
  • За последние 3 года мы откатили с production только один релиз
  • Ведущие разработчики знают до 90% классов в проекте как свои 5 пальцев

Спасибо за внимание