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

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. 

 

 

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

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

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


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

 


См. также

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

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    10036    81    4    

115

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

Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.

08.04.2024    1134    bayselonarrend    2    

32

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

Доработки 1С:ERP на крупных проектах можно организовать, не внося изменения в саму типовую конфигурацию, а используя только расширения и отдельные «микроконфигурации». Расскажем о том, как это сделать без EDT, используя процесс разработки GitHub Flow.

02.04.2024    6284    Begemoth80    24    

49

Групповая разработка (Git, хранилище) OneScript Системный администратор Программист Бесплатно (free)

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

25.03.2024    1899    bayselonarrend    3    

41

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

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

05.03.2024    2677    user1989937    6    

17

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

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

05.02.2024    4498    bayselonarrend    15    

66

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

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

22.01.2024    8554    bayselonarrend    50    

87

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

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

17.01.2024    3693    kamisov    19    

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