Приветствую Вас, Гость · RSS Суббота, 12.07.2025, 19:53








Главная » 2013 » Июль » 15 » Хранилище конфигурации: создание и использовани�
05:58
 

Хранилище конфигурации: создание и использовани�

(2) .. ну у меня проблемы с этим не возникло, т.к. эти моменты более менее расписаны. А вот с вышеупомянутыми были вопросы, ответы на которые были найдены опытным путем.. в общем, обмен опытом для начинающих работать с системой версионного контроля фирмы 1С.

Назначение галочки рекурсия - в дереве конфигурации происходит захват не только ВЫДЕЛЕННОГО объекта, но и подчиненных ему.. т.е. если, например, выделить "узел" документа "ПриходнаяНакладная" и захватить его - то формы и макеты этого объекта будут незахвачены и над ними может трудится другой программист.. с галочкой рекурсия - будет захвачено все, что к документу относится (формы, макеты)..
Если выделить корень конфигурации, отметить галочку и выполнить захват - то получите АБСОЛЮТНО ВСЕ что входит в конфигурацию.

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

Использование в одиночку - захватываем ВСЕ, делаем необходимую доработку, локально тестируем, сохраняем в хранилище с комментарием что сделано.. впоследствии, если что то не так, можно загрузить конфигурацию на момент ДО сделанной доработки.. можно посмотреть, что и где добавилось, какие изменения были сделаны в модулях - для этого нужно в меню Конфигурация/Хранилище выбрать История, выделить две строки и по правой клавише выбрать команду Сравнить конфигурации..

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

Изменено: - 12.01.10 17:26 (Недосказанная мысль :))

Ответили: (4)

Статья действительно хорошая, автор молодец. Но хочу добавить своих несколько мыслей:
1. Для полноты представления нужно было упомянуть и рассказать о сервере хранилища конфигурации. Что это за штука и с чем ее едят, соединие по tcp и т.д.
2. "можно посмотреть, что и где добавилось, какие изменения были сделаны в модулях - для этого нужно в меню Конфигурация/Хранилище выбрать История" - а если интересуют изменения в конкретном объекте, то лучше смотреть историю изменения объекта - отработает намного быстрее чем сравнение.
3. Неточность: "не забывая перед каждым объединением ОБНОВЛЯТЬ локальные БД из Хранилища - до последней версии" - каждый раз при объединении прийдется захватывать объекты, а при захвате Вы и так получете самую актуальную версию.
4. Обязательно нужно напомнить тот факт, что подключать новую конфигурацию под имеем пользователя, для которого уже есть подключенная конфигурация не следует, потому что это приведет к отключению предыдущей конфигурации. Особенно это актуально для рабочей БД, когда разворачивают бекапы и по невнимательности отключают рабочу БД от хранилища.

эм, что то еще хотел написать, но забыл ... значит позже допишу

Статья полезная.
В работе хранилища действительно очень много неочевидных вещей, поэтому мои дополнения:
1. Если работают несколько программистов, то как вариант,
рабочий день обычно начинается со следущего:
запускаем свою базу в конфигураторе, на корне конфигурации правой кнопкой мышки - получить из хранилища, включаем галочку "рекурсивно", жмем ОК. После этого в конфигурацию получаем все, что наработали другие из хранилища. САМУ БД НЕ ОБНОВЛЯЕМ!!!
Далее желаем "сравнить конфигурацию с конфигурацией БД" - и видим список все изменений сделанных другими программистами группы за предыдущий день. Если есть вопросы по изменениям- обращаемся к тому, кто их делал.
После того, как все разобрали - сохраняем в БД.
Почему не сравнить с конфигурацией хранилища - во-первых чтобы не показывались те объекты, над которым сам работаешь, во-вторых это работает быстрее.
2. В середине дня: срочные изменения (для динамического обновления) отправляем в хранилище сразу. Не срочные - после того, как изменим все связанные объекты. (см. пояснение ниже)
3. В конце дня (а если надо делать полное обновление базы - то перед ним) сдаем в хранилище все что можно.
Это не обязательный порядок, но весьма удобный.

4. Почему не помещаем сразу:
потому что целостность изменений контролируется 1С только там где есть ссылка. То есть если например вы сделали справочник "Автомобили клиентов" и добавили ссылку на него в "расходную накладную", то поместить "Расходную накладную" в хранилище Вы сможете только после (или одновременно) со справочником "Автомобили клиентов". Но если Вы например использовали этот справочник в процедуре общего модуле, которая вызывается при проведении расходной накладной, то этот общий модуль в хранилище спокойно поместиться без помещения справочника. Если после этого другой программист получит этот модуль из хранилища, то в его базе расходные накладные проводиться перестанут. (А если обновить основную базу - то и там перестанут).
И то еще хороший случай - так как возникает просто ошибка. А вот если Вы например изменили тип реквизита в документе со строки на текст и в процедуре общего модуля была проверка Если Реквизит = "1" а стала Если Реквизит = 1 и модуль в хранилище поместили а документ - нет, то ошибки не будет (привет отсутствию контроля типов), а значит у тех кто такой модуль получит документы будет неправильно проводиться, (и хорошо если это будет не основная база). Поэтому изменения лучше сдавать в хранилище "полным пакетом" (все измененные по одной теме объекты), если что-то нужно Вам для другой задачи - можно сразу же захватить по новой или просто, помещая в хранилище, "оставить захваченным".

В этом плане я не совсем понял:

ЦитатаЕсли программистов много - то изменения каждого нужно отправлять в Хранилище поочереди, ПРЕДВАРИТЕЛЬНО выгрузив у всех работу во внешние файлы с конфигурацией локальной БД и (если объединение делается с разных рабочих мест), не забывая перед каждым объединением ОБНОВЛЯТЬ локальные БД из Хранилища - до последней версии, с присутствующим там изменениями ранее подключенных товарищей..

Странно, не было никаких проблем когда несколько человек сразу изменения помещали, разве что подтормаживало малость. На то захват объектов и предусмотрен, чтобы 2 человека сразу одно и то же не исправили. Причем было замечено, что: если 1 разработчик изменил документ, скажем "Авансовый отчет", а затем второй "получения" не делал, а сразу его захватывает (например, объект только что помещен в хранилище), то 1С это отследит и сама даст ему уже новую - измененную версию. (Так прикольно бывает - смотришь на документ - 5 реквизитов, захватываешь - уже 15).

И зачем работу во внешние файлы выгружать тоже не понял.

4. Создание копий базы для программистов проще делать не 1Совской загрузкой-выгрузкой (т.к. она требует монопольного режима и не шибко шустрая), а восстановлением скульного бекапа или просто копированием базе на скуле.

5. Если нужно добавить новый объект (документ, справочник и пр), то захватите корень конфигурации, добавьте его, добавьте минимум реквизитов (совсем "пустые" объекты не всегда сохраняется), сдайте корень в хранилище (этот объект тоже сдастся при этом) и заберите объект опять. (Чтобы не держать корень долго захваченным - он и другим нужен).

6. Если Вы хотите исправить права доступа на объект, захватили его - а права доступа по прежнему недоступны - захватите соответствующую роль.

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

8. Когда делаем "получить все из хранилища" (п. 1) бывает, что 1с выдает кучу сообщений а потом пишет, что "не удалось" (список объектов при этом меняется). Значит давно не получали изменения. Ничего страшного, жмем ОК по новой и так до тех пор, пока не сработает, как надо.

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

10. Поскольку рабочие базы делаются из основной, то названия конфигураций совпадают и их легко перепутать и потом начинаются непонятки, когда пользователе говорит что у него в отчете 100 руб, а у Вас - 100,000 руб. Как вариант, добавляем в модуль приложения строчку, проверяющую при запуске программы что это за база и если не основная - выводящую это в заголовке программы 1С (например "РАБОЧАЯ БАЗА ПРОГРАММИСТА ИВАНОВА")

11. Когда база подключена к хранилищу, но при запуске не удалось к нему подключиться по любым причинам, то может выдаться сообщение "Не удалось подключиться, выполнить отключение от хранилища" (а у Вас есть захваченные объекты) - тут ОТВЕЧАЙТЕ "НЕТ". Но если случайно ответить "да" то - не пытайтесь подключиться по новой!!! Сначала сохраните конфигурацию в файл!!! Так как когда подключаемся к хранилищу, то вся конфигурация базы заменяется на конфигурацию хранилища. После этого загружаем изменения из сохраненного файла и работаем дальше.

Изменено: - 14.01.10 2:35

Еще дополнение.
Когда работаешь над отчетом/обработкой, то удобно сохранить его во внешний файл и с ним работать, чтобы после каждого изменениях не перезапускать 1С. Так вот, возьмите себе за правило - в этом случае объект все равно захватывать. Иначе пока вы меняете внешний файл кто-то может его поменять в базе. А потом будет удивляться пропаже изменений

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

Еще можно сделать каждому разработчику личный общий модуль, тогда если двум человекам очень приперло одновременно работать над одним общим модулем (типа Заказчик так в ТЗ написал что должно быть в одном модуле, или база типовая и не хочется ее сильно менять) действуем так:
1. Захватываем "общий" и свой модули
2. Копируем процедуру из общего в свой , в общем первой строчкой ставим Возврат + Вызов этой функции из своего модуля. Помещаем оба модуля в хранилище, свой опять захватываем.
3. Исправлеям функцию, отлаживаем.
4. Захватываем "общий" модуль, вырезаем процедуру из своего и вставляем в "общий".
5. Помещаем оба модуля в хранилище.
Цель достигнута - из модуля "захватывается" только одна функция. Выглядит криво но еще раз: в реальности нужно очень редко.

Изменено: - 14.01.10 13:02

КодОтключаюсь от хранилища, обновляю рабочую конфигурацию, выгружаю в файл. Затем захожу в рабочий конфигуратор, рекурсивно захватываю корневой элемент конфигурации, сравнить/объединить с конфигурацией из файла, потом помещаю в Хранилище.Все получится??? smile:o
Непонятна цель, с которой это делается.. В норме отключаться от хранилища не нужно, даже вредно.. Если цель - правильно обновить Рабочую конфигурацию, то:
Вносим изменения из обновления в хранилище:
1) заходим в любую конфигурацию, связанную с хранилищем рабочей конфигурации, в конфигураторе
2) захватываем корень рекурсивно
3) обновляем конфигурацию файлом *.cf - сравнение/объединение
4) выполняем возврат рекурсивно
==
.. если при обновлении были внесены изменения в структуру данных БД, то придется ждать или выгонять всех пользователей..
.. если были изменены только модули - то можно обновить конфигурацию динамически (тогда изменения у каждого отдельного пользователя появятся после того, как они выйдут и снова зайдут в программу, т.е. перезапустят её)
Далее обновляем рабочую базу из хранилища:
5) открываем рабочую конфигурацию в конфигураторе
6) обновляем конфигурацию из хранилища
7) загружаем полученные из хранилища изменения клавишей F7 в рабочую БД (динамически или выгнав всех пользователей)
==
Все. Рабочая БД обновлена.

(19) и для всех любителей SVN, CVS, GIT и т.д..

В отношении этих программ - в работе SVN + "Черепашка" мне пригодились даже без "растормашивания" кода 1С до исходников..

Методика такая:
Есть множество обработок, в 1С 77 они лежат в каталоге extform.. конфа старая, отлаженная, основная работа программистов - доработка под меняющиеся постоянно требования внешних отчетов и некоторых обработок.. программстов несколько - как узнать, кто и чего поменял?

Всю папку extforms загружаем в хранилище - прямо 1Совские "недобинарники".. Если заходить ежедневно и делать коммиты изменений каталога в хранилище SVN - то прекрасно отслеживается что (какой файл) и в каком порядке изменялось.. не ясно кто и что в файле изменилось.. но с "что в файле" есть небольшой "черный ходик" - мне помогло.. изменившиеся файлы берем в свой каталог, который тоже в отдельном хранилище (не связанном с ранее упомянутым).. Открываем обработку/отчет и сохраняем тексты его модуля в текстовые файлы. Все это коммитим в хранилище.
В этом хранилище можно видеть что изменилось в модулях/текстах.. только вот с формами облом..

ЧерепашкаSVN очень хорошо жала все файлы - каталог в 43Мб с обработками и т.п. ужался до 14 Мб и рос. очень медленно.. Секрет медленного роста - устройство хранилища SVN таково, что он реально коммитит только изменения даже у бинарников (перезаписывается только разница даже в exe-шниках) - в итоге 2 раза погрузив один и тот же файл (изменена только дата или имя, например), объем увеличится на.. менее чем на 1КБ..

===

Интересно будет попробывать Черепашку с ТЕКСТОВЫМИ файлами от 1С 8, которые оно получает при выгрузке модулей всех конфигураций с помощью СТАНДАРТНОЙ команды: Конфигурация / Выгрузить файлы конфигурации.. жаль при этом формы не выгружаются - но все ж..

Никто не пробовал?

(29)
если еще актуально, то всё просто

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

Полностью (рекурсивно) захватывать объект можно, если не планируется работа других с какими-либо составными частями - формами, макетами и пр. В противном случае, каждый может захватить своё и подливать своё обособленно: если нужно менять структуру и писать в модуле объекта - захватываем сам объект, если формы - только формы.

(30)
как узнать, кто отрубил базу от хранилища? хм... в истории хранилища какие тачки к нему подключены/отключены кем и когда не запоминается, да... тогда, наверное, никак smile:)


ну ваще, чисто административная проблема, имхо. Т.е. такое, да, бывает когда:

а) программист просто ошибся когда выскочил тот самый диалог и ткнул не в ту кнопку. Сам так ошибался не раз. Лечится просто опытом, внимательностью и здоровым сном по ночам )). Тем более, что некритично, ибо в рабочей базе, подключенной к хранилищу, никто ж не кодит, да? smile;) (особенно в её отключенном состоянии)
б) программист - новичок, лечится опытом и доведением до сведения, что отключать рабочую базу от хранилища некрасиво

Т.е. все ситуации - это программисты, а с ними можно/нужно договариваться.

ЗЫ: в) если программистов как кур, и договориться нереально, то переходите на поставки обновлений - тут всё уже четко.

Изменено: - 31.08.11 0:16

Просмотров: 637 | Добавил: washou | Рейтинг: 0.0/0
Всего комментариев: 0
Конструктор сайтовuCoz
Copyright MyCorp © 2025