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

23.08.18

Разработка - Групповая разработка (Git, хранилище)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

Минусы:

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

Выводы

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

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

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

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. 

 

 

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9146    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1203    bayselonarrend    3    

37

Автоматизация процесса разработки с помощью сервиса GitFlic

Групповая разработка (Git, хранилище) Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1868    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

Групповая разработка (Git, хранилище) Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3785    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

Групповая разработка (Git, хранилище) Бесплатно (free)

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    7847    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2780    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

Групповая разработка (Git, хранилище) Бесплатно (free)

Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле. Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки. Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.

26.12.2023    1342    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3961    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mvk4d 24.08.18 08:34 Сейчас в теме
Хорошо, что сейчас уже можно работать с хранилищем расширения!
2. t.v.s. 111 24.08.18 09:16 Сейчас в теме
(1) Хорошо, но пока глючно
3. DrZombi 286 26.03.19 13:12 Сейчас в теме
(2) Глючно? К примеру? Если можно, то где почитать?
Оставьте свое сообщение