Технологии групповой разработки в современной 1С‑индустрии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранилище конфигурации — типичный представитель Централизованных систем контроля версий. Архитектура таких систем состоит из единого пространства хранения централизованной консолидированной конфигурации, в которую сливаются доработки всех участников команды по мере их готовности.

Рис. 1. Схема подключений при использовании хранилища

Рис 2. Исключительная блокировка объекта в хранилище при захвате одним из разработчиков

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

Централизованное хранилище всех версий объектов конфигурации в единой базе. База располагается на выделенном, общедоступном ресурсе и существует там в единственном экземпляре. Это минус для безопасности данных хранилища, поскольку необходимо позаботиться о бэкапировании общих данных на случай форс-мажорных ситуаций.

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

Простота использования. Однажды получив доступ к хранилищу и изучив пару команд и пару кнопок, разработчик может без труда примкнуть к процессу разработки конфигурации. Так же легко осуществляется управление доступом и контроль захвата объектов со стороны администратора.

Централизованное управление. Архитектор с правами администратора может держать постоянно захваченными наиболее критичные объекты метаданных, доработка которых нежелательна. Это могут быть сложные объекты, такие как роли или регламентированные отчеты от вендора.

Отсутствие ветвления. При классической схеме работы с хранилищем мы имеем дело со строго линейным внесением изменений во времени. Это может создать особые трудности на больших и сложных проектах при большом количестве программистов. Например, когда требуется поменять приоритет двух задач, в каждой из которых задействованы одни и те же объекты, а уже выполненные доработки терять не хочется.

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

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

• Подходит для маленьких и средних команд с линейным процессом разработки.
• Предпочтительно для конфигураций на обычных формах.

1. Следите, чтобы все разработчики в команде работали на платформе строго одной версии, с точностью до последнего номера сборки. И эта же версия платформы должна быть задействована для обеспечения работы и обслуживания базы хранилища.
2. Установите в команде правило короткого захвата корня конфигурации. По факту, это требуется только в одном случае — для добавления нового объекта. Пусть разработчик захватит корень, добавит объект, тут же отпустит корень и продолжит дорабатывать объект, оставив захваченным только его. При этом следите за дополнительными требованиями платформы для обновления базы с новым объектом. Например, для регистра накопления обязательно должен быть указан хотя бы один регистратор.
3. Предусмотрите дополнительный, резервный, аккаунт в хранилище с административными правами. Он может потребоваться для аварийного снятия захвата объекта разработчика, уехавшего в отпуск, или для срочного доступа в отсутствии единственного администратора.

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

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

Рис 3. Схема подключений при использовании Git

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

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

Управление доступом к репозиторию доступно на уровне центрального сервера. Например, Github позволяет настроить права как на сам репозиторий в целом, так и на отдельные ветки истории в нем. Однако локальная копия репозитория у разработчика доступна ему без ограничений. И это накладывает дополнительную ответственность на участника команды. Так, если программист случайно выполнил ряд коммитов в ветку master локального репозитория, то отправить эти изменения на сервер может не удастся, если в удаленном репозитории коммиты в эту ветку запрещены. Такие изменения нужно будет перенести в соответствующую ветку задачи.

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

Удобная работа с изменениями и историей версий. Еще одно преимущество Git — это его высокая скорость работы. Переключаться на произвольную версию конфигурации можно за считанные секунды. Инструментарий просмотра истории изменений и их анализа довольно широк и гибок.

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

Необходимость осваивать Git как отдельный инструмент.

Начальная настройка системы. Первоначальная настройка системы необходима, чтобы Git корректно работал с файлами 1С. Также это типичные для Git настройки авторизации, ключей SSH, первичное развертывание репозиториев и настройка ветвления.

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

1. Как и при работе с хранилищем, всем участникам команды следует пользоваться одной версией платформы 1С, поскольку содержание и формат выгружаемых файлов от версии к версии может отличаться.
2. Заранее договоритесь с командой:
   
   - Какой будет структура вашего репозитория, в каких папках какие файлы будут храниться. А возможно, отдельные расширения и внешние обработки, которые применимы на многих проектах, будет разумно версионировать в отдельном репозитории;
   - Именование веток. Как при написании кода важно придерживаться единых стандартов, так и при использовании Git необходимо соблюдать единые правила в именах веток, например, чтобы обязательно присутствовал номер задачи. Некоторые таск-трекеры позволяют автоматизировать эти процессы;
   - Система ветвления. Имя основной ветки разработки, наличие и порядок работы с веткой тестирования, порядок создания и выполнения слияния веток отдельных задач и багфиксов — обо всем этом лучше договориться на берегу, исправлять потом будет гораздо сложнее.
   
   
3. Рекомендуемые консоли командной строки: Cmder и Conemu.
4. Для облегчения и наглядности при работе с Git лучше пользоваться графической IDE. Можно выбрать любую на ваше усмотрение. Здесь я приведу наиболее популярные: Git extensions, SourceTree, Github desktop, Gitkraken, VSCode.

Подход с использованием 1C:EDT (1С:Enterprise Development Tools) во многом напоминает работу по предыдущему стеку, и к нему применимы все те же рекомендации. За тем исключением, что EDT изначально включает в себя как арсенал инструментов по разработке конфигураций 1С, так и встроенную из коробки систему Git и графический интерфейс по работе с ним. Есть и некоторые отличия, о них и поговорим.

Распределенная, поскольку тоже Git.

Использование среды разработки Eclipse (EDT) с интеграцией Git. Платформа EDT позволяет удобно настроить среду разработки под любой проект. Для этого в интерфейсе предусмотрены отдельные Перспективы для работы с конфигурациями и системой контроля Git.

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

Расширенные возможности IDE Eclipse. Инструментарий IDE предоставляет удобные мастера и конструкторы для различных участков и блоков конфигураций, расширенную контекстную подсказку, удобные инструменты поиска и навигации, а все необходимые инструменты можно разместить в отдельных окнах и закладках, настраивая интерфейс полностью под себя.

Рабочие пространства. Концепция EDT включает в себя понятие «Рабочего пространства», в рамках которого можно вести одновременную разработку нескольких конфигураций в одном месте. Также можно распределять конфигурации по Git-репозиториям в самых разных сочетаниях, а к одному проекту конфигурации можно подключить несколько информационных баз. Это бывает удобно, если базы отличаются наполнением данных, ролью в проекте или настроены под специфику учета разных клиентов.

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

Производительность. Да, ушли те времена, когда контекстная подсказка появлялась через минуту после набора точки. Но все же скорость и производительность среды еще далека от идеала. А для более-менее комфортной работы требуется значительно повысить показатели «железа» рабочей станции.

Подходит для команд, применяющих расширенные возможности разработки и интеграции.

1. Установите последнюю версию EDT. От версии к версии значительно улучшается функционал отдельных инструментов и подсистем. Также каждый релиз дает новые показатели улучшения производительности. Не намного, но все же.
2. Позаботьтесь о производительном «железе». Особое внимание стоит обратить на скорость жесткого диска (обязательно SSD с максимальной доступной скоростью), а также объем и скорость оперативной памяти (от 16 Гб DDR5).
3. Настройте среду под себя. Вы можете изменить в интерфейсе и перечне опций достаточно много, вплоть до переопределения горячих клавиш, если хотите сохранить подход, к которому привыкли в конфигураторе. Удобный интерфейс значительно повысит эффективность вашей работы.

В таблице ниже приведена сравнительная характеристика по ключевым показателям процесса разработки конфигураций 1С в команде. Это поможет вам выбрать наиболее подходящий инструмент для ваших задач.

У каждого подхода организации работы в группе есть свои плюсы и минусы. Ключевые критерии выбора — это сложность и объем проекта и предпочтительные способы коммуникации и обмена кодом.

Чтобы освоить технологический стек при командной работе с Git, приглашаю почитать мою статью, в которой, помимо основного материала, вы найдете множество полезных ссылок для самостоятельного освоения Git.