Есть живая рабочая база. подключенная к хранилищу. Над базой работают несколько разработчиков. Каждый сидит в своей копии базы, подключенной к хранилищу. При этом в хранилище есть пользователь "Админ" а админскими правами, без пароля и под ним все разработчики заходят в рабочую базу и обновляются из хранилища. Под другими пользователями хранилища к рабочей базе не подключаются.
Вопрос: Именно так нужно организовывать порядок работы с базой?

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

Я как программист, находящийся на фикси и ответственный за эту базу, хочу убедиться
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ жж0те, сударь!

(0) одна база может подключаться к хранилищу только под одним пользователем, в данном случае под пользователем Админ

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

(2)получается всё организовано идеально

(4) они не могут одновременно сидеть под админом, чето ты путаешь

(4) не уверен, что для пользователя, под которым все подключаются к хранилищу для обновления рабочей базы, нужны админские права

ни в коем случае не подключай рабочукю к хранилищу!!!!

Если много разработчиков, то обновление должно идти только через обьединение (для того что-бы лишнего не накатить)

(0) Ты хочешь сказать что все изменения, которые делаются накатываются на рабочую базу? ИМХО - не правильно. Нужно промежуточное хранилище для разработки, а в рабочую должны накатываться только необходимые блоки.

(0) "есть пользователь "Админ" а админскими правами, без пароля" - после такого надо увольнять весь ИТ отдел скопом :)))

(5)а они не одновременно сидят. а по очереди тоесть когда кому-нибудь из них надо обновить рабочую базу, они заходят под админом и обновляются. а в своих копиях они логинятся под другими пользователями хранилища.

(10) прикольно и никто потом не выяснит , кто что менял..

кроме того более правильно когда есть ОДИН человек который накатывает ВСЕ изменения в базу, именно он и несет ответственнотсть за все, и этот человек "старший" над остальными

хотя не , путаю

(9)это же админские права к хранилищу. а не к конфигуратору. обычные пользователи не смогут воспользоваться такими правами.

ну и последнее - нефиг франчей даже близко подпускать к РАБОЧЕЙ...

(0) а дай доступ на удаленку?! Все-равно у вас пароля на админа нет - значит скрывать нечего!

(15)ну эти франчи важные куски нетиповой делали. сейчас они доделывают свои задачи и устраняют свои косяки. потом просто им уже не будут поступать новые задачи.
(12)согласен. меня тоже смутил такой расклад как сейчас имеет место. Но пока контролировать их некому. у меня и так завал работы. а новые задания они не получат.
(7)не понимаю почему так? их не так уж много внешних программистов.
(16)а как ты залогинишься к базе если у тебя нет пользователя ? другие юзеры кто к базе подключен все равно не смогут к хранилищу подключиться - прав не хватит.

+7 Или поставку.
+ урезать права, нечего под админскими правами входить. На каждого разработчика - свой логин.

(14) "Разруха в головах" (с)

(7) +1, но не через объединение, а через поставку.
(0) Сделать боевую "с красным замочком" на своей поставке и выплёвывать релизы. И никаких хранилищ на боевой.

(18)как они под своим логином будут входить если смена логина отключает предыдущего пользвоателя от хранилищя и подключает нового а это знаешь как долго?

(19)а почему никаких хранилищ на боевой то? удобно же поработал локально закинул в хранилище объекты зашел в рабочую и получил объекты из хранилища

Бери ситуацию под свой контроль.
1. Все задачки по доработке и устранению ошибок тольок через тебя. Ты вникаешь и пересылаешь им.
2. Все обновления через тебя. Если что-то не таок они могут сказать что ты виноват. А так хоть контролировать будешь.
3. Если не хватает знаний подружись с франем.

(21) Любой маломальский косяк и здрасти мыло,веревка,вазелин и прочие прелести райской жизни.

А Вы наверно и динамическим обновлением пользуетесь частенько ?

(23)а как же без него то? если посреди рабочего дня постоянно всякие косячки правлю ?

(22)возьму. а с франчем в хорошем отношении. только они понимают что я их хлеб постепенно забирать буду. а задачи через фин директора к ним шли. но они доделают то что должны и больше им не дадим задачь.

(0)
У нас хранилище - на локальной машине (общее), после тестирования всех сделанных изменений идет сравнение-объединение с рабочей (раз в неделю-две). При этом присутствует система учета требований (Bugtrack). Результат: схема прозрачна и работает. В редких срочных случаях - динамическое обновление.

(24) динамические обновения - зло!
если пользуешь более чем 1 раз в день - значит не правильно работаешь...

я использую примерно 1-2 раза в месяц.

Каждый сидит в своей копии подключенной к базе, включая админа.
Во время обновления админ формирует поставку и проверяет на полной sql копии, записывает время обновления и реструктуризаций, убеждается, что она запустилась в клиентском приложении, проверят по чек листу, что работоспособны жизненно важные механизмы занесенные в чек лист.
Назначается час обновления, о чем пользователям делается объявление заранее, при этои необходимо учитывать разницу по времени между филиалами по миру. Админ составляет план обновления, расставляет время на бэкап, на действия перед обновлением, само обновление, действия после обновления, допустимые отклонения времени, время на аварийный откат. План утверждается у начальника ИТ, который вписывает в план ответственных программистов на поддержку обновления (тех кто больше всего изменений в хранилище намолотил).
Далее делается обновление поставкой, записываются фактические времена когда были сделаны основные пункты плана. В конце делается объявление, что база готова к работе.
Админ и ответственные программисты дежурят около суток в готовности сделать в любой момент откат. После суток объявление считается состоявшимся.

(28)Жёстко!
но в целом верно.

(29) есть еще круче:-) + отсутствует тестирование доработок заказчиком, т.е. финслужбы....:-)

(28) упрощенный вариант

каждый сидит в своей базе, все тестовые базы на отдельном физичеки сервере (сервер разработки и тестирования).

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

(31) у нас проще было - ночью автоматически делается бэкап
и конфа хранилища закачивается в рабочую БД !

(32) то, что на дальнем востоке в это время был разгар рабочего дня никого не смущало?

Кстати если есть УРБД - то там свои пирожки, так-как откатывать просто так нельзя :)

(34) надо все сделать чтобы не откатываться... на своей памяти не помню чтобы приходилось из бэкапа восстанавливаться... всегда как-то выкарабкивались если что случалось... на семере вообще базу на уровне таблиц лечили...

(0) принцип приемлем когда разработчики все "свои"
в твоей ситуация нужно принципиально все обновления живой завязать на себя
франч может начудить перед уходом
да хотя бы даже не специально а студента пошлют на твоей базу поучиться

(31) А теперь, ребята, познакомимся с планом обновления при работе организации в режиме 24*7.

(37))) вотвот - всегда завидовал тем кому удается в 9 прийти и в 18 уйти с работы и не париться насчет 24*7

организация с режимом 24*7 не работает в одной базе, всегда есть разделение
фронт/бек
филиалы
консолидация

и т.д. и т.п.

реально количество БАЗ которые требуют поддержку 24*7 сильно преувеличено :)

(33) неа.... у нас не было пользователей там

(39) если не хочется РИБ принципиально, то можно и в одной 24*7
кроме того платформа 8.2 принесла с собой понятие тонкого клиента
+ возможность управляемых блокировок

(41) они тебе обязательно помогут, когда измениться одно из измерений регистра сведений "СписанныеТовары"

(31) а смысл то обновлением делать? чтоб посмотреть чтоб изменилось и  потом по шапке надавать разрабу? А если 5-7 разрабов, то ведущий 100% времени будет объединять

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

(31) Через объединение могут полететь внутренние идентификаторы метаданных. Это иногда проблема.

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

(45) и на автомате может не похериться то что должно быть похерено

(47) на автомате хериться и не должно.

(46) именно так я франча однажды заставил признать что это было его изменение

(42) наверное у меня небольшая контора в которой около 100-150 различных баз и нет РИБ

но есть регионы