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