Ускорение процесса разработки и тестирования нового функционала

1.

Цель - ускорить процесс
разработки и тестирования
нового функционала.

2.

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

3.

Как проявляется проблема:
На стенде одновременно развернуто много веток(задач), готовых
к тесту.
1. Код одной ветки(задачи) может порождать ошибки при
тестировании другой ветки (задачи).
Получаем "наведенные" проблемы. Нет «чистой» среды для тестов.
2. Необходимость постоянно актуализировать состояние развернутых
на stage веток(задач).
Соответственно потеря времени разработки и тестирования, фейковые
статусы.
На stage-стенде происходит пофикс найденных по задаче багов.

4.

Как проявляется проблема:
На stage-стенде происходит отладка, колдунства и прочая магия.
Пока происходят эти эксперименты, стенд может быть
недоступен, сыпать ошибками, могут быть удалены тестовые
пользователи, тестовые заказы.
При этом происходит потеря времени тестировщиков.
stage полностью неработоспособен, "лежит" (за время, моей
работы в проекте было 3 раза).
Соответственно процесс тестирования остановлен.
Часть случаев была связана с тем, что CRM производил DDOSатаку на стенд.

5.

Предлагаемое решение:
1. Регламент работы с ветками.
1.1. Stage = PROD + dev_branch (ветка, которая сейчас активно тестируется)
1.2. Увеличение кол-ва stage стендов (в том числе как задел на будущее при
условии внедрения автотестов).
2. Выделить для нужд разработки отдельный dev-стенд.
(разработка, авторское тестирование, колдунства и прочая магия).
Если есть возможность, проводить часть отладки на локальной машине.
3. Алгоритм(скрипт), который отслеживает нагрузку и при DDOS
разъединяет связь между стендом и CRM.

6.

Регламент работы с ветками(черновик):
1. DEV_branch создается(почкуется) от PROD;
2. По завершению разработки авторское тестирование и отладка производится на
dev-стенде;
3. По завершению предыдущего пункта ветка попадает на stage, при условии, что на
нем не тестируется другая ветка.
В обратном случае ветка ожидает попадания на stage в соответствии с приоритетами
тестирования и разработки.
4. При успешном завершении тестирования, ветка сразу попадает на PROD.
Тестирование при этом не проверяет ее заново на проде, а проходит smoke-тесты;
5. Если тестирование задачи(ветки) переходит в статус Test Failed, то в случае, если
требуются минимальные правки, доработки по задаче проводятся также на stage до
успешного завершения;
6. Если тестирование задачи(ветки) переходит в статус test failed, то в случае, если
требуются значительные доработки или пофикс багов затянулся, то stage откатывается
до состояния PROD, задача дорабатывается на dev-стенде