Технология производства RAIDIX

В 90% случаях стоимость данных, которые лежат на СХД превышает стоимость самой системы хранения данных в несколько раз. Поэтому при разработке такого рода продуктов нам приходится заботиться о надежности решения для хранения данных, об обеспечении стабильной работы, о сохранности данных. Что мы для этого делаем? Чтобы каждый раз получать технологически стабильный продукт, в RAIDIX существует обязательная для соблюдения технология производства. Про нее я и хочу сегодня рассказать.

Как мы пришли к текущей технологии? Все просто: 3 года назад мы серьезно озадачились вопросами повышения качества и стабильности продукта. Подошли к вопросу настолько серьезно, что даже родилась новая линейка продукта RAIDIX 4.x, в которой многое разработано с нуля. Мы полностью изменили подход к разработке. Не то чтобы его раньше не было — были и технологические инструкции, и обязательное тестирование, и обязательная проверка работоспособности написанного кода перед передачей в тестирование. Тем не менее, конечным результатом мы были недовольны, т.к. часто сроки здорово съезжали на этапе тестирования (до 80 процентов времени занимало тестирование продукта и багфикс).

Преобразования начали с анализа. С чем связаны задержки? Получили интересные результаты:

1. Сложность и высокая связанность кода на уровне управления приводит к тому, что модификация одного модуля может потянуть за собой проблемы в совсем неожиданных местах.
2. Длинный жизненный цикл некоторых багов (т.е. баг найден, вроде исправлен, но почему-то периодически передается от тестера к разработчику, хотя в идеальном случае нашли, пофиксили, проверили, закрыли; т.е. бага несколько раз возвращалась с этапа проверки обратно на исправление).
3. Перепроверка (регрессия) занимает много времени.

Что решили сделать:

1. Полностью переписать уровень управления для уменьшения связанности модулей и упрощения кода, что и было сделано (в результате чего и родилась версия Raidix 4.x).
2. Решили применить техники, повышающие качество продукта до передачи его в тестирование, такие как обязательные сode review перед чекинами в транк, CI, юнит тесты.
3. Стали активно развивать базу автоматизированных тестов, чтобы ускорить регрессионные проверки.

Что получили в итоге:

1. Код был переписан в течение года. Новый код обладал гораздо меньшей связанностью, не тащил за собой старые костыли и известные проблемы. Новая архитектура позволяла довольно просто расширять функциональность без опасности задеть существующую. Это сразу отразилось на точности планирования и на сроках тестирования.
2. Новые фичи, багфиксы теперь имеют гораздо меньше итераций перекидывания от тестеров к разработчикам, т.к. принятые технологические меры привели к значительному улучшению кода, попадающего в билды. Что также привело к большей эффективности работы группы тестирования.
3. После внедрения автотестов мы автоматизировали значительный объем тестовых кейсов (~10%), выполнение которых теперь занимает гораздо меньше времени и не требует длительного вмешательства тестировщиков. Покрытие, конечно, надо увеличивать, но эффективность от внедрения очевидна.

До новых встреч!