1с как подключить расширение к хранилищу
С развитием платформы 1с всё чаще для изменения типовых конфигураций используют расширения.
Я постарался добавить в обновлятор все необходимые возможности для их администрирования (при необходимости сразу в группе баз), в том числе обновление из хранилища, а также операции с расширениями по расписанию.
Меню управления расширениями для базы можно найти сразу в нескольких местах:
Вот как выглядит сам диалог для администрирования расширений:
Посмотрим его в действии.
Я покажу всё на примере одной базы, но вы знайте - можно проделывать то же самое сразу для нужного количества баз (выделив их через Ctrl или отметив галками).
Перед нами типовая бухгалтерия 3.0 без установленных расширений:
Добавляем новое расширение
В диалоге администрирования расширений переходим на закладку "Добавить" и указываем файл с расширением, уточнив его настройки (безопасный режим, защита от опасных действий и так далее):
Выводим уже добавленные расширения
Переходим на закладку "Вывести", чтобы получить список расширений (вместе с их свойствами), которые уже добавлены в базу:
Проверяем работоспособность (применимость) добавленных расширений
Это можно сделать сразу для всех расширений запустив операцию на закладке "Проверить":
И если расширение содержит ошибки - мы увидим их в отчёте обновлятора.
Обновляем уже существующее расширение
Предположим, вышла новая версия расширения и его нужно обновить в базе (записать поверх существующего).
В этом нам поможет закладка "Обновить".
Из файла
Я указал файл с новой версией расширения и указал имя уже существующего расширения в конфигураторе ("ПисьмоВПоддержку").
Это имя необходимо, чтобы обновлятор смог найти уже существующее расширение в базе и загрузить в него новую версию из файла.
Часто оно совпадает с именем файла из которого мы загружаем расширение. Но так бывает не всегда.
Чтобы узнать имя расширения наверняка - зайдём в конфигуратор после его установки:
Вот его имя: "ПисьмоВПоддержку".
Причём если мы не выбираем конкретные значения опций (например, оставляем закрашенными синим цветом "Безопасный режим", "Защита от опасных действий" и так далее), то они не меняются при обновлении расширения (остаются как были до обновления).
Из хранилища
При этом есть нюансы в зависимости от того подключено ли расширение в обновляемой рабочей (продуктовой) базе к хранилищу или нет.
Расширение НЕ подключено к хранилищу
Это самый желательный вариант, который позволит вам не беспокоиться о конфликте пользователей хранилища между собой.
А также даст вам возможность обновляться из хранилища не только на последнюю версию конфигурации, но и на любую необходимую (заполнив поле "Версия", об этом ниже).
Расширение подключено к хранилищу
Тогда оно должно быть подключено под тем же пользователем, которого вы указываете в обновляторе для доступа к хранилищу.
Причём в этом случае пользователь должен быть уникальным, то есть не использоваться для подключения этого же расширения в других базах.
Внимание! Чтобы обойти это ограничение вы можете параметризовать имя пользователя хранилища. Для этого укажите значение "%base_name%" (вместо "updater" у нас в примере). В этом случае при выполнении скрипта в качестве имени пользователя хранилища будет подставляться имя базы в обновляторе (наша задача предварительно создать пользователей с такими именами в хранилище).
Стоит также учитывать, что при этом варианте обновление всегда будет происходить на последнюю версию конфигурации в хранилище, даже если вы заполните поле "Версия" (о нём рассказывается ниже).
Именно поэтому я рекомендую держать расширение подключенным к хранилищу только в базах для разработки, а рабочие (продуктовые) базы к хранилищу не подключать.
Это поле отвечает за номер версии конфигурации расширения из хранилища, которую мы получаем.
Если оставить его пустым, то всегда будем получать актуальную (последнюю) версию конфигурации расширения из хранилища.
Не нужно путать эту версию с версией самого расширения. Речь идёт вот об этой колонке:
Внимание. Заполнять поле "версия" имеет смысл только в том случае, если обновляемое расширение не подключено к хранилищу. Если оно подключено к хранилищу, то будем всегда получать актуальную версию несмотря на настройки.
Выгружаем все расширения во внешнюю папку
Обновлятор может легко выгружать все (или конкретное) имеющиеся в базе расширения во внешнюю папку в виде отдельных файлов:
В нашем случае результат будет таким:
В xml-файле сохраняются все настройки расширения в базе (безопасный режим, защита от опасных действий и так далее).
Загружаем все расширения из внешней папки
Все выгруженные расширения (вместе с их настройками) можно легко загрузить назад в ту же или в другую базу:
Удаляем существующее расширение
Удалим расширение с именем "ПисьмоВПоддержку":
Выполняем эти же операции по расписанию
Мы также можем настроить запуск любой из перечисленных выше операций по расписанию для нужных нам баз.
Предположим, что нам требуется обновлять расширение с именем "ПисьмоВПоддержку" из хранилища в 3 базах каждую ночь.
Для этого переходим на закладку "Скрипты" в главном окне обновлятора:
Из шаблонов открываем диалог "Управление расширениями" и настраиваем его для обновления нужного расширения из хранилища:
Нажимаем на кнопку "Обновить. " и в редактор вставляется текст скрипта с нужными параметрами:
Внимание! Обычно для каждой базы в хранилище создают отдельного пользователя. Сейчас в скрипте мы указали одного и того же пользователя с именем "updater", но ничего не мешает нам параметризовать это имя и выбрать, например, из параметров скрипта значение "%base_name%". В этом случае при выполнении скрипта в качестве имени пользователя хранилища будет подставляться имя базы в обновляторе (наша задача предварительно создать пользователей с такими именами в хранилище).
Сохраняем скрипт (кнопка "Сохранить" на нижней панеле):
Далее в настройки программы, кнопка "Расписание":
Здесь создаём новую задачу с типом операции "Запуск скрипта" и выбираем файл с нашим скриптом ("x:\work\update_extension.cmd"):
Настраиваем и сохраняем остальные параметры задачи:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Большинство разработчиков 1С уклоняются от использования расширений конфигурации в проектах из-за того, что расширения не поддерживают групповую разработку. Поддерживать версионность файлов *.cfe самостоятельно в папках или с использованием системы управления версиями Git готовы не все.
Напоминаем, что в новых версиях платформы «1С:Предприятия» такая возможность предусмотрена: разработчики могут создать хранилище для расширений, аналогичное знакомому хранилищу конфигураций.
Больше не нужно придумывать код для динамического вывода новых элементов на формы. Достаточно сделать расширение «Интерфейсы.cfe», и все разработчики проекта выводят новые элементы в него, экономя время на разработке технических заданий. Подробная инструкция по развертыванию хранилища конфигурации есть в статье «Хранилище конфигурации: создание и использование».
Продемонстрируем, как задействовать возможность для создания хранилища расширений конфигурации.
Среда для тестирования нового функционала развернута на платформе «1С:Предприятие 8.3» (8.3.12.1714) с конфигурацией «1С:ERP Управление предприятием 2» (2.4.6.154) . Одно из обязательных условий – хранилище конфигурации у вас уже поднято.
Заходим в конфигуратор, подключаемся к основному хранилищу.
Переходим меню «Конфигурация» – «Расширения конфигурации» – выбираем расширение.
В верхней панели управления формы расширений выбираем подменю «Конфигурация» – «Хранилище конфигурации» – «Создать хранилище».
Выбираем каталог, отличный от основного хранилища конфигурации. C:\1C_repository\metiz_erp – путь хранилища конфигурации. C:\1C_repository\metiz_erp_cfe – путь хранилища расширения.
Указываем пользователя хранилища (пользователи в хранилище расширений свои, но можно назвать их так же, как пользователей основного хранилища).
Хранилище создано и подключено, далее работаем по стандартному методу хранилища конфигураций.
Для другого разработчика также открываем учетную запись (в «Администрировании хранилища расширений»). Он в своей базе создает пустое расширение и подключает его к хранилищу, при этом актуальная конфигурация расширения затянется автоматически.
Блин, а если расширений несколько, то это нужно несколько отдельных хранилищ. Ждем, когда появится хранилище проекта, где не будет этого головняка.
(1) да, нужно хранилище под каждое расширение. К количеству расширений в конфигурации нужно подходить рационально. Это всё таки механизм групповой разработки. Если с разными расширениями работают разные разработчики, то они могут подключать только свои расширения. Расширение подключается за секунду, не вижу здесь "головняка". Вижу "головняк", когда 20 разработчиков пытаются модифицировать расширение не подключенное к хранилищу, а администратору их нужно как-то разруливать.
(1) Есть и другая сторона, когда есть расширение которое при необходимости подключается к ряду типовых конфигураций, например обработчик клиент-банка. Да и уровни доступа могут быть разные к хранилищам разных расширений и основной конфигурации.
При такой ситуации хранилище проекта неактуально, а отдельное хранилище для расширения - то что надо. Поэтому вряд ли разработчики будут делать общее хранилище проекта.
Рациональный подход к количеству - 0 расширений. Потому, что пока сравнение-объединение с новой конфигурацией поставщика не учитывает расширения есть не иллюзорный вариант попасть и не заметить как.
Что-то мне подсказывает, что не из-за невозможности групповой разработки разработчики обходят расширения, далеко не из-за этого.
(4) Вы пробовали базу, где более 100 пользователей динамически обновить пару раз в подряд? Если да то поймете, что система проседает, если обновлять через расширения, то нет. Фиксить ошибки моментально в рабочей базе не через расширения - это уже прошлое десятилетие. Те разработчики, которые обходят расширения, скоро уйдут на второй план, как разработчики 1С 7.7 ушли.
(6) Привет, Дима. Не ожидал тебя увидеть тут в качестве обозревателя =)
По поводу расширений есть негативный опыт. Не знаю как в новых версиях ERP, но в 2.1 при обновлении расширения - система пользователей старается принудительно выгнать из программы, чего не бывает с динамическим обновлением. Да и 1С оптимизировала обновление конфигурации, на новых платформах не должно быть сильно долго. Пиши еще!
(6) вот полностью согласен. Вообще обычно достаточно раз поразгребать косяки динамического обновления, чтобы раз и навсегда забыть о нем. Я если честно, за исключением конфигураций на обычных формах, уже забыл, когда выгонял кого-то для применения каких-то доработок. Расширения недооцениваются, в основном незаслуженно, даже не попытавшись в них разобраться.
(6)Вы можете даже как молитву это повторять каждый Божий день, кривая приблуда от этого прямее не станет. По факту я расширения использую, скорее потому что это слегка предохраняет меня от того, что я когда-нибудь накачу очередной релиз, который частично или полностью сломает мои доработки-логически, или физически. Как примерно я раньше использовал файл, в котором хранил список изменений относительно типовой. Расширения раскрячивает после каждого обновления релиза, который затрагивает модифицированные объекты. И каждый раз я ловлю себя на мысли, что если бы в них хранились жизненно важные структурные изменения, это могло бы привести к неиллюзорным проблемам. Пока получается, что нужно структурные изменения делать в основной конфигурации, а изменения типа изменений на форме, отчетов и обработок можно делать в самом расширении. Но как только релиз затрагивает измененные объекты, можно сразу начинать искать глюки. Обновляя связь с буферной конфой, к которой подключено расширение волшебной кнопкой в расширении. Причем могут даже отваливаться унаследованные реквизиты. Они при этом выглядят как неактивные.
Это первый важный момент. И чем сложнее расширение и больше в нем модифицированных форм и объектов, тем больше приходится прокликивать после обновления и тем выше вероятность что-то пропустить, что кстати в режиме сравнения и обновления как раз пропустить сложно.
Второй важный момент состоит в пакетном обновлении расширений, если обслуживается несколько одинаковых конф. Я пока не нашел понятной инфы о ключах командной строки для пакетного обновления расширений в конфигурациях.
А так да, штука хорошая, но как многие хорошие штуки, слегка затормозившая в развитии относительно реальных потребностей.
Про известные ограничения расширений я тактично умолчу. Ситуация сильно напоминает ситуацию с конвертациями. Не успели толком разобраться со 2, как приехала 3, абсолютно другая. А многие еще толком не разобрались с предыдущей по причине скудного количества разрозненных материалов по ней.
Шастун Алексей поднимает вопрос одновременного использования хранилища и расширений. В статье рассмотрены плюсы и минусы хранилища и расширений, а также возможные варианты их использования. Также автор описывает два практических кейса по организации одновременного использования хранилища и расширений 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. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
Механизмы конфигуратора, обеспечивающие групповую разработку прикладного решения, позволяют группе разработчиков вносить изменения в конфигурацию одновременно, по мере выполнения каждым из них своего участка работы. Такой порядок внесения изменений обеспечивается возможностью определить права доступа каждого из разработчиков на модификацию объектов прикладного решения:
Хранилище конфигурации
Хранилище конфигурации является средством, позволяющим осуществлять групповую разработку прикладных решений. Также хранилище конфигурации обеспечивает версионирование изменений, выполняемых в разрабатываемой конфигурации. В силу этого использование хранилища может быть очень полезным и для одного разработчика, т. к. позволяет документировать изменения, выполняемые в прикладном решении и работать с версиями.
Для осуществления групповой разработки прикладного решения на общедоступном сетевом ресурсе создается хранилище конфигурации и назначается его администратор:
Администратор осуществляет формирование списка пользователей, имеющих доступ к хранилищу, может просматривать список пользователей, подключенных к хранилищу и освобождать объекты конфигурации от захвата:
Для того чтобы иметь возможность модифицировать прикладное решение, расположенное в хранилище, разработчику необходимо подключиться к хранилищу, указав имя пользователя и пароль:
Окно хранилища конфигурации
При групповой разработке прикладное решение рассматривается как набор объектов, закрытых для изменения. Каждый из пользователей, допущенных к работе с хранилищем, может «захватить» для изменения произвольное число объектов, не захваченных другими пользователями. Каждый объект может быть захвачен только одним пользователем:
Каждый из разработчиков, подключенных к хранилищу, редактирует захваченные в хранилище объекты и отлаживает прикладное решение на своей текущей информационной базе так же, как и в обычном режиме. После внесения изменений в объект прикладного решения, разработчик может поместить измененный объект в хранилище с тем, чтобы другие пользователи могли обновить этот объект в своих конфигурациях. При этом разработчик может снабдить выполненные изменения текстовым комментарием:
В любой момент времени можно выполнить сравнение текущей конфигурации с хранилищем или выполнить сохранение хранилища как конфигурации.
История хранилища
Конфигуратор 1С:Предприятия поддерживает ведение истории хранилища:
Каждая строка списка отображает очередную версию прикладного решения в хранилище. Каждую версию можно открыть для просмотра, загрузить вместо текущей, сравнить с текущей или сохранить в файл на диске.
Поддерживается возможность отката назад и удаления ненужных версий, опубликованных в хранилище, а также возможность удаления самых ранних ненужных версий путем сокращения до нужной версии.
Существует возможность вывода отчетов по истории хранилища, содержащих информацию об изменении отдельных элементов прикладного решения и всего прикладного решения в целом:
Отчет по версиям хранилища отражает состав добавленных или измененных объектов:
Отчет по объектам разработки содержит информацию об изменениях, которые были внесены в конкретные объекты прикладного решения:
Отчет по комментариям позволяет анализировать комментарии, которыми разработчики сопровождают изменения конфигурации:
Таким образом, использование хранилища полезно и для одного разработчика, т. к. история хранилища позволяет документировать изменения, выполняемые в прикладном решении и работать с версиями.
Работа с хранилищем в окне конфигурации
Функции работы с хранилищем доступны не только из окна хранилища, но из окна конфигурации. В нем, так же как и в окне хранилища, отображается состояние объектов конфигурации:
Находясь в окне конфигурации, разработчик может захватывать объекты в хранилище, отменять захват, помещать объекты в хранилище, сравнивать объект с объектом, находящимся в хранилище и получать историю объекта хранилища.
Кроме этого можно выполнять выборочное сравнение, при котором не производится сравнение конфигураций целиком (новой и старой версии). Сравниваются только отдельные свойства интересующего объекта или сам объект. Список свойств, доступных для выборочного сравнения, отображается в контекстном меню.
Работа с хранилищем без подключения
Некоторые действия с хранилищем можно выполнять без подключения. Если текущая конфигурация не подключена к хранилищу, разработчик может установить соединение с хранилищем:
В режиме соединения будут доступны все действия, связанные с просмотром данных хранилища, сравнением объектов и конфигураций, а также администрирование хранилища (при наличии соответствующих прав). Недоступны только действия, связанные с захватом и помещением объектов в хранилище:
Удаленная работа с хранилищем конфигурации
Хранилище конфигурации может располагаться на компьютере под управлением операционных систем как Windows, так и Linux. В операционной системе Windows сервер хранилища конфигурации может быть запущен как приложение или установлен как сервис. В операционной системе Linux сервер хранилища конфигурации может быть запущен как процесс или как демон. При этом:
Проверка и исправление хранилища конфигурации
Для автономной проверки хранилища конфигурации может использоваться утилита восстановления файловой базы данных. Исправлять хранилище этой утилитой не рекомендуется.
Однако в случае потери копии последней версии конфигурации можно попытаться выполнить исправление файла базы данных хранилища для того, чтобы получить из него последнюю версию конфигурации, на основе которой создать новое хранилище.
Хранилище конфигурации в 1С 8.2 и 8.3 — это инструмент для групповой разработки решения, встроенный в платформу 1С: Предприятие 8. Хранилище позволяет вести многопользовательскую разработку решений неограниченным количеством пользователей. С его помощью можно увидеть полную историю разработки конфигурации и каждый шаг разработчиков в подробностях.
Рассмотрим настройки и работу с хранилищем конфигурации подробнее.
Как работает хранилище 1С
Хранилище, по сути, это база данных, где хранятся изменения конфигурации. Каждый из разработчиков работает со своей информационной базой, подключенной к хранилищу. Рабочая база так же может быть подключена к хранилищу. Лучше всего общая схема изображена на этой картинке:
Так же в этой БД хранится информации о том, кем захвачен тот и или иной объект. Захват объекта — это метка, устанавливаемая разработчиком. Установленный захват позволяет избежать коллизий при групповой разработке. Пока объект захвачен, никто не может его редактировать.
Захватить можно как объект целиком (рекурсивно), так и отдельно объект или формы.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
После того как разработчик произвел какие-то действия над объектом, он обязан поместить доработки в хранилище. И тем самым снять пометку о том, что объект захвачен.
Как создать хранилище 1С
Создать хранилище достаточно просто, для этого необходимо выбрать в меню «Конфигурация — Хранилище конфигурации» пункт «Создать хранилище». В появившемся меню достаточно указать путь к будущему расположению хранилища и логин/пароль пользователя-администратора:
При создании сделайте обязательно резервную учетную запись с административными правами — очень часто это выручает.
Как подключиться к хранилищу 1С
Чтобы подключиться к хранилищу конфигурации, нужно выбрать в меню в меню «Конфигурация — Хранилище конфигурации» пункт «Подключиться к хранилищу». В появившемся окне необходимо указать путь к хранилищу и логин/пароль пользователя, нажать «Подключиться»:
В момент подключения Ваша конфигурация заменится конфигурацией из хранилища, будьте внимательны.
Администрирование хранилища конфигурации 1С
Для администрирования хранилища 1С необходимо выбрать в меню конфигурации следующий пункт — «Конфигурация — Хранилище конфигурации — Администрирование»:
- На вкладке «Пользователи» можно добавить или удалить новых пользователей, а также определить состав прав для каждого из них.
- На вкладке «Подключения» можно просмотреть всех пользователей, подключившихся к хранилищу, по необходимости отключить их.
- На вкладке «Отмена захвата» Вы можете снять захват любого пользователя на определенный объект, если конечно же Вы имеете права на это.
Как просмотреть историю хранилища 1С
Для просмотра истории надо зайти в меню «Конфигурация — Хранилище конфигурации», выбрать пункт «История хранилища»:
В истории хранилища 1С можно увидеть, когда, кем и что было изменено.
Разработка с хранилищем 1С 8.3
Работу с хранилищем условно можно разделить на основные действия:
-
конфигурации из хранилища конфигурации 1С;
- обновить статусы хранилища 1С;
- захват в хранилище;
- помещение в хранилище.
Остановимся подробнее на каждом действии:
Обновить статусы хранилища 1С
Производит получение последних статусов объектов (захвачен или нет).
Вызывается: «Конфигурация — Хранилище конфигурации — Обновить статусы».
Обновление конфигурации из хранилища конфигурации 1С
Действие позволит получить все измененные объекты конфигурации, которые были помещены в хранилище. Выполнение данной команды так же обновляет статусы объектов.
Вызывается: «Конфигурация — Хранилище конфигурации — Обновить конфигурацию из хранилища».
Захват в хранилище конфигурации 1С
С помощью этой команды можно заблокировать изменение данного объекта для других разработчиков: пока объект захвачен Вами, никакой пользователь не может изменить его до тех пор, пока Вы не поместите объект обратно.
Произвести захват можно, вызвав правой кнопкой контекстное меню у объекта метаданных:
В открывшемся окне можно установить некоторые настройки:
- Выполнять рекурсивно — позволяет захватить все подчиненные объекты — формы и т.д.
- Разрешать получать захваченные — позволяет получать другим пользователям промежуточные версии объекта
Помещение в хранилище 1С
После изменения объекта его необходимо поместить обратно в хранилище, делается это так же, как захват, только выбирается пункт «Поместить в хранилище»:
При помещении обязательно заполняйте поле «комментарий», это очень важно при групповой разработке. Через полгода Вы и не вспомните, зачем производили те или иные действия. Так же, как у захвата, у помещения есть свои специфичные настройки:
- Выполнять рекурсивно — позволяет поместить все подчиненные объекты — формы и т.д.
- Оставить захваченными — позволяет поместить «промежуточную» версию объекта, оставив при этом захват пользователем
Как добавить новый объект в хранилище 1С
Для этого необходимо захватить «корень» конфигурации, а после добавления объектов (справочников, регистров, перечислений и т.п.) поместить корень конфигурации обратно в хранилище.
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Читайте также: