Одновременное использование хранилища и расширений

В этой статье речь пойдет о групповой разработке типовых и нетиповых конфигураций.

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

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

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

Здесь как раз продемонстрирован захват объектов в хранилище конфигурации.

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

Это инструмент существует очень давно, ему уже около десяти лет. Его все используют – он очень важен при работе на проекте.

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

На слайде можно увидеть, как выглядит диалоговое окно «Расширения конфигурации». Как видите, в конфигурацию можно добавлять несколько расширений.

Когда мы работаем с конфигурацией, мы можем модифицировать как саму конфигурацию, так и ее расширения.

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

Я постарался коротко представить сравнительный анализ хранилища и расширений.

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

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

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

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

 

Кейс 1: команда из трех человек. Расширения

 

Рассмотрим первый кейс, когда команда состоит из трех человек. Как происходит работа?

Есть какая-то база данных и есть три разработчика, которые эту базу данных дорабатывают, внося изменения в расширения.

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

Эту проблему можно решать по-разному:

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

Расскажу о преимуществах и недостатках подхода работы в расширении.

Преимущества:

• У нас есть легкость обновления типовых конфигураций;
• И есть относительная простота работы – зависит от ситуации.

Минусы:

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

 

Кейс 2: увеличение команды до 5-10 человек. Хранилище + Расширения

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

Второй кейс о том, как одновременно работать с хранилищем и с расширениями.

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

Что это значит?

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

Итак, мы создаем хранилище, заводим в нем пользователей и следующим шагом мы подключаем все наши базы к этому хранилищу.

Работая в хранилище, мы получаем все его преимущества – выкладывая там новые изменения, мы автоматически получаем все это в базе (в том числе, в базе данных заказчика). Остается одно «но»: наши разработчики из первого кейса часть разработок сделали в расширении. А расширения на текущий момент живут отдельно от хранилища и пока что работу с хранилищем не поддерживают, хотя, это, наверное, есть в планах. Поэтому самое сложное – это работа с расширениями параллельно работе с хранилищем.

Что мы должны сделать? Устанавливается следующий регламент – вся новая функциональность реализуется в хранилище, а те доработки, которые касаются реализованной ранее функциональности, по-прежнему редактируются в тех расширениях, где они были ранее реализованы. При этом каждый разработчик объединяет свои изменения с расширением в тестовой базе самостоятельно (или какой-то администратор может выполнять изменения расширений от разработчиков в контуре тестовой базы). Это ручное объединение расширений в единой базе производится с помощью того же самого окна сравнения и объединения конфигураций, только выполняется оно в расширении. Да, сохраняются риски, сохраняются какие-то организационные моменты, это по-прежнему долго и сложно, но у нас уже есть хранилище, какая-то история, связанная с хранилищем, какая-то тестовая база, в которой мы фиксируем состояние работающего продукта. И из этой тестовой базы в базу заказчика уже переносится некоторое зафиксированное состояние продукта (файл CF из хранилища и файлы CFE, объединенные в нашей тестовой базе). Это позволяет уменьшить риски того, что в базу заказчика попадет что-то неправильное.

И последним шагом организуется автоапгрейд контуров – мы стараемся максимальное количество действий выполнять скриптами. По заданию раз в день или несколько раз в день.

 

Это пример bat-файла, который у нас использовался для автоапдейта. Что он делает:

• Обновляет базу данных из хранилища;
• Сохраняет эту базу данных;
• Сохраняет файлы;
• И переносит эти файлы в базу заказчика.

Если внимательно посмотреть на этот скрипт, то можно увидеть, что речь идет о настройке конфигурации «1С:Зарплата и управление персоналом». Исходя из нашей практики, эта конфигурация должна максимально оставаться типовой. Она очень сложная и часто меняется, поэтому большой соблазн перевести ее на работу с расширениями. Но опять же, в силу того, что она большая и сложная, количество разработчиков в нашем случае потребовалось довести до шести-семи человек, и работа без хранилища стала невозможной. Проект – это такая вещь, где, чтобы что-то получить, надо чем-то пожертвовать. А чем – это уже надо решать по месту. В данном случае мы все-таки решили полностью отказаться от расширений.

 

Переход от работы с расширениями к работе в хранилище

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

На этом слайде можно увидеть, как выглядит наша «Дорожная карта» по отказу от расширений:

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

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

Нужно потратить какое-то время на освоение этого механизма, но это себя оправдывает. Конечно, при обновлении нам придется потратить больше времени, чем при работе с расширением, но повторюсь еще раз: на сложном проекте мы решили пойти по этому пути.

Не могу не сказать о том, что у нас есть альтернатива. Этот способ описан в публикации Евгения Сосны «Использование Git для доработки типовых конфигураций». Коллеги это используют.

Почему мы не стали на это переходить?

• Во-первых, это сложно. У нас по разным причинам не было возможности обучить разработчиков 1С работе с Git.
• Во-вторых, для этой работы требуется более высокая квалификация разработчика, он должен быть готов осваивать новый механизм. И, к тому же, если разработчик много лет работал с «1С:ЗУП» и не обладает другими технологиями, но при этом он прекрасный разработчик «1С:ЗУП», мы не будем настаивать на том, чтобы он переучивался.
• И, в-третьих, необходима соответствующая архитектура. Например, если разработка ведется в контурах заказчика, и он не готов давать доступ на какие-то внешние ресурсы с Git, либо не готов разворачивать это дополнительно на каких-то своих серверах, то нам этот вариант тоже не подходит.

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

 

Выводы

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

Пока шла подготовка к конференции Infostart Event, появилась новая версия среды разработки EDT, которая хорошо поддерживает работу с системами Git. Вполне возможно, что в ближайшее время фирма «1С» внесет функционал совместной работы расширения и хранилища в конфигуратор. Думаю, есть шансы, что мы это увидим.

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

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.