Привет! Меня зовут Стас Ганиев, программист 1С, автор ТГ-канала OneSCast, в этой статье я рассмотрю и сравню три самых популярных подхода к групповой разработке: хранилище конфигураций, конфигуратор + Git, EDT + Git.

Я хорошо помню время популярности платформы 7.7. В 2002 году в команде, в которой я работал, не было возможности хоть как-то объединить усилия программистов при одновременной работе над одной конфигурацией. Когда для повышения эффективности за одну конфигурацию брались два разработчика, они в первую очередь договаривались, над какими задачами каждый будет работать и какие объекты дорабатывать или добавлять. Чтобы объединить результаты их трудов в конечный продукт, выполнялось объединение двух версий конфигураций (и не дай Бог в этот момент взять не тот файл), а затем вручную каждая доработка переносилась в конечную конфигурацию. Разработчики тогда работали с отдельными, никак друг с другом не связанными конфигурациями. И, если к процессу подключался третий специалист, или за время доработки на продуктиве успевали что-то поправить или влить «быстренько» новую фичу, то процесс сборки превращался в сущий ад.

Как ни странно, но именно тогда родилась первая технология групповой разработки. Позже она получила название Локальной системы контроля версий. Согласно ее концепции отдельные файлы конфигурации — версии — выкладывались в некую общую папку или структуру каталогов, определенным образом назывались и периодически бэкапились. Все это было неудобно, сложно контролировалось, а версионирование кода было весьма условным.

С выходом платформы 8.0 в ней появилось хранилище конфигурации, ставшее типичным представителем Централизованных систем контроля версий. Теперь разрабатывать конфигурации в команде стало намного проще. Каждый разработчик мог видеть, какой объект кем захвачен, а все доработки всех участников собирались в единую историю в хранилище. Технологии групповой разработки стали набирать обороты: в версии 8.2 по просьбе сообщества добавили функцию выгрузки конфигурации в файлы, дав возможность задействовать Распределенные СКВ, такие как Git. А в EDT эта технология уже доступна из коробки.

Преимущества технологий групповой разработки сложно переоценить:

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

На сегодняшний день использование технологий командной работы — это неотъемлемая часть любого проекта. Даже если программист работает над конфигурацией в одиночку, полезно хранить и контролировать историю всех выполненных изменений.

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

При выборе конкретной технологии важно понимать цели и задачи, которые необходимо решать. Целями групповой разработки могут быть:

• повышение качества продукта;
• ускорение процесса разработки;
• гибкость и масштабируемость;
• обмен знаниями и опытом.

Возможные задачи групповой разработки:

• организация эффективного взаимодействия;
• управление конфигурациями и версиями;
• обеспечение качества;
• планирование и мониторинг.

В этой статье рассмотрю возможности, плюсы и минусы трех основных технологических подходов:

1. Хранилище конфигурации.
2. Конфигуратор + Git.
3. EDT + Git.

Также посмотрим в разрезе задач: когда и какую технологию лучше использовать, а где каждая из них будет бессильна.

Источник: Хабр