gifts2017

Хранилище конфигурации: не очевидные особенности групповой разработки

Опубликовал Алексей Орлов (_also) в раздел Программирование - Практика программирования

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

Введение

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

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

Базовый порядок работы

Итак, сначала вкратце опишу базовый порядок работы с хранилищем, который используем мы:

  • Рабочая база подключена к хранилищу;
  • Для каждого разработчика создается отдельная копия;
  • Пользователей хранилища мы называем по имени базы на 1с сервере. Пароль всегда стандартный и одинаковый. Это очень удобно. Совершенно не нужно помнить никаких логинов/паролей. Если ты заходишь в конфигуратор рабочей базы, то вводишь в логин имя рабочей, в копии - имена копий;
  • Рабочая база (желательно ежедневно) в ручном или автоматическом режиме обновляется из хранилища;
  • Если в течение дня пришлось что-то аврально исправлять, то можно внести исправление и в рабочей базе, но сразу поместить изменения в хранилище.


Особенности

Теперь перейдем к вещам, которые обязательно нужно помнить при работе с хранилищем. Многие из них достаточно очевидны. Однако есть и такие, которые мы “словили”.

Хочу обратить внимание, что основное “словили” заключается в особенностях ведения наших проектов, однако полагаю что для многих это также актуально. У нас есть несколько самописных систем, которые уже эксплуатируются, но также активно дорабатываются. В рабочие конфигурации внедряются новые подсистемы, затрагивающие достаточно большой функционал. При этом, как всегда, всем надо всё и быстро, и мы не можем себе позволить по полгода разрабатывать/тестировать функционал где-то в сторонке, а уже потом внедрять его в рабочие системы. Чаще всего проекты  разбиваются на маленькие и средние задания на разработку. Такое задание попадает к разработчику, он в своей копии пишет то, что надо.  Потом, на его же копии всё тестируется, и если все хорошо, через хранилище обновляется рабочая БД. Не будем останавливаться на том, что так разработку вести не очень хорошо, но что, то есть, и уверен у многих похожие ситуации.

Теперь подробнее о таких особенностях:


Правила работы с корнем конфигурации

Правило номер 1: не держите захваченным корень конфигурации!

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

  • Захватываем корень;

  • Добавляем новый объект;

  • Помещаем корень и новый объект;

  • Захватываем объект обратно.

Думаю многие работают по такому принципу. Вроде удобно, что корень всегда свободен для других разработчиков. Если даже новые объекты обновляются на рабочую - тоже ничего страшного (на них нет прав и их никто не увидит). Однако такой способ, помимо удобства, может содержать не очевидные неожиданности. О которых далее.



Составные поля - зло

Составные поля содержат в себе несколько неожиданностей при работе с хранилищем при нашей схеме разработки. Приведу несколько примеров.

  • Добавление нового документа. Допустим необходимо добавить новый документ, но он, в свою очередь, является регистратором уже существующего регистра. Если мы пойдем по стандартному пути работы с корнем, вот что нас ждет. Мы добавим документ и поместим его в хранилище, т.е. этот документ появится в рабочей базе. В итоге у поля регистратор существующего регистра добавится новый тип документа, на который, я напоминаю, у пользователей нет прав. Таким образом, в рабочей базе пользователи могут словить “Нарушение прав доступа” при чтении таблицы регистра.

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

Правило номер 2: думайте о составных полях и правах. Не помещайте объекты в хранилище бездумно!


Правила работы с ролями

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

Вообще, при разработке новых подсистем, я придерживаюсь такого принципа. Я просто добавляю новую роль(или несколько) для данной подсистемы и на все новые объекты даю права исключительно этой роли. Когда подсистема внедряется, то просто нужным пользователям добавляем эту роль.



Особо хочу отметить очень не очевидную проблему при работе с ролями вроде ПолныеПрава или Администратор. В общем с любыми ролями, у которых установлен флаг “Устанавливать права для новых объектов”:


Сначала сформулирую правило номер 3: старайтесь никогда не захватывать в хранилище роль ПолныеПрава!

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

Так почему же не надо захватывать такие роли?

Ну, во-первых, в большинстве случаев это просто не нужно.

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


Дополнительные полезные советы:

  • Старайтесь помещать объекты в хранилище не по одному, а “пакетом”: все объекты, измененные в рамках одной задачи.

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

Во-вторых, позволяет проще ориентироваться в версиях конфигурации. Тут я советую также пользоваться метками для версии в хранилище.

  • Пользуйтесь окном “Хранилище конфигурации”. К сожалению, почему-то не все знают о его существовании. А тем не менее, оно очень полезное. Например, в нем можно пакетно захватывать, помещать объекты в хранилище (через ctrl), ставить отборы (Все захваченные и Все захваченные пользователем).

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


  • При какой-либо не удачной попытке подключения к хранилищу (например, Вы случайно нажали отмена при подключении), 1с выдаст Вам вот такой диалог:

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

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


Спасибо за внимание, надеюсь для кого то информация окажется полезной. У кого есть что добавить, добро пожаловать в комментарии.


См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Александр Капустин (kapustinag) 03.06.13 12:09
C картинками какая-то проблема. Не отображаются картинки в тексте публикации, только место пустое. В трех доступных мне броузерах посмотрел - везде пусто. Или все-же у меня локальная проблема?
2. Алексей Орлов (_also) 03.06.13 12:41
(1) kapustinag, проверьте сейчас, пожалуйста.
3. Егор Ермаков (mentos) 03.06.13 13:56
Пользователей хранилища мы называем по имени базы на 1с сервере.

вот за это спасибо :) простейшая вещь, но в голову никогда не приходила
4. Алексей Орлов (_also) 03.06.13 14:21
(3) mentos, да, это очень удобно
5. Александр Капустин (kapustinag) 03.06.13 15:43
Похоже, стоит фильтр на нашем прокси-сервере. Картинки-то не на сервере Инфостарта, а на google...
С другого компьютера, внешнего, зашел - все Ок.
6. Алексей Орлов (_also) 03.06.13 15:47
(5) kapustinag, видимо инфостарт не копирует лишнего на свой сервер. Я в статье делал вставить картинку и указывал url.
7. Alexander Speshilov (speshuric) 03.06.13 21:20
"Рабочая база подключена к хранилищу;" - после этого читать желание пропало.
8. Алексей Орлов (_also) 03.06.13 21:24
(7) Поясните свою точку зрения
9. Alexander Speshilov (speshuric) 03.06.13 22:35
(8) _also
Сразу скажу, что я и сам какое-то время так делал. Пока не переубедил коллег. Я считаю, что вешать продуктовую базу на хранилище - по надёжности это примерно аналог того, что подписаться на автообновления midnight сборок. Правильным вариантом является выплёвывать файлы поставки и держать продуктовую базу у себя на поставке "на замочке". В этом режиме можно обновлять и ежедневно и еженедельно и вообще, как пожелаете.
Лет 5 с лишним назад накидал схемку того, как примерно это выглядит. Нюансов там заметно больше, но для начала обсуждения вполне пойдёт.

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

Если исправления не авральные, то как бонус - можно протестировать именно тот файл поставки, который пойдёт в бой, хотя б "джентельменский набор": синтаксис, проверки конфы, логин админа, логин пользователя, время реструктуризации. Автоматизируется на раз-два, зато не сможете совершить ошибку, которую допустила 1С в релизе УПП 1.2.8:
Исправлена ошибка 00092921:
При входе пользователя не с полными правами происходит ошибка.

Опять же заранее будет видно если косяк с реструктуризацией и т.п.

Я ни в коем случае не спорю с самими советами. И роли, и составные типы, и многие другие советы вполне разумны и интересны, но модель "рабочая на хранилище" меня пугает очень сильно.
KapasMordorov; pit201201; omut; kuntashov; bird21; CratosX; Ish_2; laduk; xzorkiix; _also; awk; +11 Ответить 3
10. Алексей Орлов (_also) 03.06.13 23:28
(9) speshuric,
держать продуктовую базу у себя на поставке "на замочке"

это мечта. Конкретно в наших реалиях авральных исправлений порой больше, чем нормальных обновлений, так что... НУ не можем мы себе такого позволить.
Спасибо за схемку, подход у Вас очень правильный. Однако я считаю ее слишком тяжелой для случаев небольших баз, с небольшим количеством пользователей, И... с низкоквалифицированными программистами.
В любом случае спасибо за конструктив, этого я и ждал :)
11. Евгений Сосна (pumbaE) 03.06.13 23:32
(9) speshuric, не хватает хранилищу "веток".
Ваша схема подойдет когда все таки проводятса какие-либо автоматические тесты или даже есть отдельный тестировщик или же пользователи проверяют в отдельной тестовой базе данные, перед помещением в рабочую базу.
Но чаще, к сожалению, конечный потребитель доработок является и тестировщиком и пользователем одновременно и об ошибках програмисты узнают утром не от build-бота, а от полоьзователей.

p.s: Имхо, вряд ли что-то изменится кардинально даже с выходом 8.3 и возможности тестирования, если сама 1С не повернетса к программистам и не будет пропогандировать "best practice" среди программистов и будет публиковать тесты к типовым конфигурациям (скептик во мне заявляет "Не бывать этому!"). Возможно будут единицы использовать тесты, чего таить и сам не без греха, но я то постараюсь вместе с Артуром Аюхановым поразрабатывать в стиле TDD , а основаня масса програмистов так и будет писать комментарии в коде "Здесь было Вася" и считать, что это верх совершенства в способах доработок типового кода, а про тестирование даже понятия не иметь.
p.s.s: Я знаю, что автоматическое тестирование - это не волшебная пилюля.
kuntashov; KEV8383; _also; +3 Ответить 3
12. Алексей Орлов (_also) 03.06.13 23:40
(11) pumbaE, подписываюсь под каждым словом. Но думаю, что тестов к типовым мы так и не дождемся. И, кстати, даже "Здесь был Вася", к сожалению, не все пишут.
13. Алексей Орлов (_also) 03.06.13 23:42
(11) pumbaE, Жень, а не тестировал работу с хранилищем в 8.3. 1С там заявляла какие-то ништяки. Мол работать будет сравнение быстрее?
14. Евгений Сосна (pumbaE) 03.06.13 23:49
(13) _also, пока нет, дети заболели, нет времени. По тому что видел, для себя кардинального ничего не вынес. Пока вижу структуру хранилища похожую на git(но могу и ошибаться, но тут трудно что-либо новое придумать как со справочником "Номенклатура"). Скорость по сравнению с хранилищем старым действительно быстрее. По сравнению с аналогичной историей экспортированной в git хранилище еще не тестировал.
15. Алексей Орлов (_also) 03.06.13 23:52
(14) pumbaE, я понял. Надо что-то придумывать с ролями и частичной выгрузкой в xml 8.3 и переходить на git...
16. Alexander Speshilov (speshuric) 03.06.13 23:55
(10) _also, Как раз с низкоквалифицированными сотрудниками схема "с поставкой" лучше. Натаскать сервис-деск или кого-то подобной квалификации на проверку и формаирование релиза достаточно просто, а времени высвобождается немало: это и проверка и выгоняние пользователей и само применение. Когда писалась эта схема как раз одна из целей была пульнуть в сопровождателей релизом и самому не греть голову.
(11) pumbaE, Веток не хватает. Git не хватает с распределённой структурой. Есть такое. Но цикл сборка/поставка дисциплинирует вне зависимости от того есть тестировщик или нет. Просто же: собрал, проверил синтаксис и конфу на ошибки, проверил реструктуризацию, проверил логин великого админа и проверил логин твари ничтожной. Да хоть бы и в УПП - это займёт на нормальной железяке около получаса от силы. Не хочешь сам - отдай "подовану", заодно пусть посмотрит изменения и покритикует, если время есть. Выше приведён пример, что и фирма 1С когда-то забивала на эти проверки и к чему это приводило. Не нужен на этом уровне ни билдбот, ни отдельный тестер. Нужен просто этап "Я собрал поставку, я сейчас её накачу и хочу проверить, что мне не придётся сидеть 2 выходных и восстанавливать работу предприятия".

Давайте не будем пенять на 1С и ждать когда она "повернетса к программистам" (кстати, какой стороной? :) ). Хочется, чтобы был идеальный код - начни с себя и своего коллектива. Юнит-тестов не хватает? Так надо писать и показывать на практике результативность этого подхода, другие методы не сработают.
KEV8383; xzorkiix; _also; +3 Ответить 1
17. Алексей Орлов (_also) 04.06.13 00:00
(16) speshuric, низкоквалифицированные сотрудники порождают такой код, что придется каждый день с поставки снимать.
За "начни с себя" - огромный плюс. Мы все кивать горазды, а сами производим тот еще.. продукт ((
18. Илья Кутузов (Kutuzov) 04.06.13 08:12
Еще хотелось бы подробную инструкцию по настройке подключения к хранилищу через интернет.
19. Игорь Гончаров (SPID) 04.06.13 09:04
По поводу "Захватил корень - добавил объект - поместил корень - захватил объект и дальше его разрабатываеш" тоже кроется подвох, если этот объект регистр - нужно не забыть добавить хоть одно измерение и назначить регистратор, если он необходим. Если поместить пустой регистр в хранилище, то для разработчика получившего конфигурацию с хранилища ждет сюрприз - он не сможет обновить конфигурацию БД, конфигуратор будет "ругаться" на этот регистр без регистратора и/или без измерений.
20. Алексей Орлов (_also) 04.06.13 09:11
(19) SPID, согласен. Вообще лучше все новые объекты, в том числе с реквизитами за один раз добавлять.
21. Евгений Шабалин (xzorkiix) 05.06.13 11:07
текст читаешь, приговаривая "конечно", "это же логично". Но всё равно полезно.

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

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

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

Имхо, на инфостарт-евенте скорее такого простого доклада ожидал, а поверх какие плюшки появляются при внедрении иных продуктов, технологий, методологий.
22. Евгений Сосна (pumbaE) 05.06.13 11:37
(21) xzorkiix, не ставил себе целью описания работы с хранилищем. Рассказывать банальные вещи не очень хочется ни мне и вам их слушать тоже думаю не сильно охота.

Комментарий к коммиту - это одно из главных и трудных правил которые надо заставлять себя выполнять.


p.s.: Ben Collins-Sussman: Итак есть два "класса" программистов-разработчиков, назовем их "20%" и "80%", основная движущая сила индуструии программного обеспечения - это "80%"-ные парни... Их знаний в точности достаточно, что бы сделать свою работу, затем пойти домой и забыть о комьютерах...
Жутка правда №1 - Основной объем...ПО - создается вышеупомянутыми "80%" программистов.
Жуткая правда №2 - Большинство "альфа - гиков" забывают "жуткую правду №1" .

Вышеупомянутым программистам вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между "pull" и "update"...

Ben Collins-Sussman - автор svn.
_also; vikad; +2 Ответить
23. Владимир G (laduk) 05.06.13 13:01
Статья ни о чем, да еще и с неадекватными советами типа: "имя пользователя по имени базы и одинаковые пароли" - по моему полнейший бред;
"Рабочая база автоматически обновляется из хранилища" - да за такое руки поотрывать мало
24. Алексей Орлов (_also) 05.06.13 13:36
(23) laduk, я рад, что Вам понравилось )
25. ффф ыыы (zqzq) 05.06.13 16:56
имя пользователя по имени базы и одинаковые пароли

ИМХО лучше на каждого программиста своего пользователя (с правами захвата) + админа хранилища + юзера с правами только на чтение для обновления рабочей из хранилища (лучше заходить с одного сервера). Тогда и нормальный отчет по истории работы с хранилищем будет. Естественно, для сложных случаев лучше рабочую обновлять поставками/объединением.
26. Сергей Ш (cdover) 07.08.14 18:20
всё по полочкам. Спасибо!
27. Евгений Фербер (omut) 07.08.14 22:56
(9) speshuric, полностью поддерживаю. Сам работаю точно по такой же схеме :)
Отдельно по запуску (пароли, пароли, пароли...) У кого нет снегопата: напишите батник с параметрами запуска и сразу попадете в конфигуратор под нужным пользователем в нужную базу и подключением к хранилищу. Если баз много, то файлов будет тоже много. Но это уже, что называется, на любителя. На всякий случай, если кто не знает, пример строки в батнике такой:
"C:\Program Files (x86)\1cv82\ВАША_ВЕРСИЯ_ПЛАТФОРМЫ\bin\1cv8.exe" DESIGNER /S СЕРВЕР_1С/ИМЯ_БД_1С /NИМЯ_ПОЛЬЗОВАТЕЛЯ_1С /PПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_1С /ConfigurationRepositoryNИМЯ_ПОЛЬЗОВАТЕЛЯ_ХРАЛИНИЩА /ConfigurationRepositoryPПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_ХРАНИЛИЩА (для клиент-серверной БД, если файловая база, то вместо /S ставим /F и дальше папку БД вместо сервера и имени БД)
28. Михаил Рожков (Templ) 15.04.15 11:35
Из-за чего может быть. Внесли изменения из хранлища в основную базу. И оказалось что в рабочую базу затянулось старая версия изменений.
29. Stas Churkin (Stas-ch) 18.04.16 11:07
(27) omut,
а зачем батники? Можно ведь все прописать сразу в параметрах запуска 1С. Из минусов - надо прописывать у всех, кто работает с базой (копи-паст рулит), зато нет кучи батников.
30. Stas Churkin (Stas-ch) 18.04.16 11:10
а вот никто не знает как в случае копирования базы с изменениями, не внесенными в хранилище, перенести информацию о подключении к хранилище в эту новую базу?
т.е. средствами SQL скопировали базу, старую убили (или пока еще нет, но скоро убьют). Захожу в новую базу а информации о подключении ее к хранилищу нет - при попытке подключения к хранилищу вся информация замещается данными хранилища. Приходится выгружать через конфигуратор все изменения и закачивать их в новую базу. Муторно. Может есть способ проще? Поделитесь.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа