Версионность web-приложений

В последнее время я все больше и больше задумываюсь о проблемах тестирования того, что я произвожу. Все чаще и чаще я задаю себе вопрос “Почему?”. Почему продукт приходит в стадию live еще сырым? Почему заказчик находит в нем критические уязвимости и гневно репортит об этом? Ответы на эти вопросы для каждой ситуации и для каждой команды свои. Кому-то просто не хватает времени все хорошо оттестировать, а кто-то просто так относится к своим обязанностям.

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

К чему это я, спросите Вы? Я хочу затронуть тему тестирования продуктов со стороны разработчика и всей команды в целом.

Хочу немного затронуть тему версионности проектов, а в частности при web-разработке.

Давайте посмотрим как процесс тестирования происходит в большинстве случаев, которые я встречал на своем опыте:

  1. Разработчик заканчивает набор фич и репортит менеджеру о том, что он сделал (либо просто закрывает поставленные задачи в Bug\Task traking)
  2. Менеджер дает отмашку QA, что пора тестировать
  3. Тестировщик тестирует, периодически ругаясь, что все отваливается, версию прямо на копии разработчика и репортит баги
  4. Разработчик фиксит
  5. Тестировщик перепроверяет, подтверждая, что все пофикшено

Чем чревата данная схема? А тем, что:

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

Схема номер 2:

  1. Разработчик заканчивает набор фич и репортит об этом
  2. Разработчик поднимает отдельную версию для тестирования
  3. Тестировщик тестирует и заводит таски на разработчика
  4. Разработчик фиксит и меняет статус у бага на fixed
  5. Тестировщик начинает проверять и видит, что баги со статусом “fixed” все еще воспроизводятся и начинает гневно и массово снова переводить баги на разработичка
  6. Разработчик оправдывается (или злится), что все пофиксил, но ничего еще не заливал на версию QA т.к каждый баг заливать – ужас, а если менять статусы у багов только после их заливки, то можно забыть, проглядеть и не закрыть необходимые тикеты (особенно если их очень много)

Вторая схема приятнее первой, но тоже, как вы видите, имеет свои недостатки в плане коммуникации между разработчиком и тестировщиком. Да, эту проблему можно решить в личном порядке, но это сильно делу не поможет. Коммуникация – хорошо, но не всегда работает на все 100% т.к. “человеческий фактор”…

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

  1. Разработчик заканчивает задачи и меняет статусы у соответствующих тикетов
  2. Разработчик, либо человек ответственный за это, ставит номер версии к текущему состоянию проекта ( как это делать? об этом чуть позже)
  3. Тестировщик начинает тестировать версию приложения с конкретной версией (предположим это будет 0.1.0)
  4. Тестировщик находит дефекты и заводит тикеты на разработчика с указанием номера версии в который данный баг воспроизводится
  5. Разработчик фиксит дефекты и в комментарии к тикету пишет номер версии в которой данный баг будет пофикшен
  6. Данная процедура выполняется до того момента, как тестировщик не сможет найти багов, либо на усмотрение менеджера\тех лида\etc…
  7. Проект получает новую версию ( предположим это будет 0.1.1 )
  8. Тестировщик точно знает о наборе тех багов, которые пофикшены в этой версии

Данная схема позволяет уменьшить время на общение между разработчкиом и тестировщиком. Достаточно просто в чат проекта (если конечно такой есть) написать, что версию обновилась.

Теперь давайте поговорим о том, по какому принципу нумеруется проект и как, собственно, эту версию поставить, чтоб все, в любой момент времени, могли узнать какая текущая версия проекта.

0.1.0 – stable\full версии проекта, чаще всего такой версией является когда проект запускается в первый раз
0.1.0 – major версии, окончание итерации, показ функционала клиенту…
0.1.0 – minor версии, промежуточное состояние проекта в итерации
Так же в конец может быть добавлена еще одна цифра, которая указывает на hotfix в минорной версии. Предположим, отдав на тестирование версию 0.1.3 мы забыли что-либо добавить в нее, либо заметили явную опечатку, в таком случае мы исправляем и именуем версию 0.1.3.1

Важно!
Новый функционал попадает на qa, staging, live сервер исключительно через версионирование. Т.е даже если есть необходимость заливать изменения по ftp, то предварительно локально ставится новый tag, а затем изменения отправляются на сервер. Даже если изменения совсем минорные, не допускайте ситуации, когда на qa либо live будут залиты изменения без версии. Это условие существенно облегчает понимание того, что сейчас находится на сервере где у нас ограниченный доступ (ftp). Новый разработчик на проекте посмотрев на дерево изменений всегда поймет по какой commit изменения попали не сервер.

Как добавить версию либо узнать текущую?
Для версионирования проектов используются распределенная система контроля версий Git или Mercurial. В этих системах присутствует такое понятие как Tag.
Tag – именованный указатель на commit.
Поставить Tag к коммиту мы можем так:
git tag 0.1.1
or
hg tag 0.1.1
Tag и является текущей версией проекта, т.е все изменения, которые ниже коммита с этой меткой входят в эту версию. Любое изменение которые будет сделанно в дальнейшем должно иметь другую версию.

Для того, чтобы узнать текущую версию проекта было просто ее следует добавить в title страницы.

Для Yii я написал достаточно простой компонент, который умеет возвращать вам текущую версию проекта.
Что нужно:
1) Добавить файл компонента
2) Добавить в конфиг файл строчку в раздел компонентов

[php]
‘version’ => array(
‘class’ => ‘components.version.VersionComponent’,
‘prefix’ => ‘v’, // префикс перед версией
‘enable’ => true, // включить либо выключить компонент
‘vcs’ => ‘hg’ // тип системы контроля версий из которой будем брать версию
)
[/php]

3) Вставить в title

[php] <?php echo Yii::app()->getComponent(‘version’)->getCurrentVersion(); ?> [/php]

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

Leave a Reply

Your email address will not be published. Required fields are marked *