Работы
по полномасштабному переходу к разработке по методу GitFlow
были начаты в прошлом году, чему предшествовал всесторонний анализ недостатков и
ограничений базовых продуктов для контроля версий и статической проверки
качества кода. Теперь, в рамках проектов ДКИС ALP,
где обеспечивается непрерывность процессов разработки и тестирования,
реализовано хранение версий кода по Git-веткам, что
позволяет разработчикам размещать те или иные части кода в т. н. «дерево
конфигурации», а затем собирать из них единый итоговый релиз. Ранее
используемое базовое хранилище 1C не позволяло в
полной мере реализовать такую модель разработки.
Новый
процесс дает гораздо большие возможности для автоматизации, а необходимые
элементы «ручного управления», которые еще сохраняются из-за объективной
сложности некоторых корпоративных проектов, выполняются быстрее и исключают
возможность появления значительных ошибок разработки.
Отметим, что переход на GitFlow потребовал решения
не только технических задач, но и преодоления определенного консерватизма
сотрудников, привыкших работать с уже знакомыми инструментами. В частности, поскольку
разработчикам было сложно сразу отказаться от использования прежнего хранилища
в пользу Git, на промежуточной стадии было развернуто интерфейсное
решение, эмулирующее привычную для разработчиков среду, тогда как сами файлы уже
размещались в Git, причем с соответствующей поддержкой версионности.
Затем был осуществлен переход на прямое размещение кода в Git (этот процесс занял примерно полгода). В итоге, в
настоящее время многие разработчики ДКИС ALP
перешли
на прямое использование веток Git в полном объеме.
Одновременно, компания внесла изменения в состав ролей и функций участников
проектных команд, предполагающие выделение ответственного специалиста – Merge-мастера. В ДКИС ALP
такой
сотрудник (как правило, это один из архитекторов проекта) подготавливает релиз
выпускаемого программного продукта путём объединения различных версий и «веток»
кода в единую согласующуюся конфигурацию под требования заказчика.
Как подчеркивают инженеры ALP, такой подход
себя полностью оправдал. Так, если ранее на выпуск новой рабочей версии
приходилось в среднем три дня с учетом всех подготовительных работ, то в
настоящее время этот срок сократился до 10 рабочих часов, а к концу текущего
года доля ручного труда на «сборку» релиза должна составлять не более 5%. Такой
подход тем более оправдан, что в последние годы сложность ERP-решений неуклонно возрастает, а кастомизация
становится все глубже, что несомненно приведет к массовому переходу вендоров на
модель, уже апробированную ALP.
В дальнейшем, в рамках развитие данного проекта, компания планирует расширить
использование специализированных адаптированных библиотек для анализа кода и
выявления в нем паттернов, закономерностей и аномалий.