у нас скульная база с 10-20 постоянно рабочими пользователями. я программист, всегда работала в рабочем конфигураторе, потом в конце рабочего дня принимала все изменения. переехали на новый сервер, появились ошибки СУБД, теперь админ мне говорит, что так нельзя и надо работать в тестовом конфигураторе, а рабочий вообще не открывать пока пользователи в базе.
у меня очень много мелких изменений, в т.ч. в структуре баз данных, так что временно'й целесообразности в этом нет: принятие этих изменений в рабочем конфигураторе займет столько же времени сколько и в тестовом. насколько прав наш админ? действительно все работают в тестовом несмотря ни на что?

(0) к слову сказать админы сервера говорят, что ошибки СУБД из-за 32-х битной версии скуля, и им я верю больше.

Все 1С-ники делятся на 2 группы. Которые уже убивали свои базы и те которым это еще предстоит
:)

Работать в рабочей базе - зло.

Программировать на 'бою' - это фиаско, братан.

а как тестировать свои доработки? конечно нужна тестовая база

(0) Тестовая база нужна тебе, юный падаван!

в крупных конторах прог не имеет доступа в бобевую

(6) "База нужна тебе тестовая" так правильнее

всем спасибо, все понятно)))

а если я буду в конце дня не принимать миллион мелких изменений в рабочую а просто буду сверху конфу накатывать из тестовой, так делается?

(10) не возражаем

почитайте про разработку через хранилище

(8) всё-таки быстрее тренироваться на кроликах

(12) насколько я знаю, тестировать предприятия через хранилище нельзя, так ведь?

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

(14) Что значит нельзя? Все можно, почитайте про это сначала.

(14) неправильно понимаешь

(12) (15) (16) (17) спасибо, подключаю хранилище

(0) Вам перед рабочим днем не выдают полотенце с красным кругом?

https://ru.wikipedia.org/wiki/Камикадзе

В рабочем конфигураторе даже отладки не должно быть. Должна быть только возможность обновить конфу из хранилища. Все остальное в тестовой базе.

(19) эммммм... отладка в рабочей иногда нужна, а вот хранилище к рабочей подключать - верный путь к геморою....

(20) >> вот хранилище к рабочей подключать - верный путь к геморою
Почему?

(20) У нас нет в рабочей отладки, есть свежий бекапчик, при необходимости бекап заливается в скульную тестовую базу. Почему подключать хранилище к рабочей - гемморой? чем это черевато и как вносить доработки, через CF?

(20) При грамотном использовании никакого геморроя.

(23) какое использование не грамотное?

(22) иногда ошибки проявляются ТОЛЬКО при работе на боевой, например всякие обмены и прочее....

(21) по тому, что есть шанс накатить что-то не оттестированое, но уже положенное в хранилище

(20) +100500

(20) +100

(25) >> есть шанс накатить что-то не оттестированое, но уже положенное в хранилище
Какая разница - попадет это в боевую базу напрямую из хранилища или через промежуточный cf?

(25) А зачем что то не оттестированное убирать в хранилище? Что может это заставить сделать?

(28) Ну как бы при сравнении объектов, видно, что какой-то удак добавил реквизит в РТУ, а база на Овер 400ГБ и рту хренова туча и реструктуризация за ночь не пройдет,ну типа как пример

(28) Точнее это нагляднее все

(31) понял.

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

в данном случае в рабочую конфу попадет объект без прав...

сложно представить,что попадёт в базу при такой работе,нсли нет хранилища

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

По хорошему, прод для разработки вообще должен быть не доступен. Должны быть подняты среда для разработки/тестовая среда/сертификационная среда. Релиз документируется и передается админам для установки в прод.
Как то так, если коротЕнько.

(36) +1

(0) в приличном обществе за такие фокусы по щекам хлещут

Поддержку (35) Лет 5 назад, когда на фикси работал, подключал хранилище к рабочей УТ. Иногда ВДРУГ пропадали внесенные ранее в рабочую изменения. С третьего раза я все понял и далее рабочую обновлял только через cf. Сейчас может и починили хранилище, но я не проверяю

Работать и отлаживать надо тестовой. Остальное по вкусу.

(33) И как эта проблема решается, в условиях, когда боевая база НЕ подключена к хранилищу?

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

Пример надуманный и никак не связан с вопросом подключения продуктива к хранилищу.

(0) Разрабатывать в рабочей базе - извращение в принципе.

(35) +9000! Рабочую базу нельзя к хранилищу подключать.
Рабочая база должна обновляться комплектами поставки, выгружаемыми из пустой базы, подключенной к хранилищу.

(0) вы и отлаживаете в рабочей базе?
о_О
самоубивцы

(30) Это про текст электронного чека история?

(44) Иногда, когда нет выбора, не грех и к рабочей подключиться, если база сравнительно небольшая (<200 пользователей). Конечно, за блокировку транзакций пользователям нужно на месте руки отрывать.

(39) У многих была такая проблема. Очень многих.

(43) Можно. И нужно.
Главное, в ней отладку не делать.
Всегда есть две конфигурации в любой базе- хранилища и собственно бызы. И они не пересекаются, пока не применишь изменения.

С таким уровнем вопросов, как у автора, и "миллион мелких изменений в рабочую" - мне страшно за базу!

(48) Предлагаешь изменения без тестирования применять? Круто, чо.

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

(50) Можно и в рабочей тестировать. Только выгнать всех из базы, пусть пока чайку попьют, покурят.. или уж пообедают, пока 1с-ник тестит базу :)

(50) Блин, написал, же, тестирование- в тестовой базе.

(52) нельзя такое делать. Это прямая дорога к потерям данных и затяжным авариям. Добродетельные люди так не делают и уж тем более ни кому не рекомендуют так делать.

(54) А вот с этим соглашусь.

(53) И смысл тогда хранилище к рабочей подключать?

(47) Починили ее уже?

(57) Как-то не тянет проверять)))

ИМХО, рабочую можно на свое хранилище посадить. Так, для информации, какие изменения и когда накатывались. Плюс, какая никакая защита от дурака. Что бы что то поправить, захват их хранилища нужно делать.

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

(59) для этого поставки придуманы
(60) "В хранилище всегда должна быть актуальная конфа" - а работать программистам где? В базе, не подключенной к хранилищу?

(0) крута, раз умудряешься делать без отладки и тестировки.

База не может падать из-за того, что открыт конфгуратор

(62) может. Например, на блокировках, если программист (или лицо, им прикидывающееся) грамотно остановится отладчиком внутри транзакции проведения документа

(61) Можно и поставками. Но, я бы, наверное, еще и хранилище прилепил.
(63) Ну, это будет не "падение базы". :)

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

(61) ну какбэ а в чем проблема? недоделанный функционал в хранилище не выкладывается. и все ок

Как обычно в таких фирмах на 20 юзеров - считают, что выросли из коротких штанишек, и начинают программу дорабатывать, причем "срочно". Если до завтра кнопочку или отчетик не сделаешь - прям умрут все, не иначе!

(66) Я больше скажу ;)
Если передумал что-то менять, сделай отмену захвата объекта в хранилище и все станет как было.

(67) Марь иванна отлучит от печенюшек и сошлет заправлять картриджи.

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

(66) +1

15 Разработчиков работало с прямым подключением к хранилищу все было отлично.

(70) Если не умеете работать по данной схеме не пишите , что это не работает. Отлично работает, если руки прямые.

(70) ну хз... работал в команде из 50+ программистов в одном хранилище и ничего=) просто надо соблюдать правила, коментировать что выкладываешь и не захватывать лишнего

(72) и прод был подключен к этому хранилищу?

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

(74) так и ну о чем ты тут тогда рассказываешь? 50+ и не было проблем... В этом я и не сомневаюсь. Речь-то про другое немного.

(74) см (43) про поставки

(75) про что все таки речь-то? Расскажи нам )
Я сразу написал. что лучше обновлять поставкой, но если руки из нужного места, то и из хранилища обновлять можно. это не проблема.

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

(77) я уже рассказал - (70).
Когда изменения в хранилище помещаются ТОЛЬКО протестированные и уже готовые к релизу, тогда выпуск хотфиксов к объектам, над которыми ведется разработка, не возможен. Либо - это откатить нафиг все разработки, выпустить хотфикс и потом натягивать результаты разработок обратно.

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

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

Одно хранилище - это для одиночек. Подключать прод к хранилищу - для любителей аквалангов и гамаков.

(80) Присоединюсь к коллегам: Вы просто не умеете их готовить!
Из личной практики, у меня отдел разрабов 1С (~15 человек) отлично через хранилище работали.
А вообще, см. (36)

(82) Какое отношение эта сентенция ко мне имеет? Где я сказал, что с хранилищем плохо?


с (36) полностью согласен.

я говорю о том, что (66) препятствует командной разработке.

(79) кстати интересная тема.
на самом деле все не так страшно как кажется. Во первых у нас был механизм замен. т.е. без обновления в режиме предприятия можно было поставить под замену(изменить текст выполняемого кода) любую процедуру, любую форму. это покрывает 99% всех потребностей.
И ситуация когда для разработки разного функционала требуется, допустим, один и тот же объект.довольно редка, и скорее находится в области правильного распределения задач, нежели в области непосредственно разработки. Но при возникновении подобных ситуаций(допустим необходимость использования одного общего модуля) всегда можно экранировать свой код в хранилище и отпускать объект. Это не так уж и сложно.

(85) ну, эти подмены - это костыль, согласись?

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

отклонились насовсем от темы. Автору до таких материй еще очень далеко. Если вообще - когда-нибудь...

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

(54) Знаю яааа!! :)
Естественно, надо всё делать в локальной
В конфигуратор рабочей БД надо лесть только для обновления своими нетленками..
Да и то - после непременного бэкапа..

ЗЫ. для 7-ки, кто помнит, была TurboMD.dll, позволяющая динамически обновить БД.
Молодцы были создатели, ребята, думающие и делающие правильное дело..

(87) по теме автора то сказать нечего.

В рабочей кодить - порнография полная конечно.

Потому и отклонились

(65) 1. Зато медленнее все остальное.
2. Критично только если загружать конфигурацию из файла. Да и то иногда не прокатывает. Ну и поставки никто не отменял.

(66) Потом будут пропадать изменения, сделанные другими программистами.

Все не читал. Судя по всему, ошибки не из-за конфигуратора. Хотя это не корректно. Пусть лучше админы настраивают скуль правильно. И вообще, 32 разряда для СУБД сейчас, это мовитон.

(92) работаю с хранилищем уже почти 8 лет, ни разу без логики ничего не пропало. ЧЯДНТ?

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

(94) Оно с логикой пропадет, потом весь отдел депремируют. Легче станет от того, что логика была?

(95) ну расскажи как? =) Я уже просил описать кейс, когда при нормальной работе с хранилищем пропадают изменения... мне пока никто не рассказал

(86)


Если объект захвачен Разработчиком №1 и требуется внести хотфикс тогда алгоримт следующий:
1) Разработчик №1 сохраняет свою конфу файл.
2) Отпускает объект
3) Вносится хот фикс
4) Разработчик получает и захватывает объект и объединяет со своими изменениями.

Результат достигается за 5 мин. И самое главное , что рабочая конфа у всех разработчиков ВСЕГДА едина. Очень практично и быстро.



Кстати , когда я пришел в большую организацию, показал как работать в продуктиве с напрямую подключенным хранилищем, всем понравилось и самое главное обновления начали проходить намного быстрее и без ошибок.

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

И да. Это очень большие системы в Москве, а не мелкие ларьки. За 4 года работы с напрямую подключенным хранилищем к рабочей БД никаких проблем не было ни разу. Это реальная практика.

(92) За 4 года ничего не пропало у нас. Что мы делаем не так?

(96) Очень просто. 2 программиста в своих базах правят один объект. Потом первый вносит изменения и разблокирует объект в хранилище, затем второй вносит изменения, и по недосмотру затирает изменения первого программиста. Объект же свободен, а то, что у него в копии была устаревшая версия - он и не знал.

(97) Вы (66) вообще читали?

(0) сегодня вроде не первое апреля

(98) а причем здесь хранилище?

(98) походу кто-то тут не представляет, как работает хранилище )

(97) не верю...

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

(103) за 8 лет работы лично у меня было ровно одно падение хранилища(восстановили из бекапа) и пара тройка проблем с данными, но только по моей или еще чьей нибудь глупости...
Рил ток, синк эбаут ит xD

(103)

Если будут технические проблемы я думаю надо проинформировать 1с, я не думаю что они Ваши проблемы не решат.

У меня лично проблем не было.

А так и базы бывают падают. Бэкапы никто не отменял.

(103) На 8.1 и 8.2 регулярно были такие проблемы с выходом из строя хранилища. На 8.3 уже несколько лет работаем и (тьфу тьфу тьфу) никаких проблем с потерей данных или выходом из строя базы хранилища не было.

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

Выполнить(СтрокаВ10кб) ??

(107) тип того.

(0) Давай познакомимся) Я тебя буду оберегать, и будем учиться друг у друга;)

(109) я все думал, как скоро появится пикапер который глянув на фоточку тс начнет ее клеить.

(110) Красивые и умные девушки прекрасны! Особенно если она еще программист)

А по теме, я лично работаю в тестовых конфигурациях, и потом обновляю при помощи Сравнить/Объеденить

(96) как, как, вот так Коллеги, осторожно, версия 8.3.10.2580

Но от хранилища подключенного к рабочей отказываться не хочется, так как если руки прямые + сама 1С не глючит, это крайне удобно. Проверено годами. Заморачиватся с поставкой какой смысл, если ты конфигурации для своей конторы пишешь ?

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

(114) да, да, да, конечно.
Еще git поднять, сервер сборки, сервер тестирования, сервер публикации релиза...

(0)
1) работать в рабочем конфигураторе моветон.
2) разрабатывать на разработческой
3) тестировать на тестовой.

(114) 2 раза на грабли наступал при динамическом обновлении.
Больше не охото, работа становилась на пару часов пока чинил.
Если ляжет порвут первые это бухи, потом и другие подтянуться.
Лучше используйте регламентный час, для обновления и разработку вести на сервере разработчиков, чтобы не мешать пользователям.
На боевом серваке тестить тоже зло, не есть хорошо.

(101) Читаем (66) до просветления. Подсказка: где будет храниться недоделанный функционал, и как будет обеспечиваться актуальность этого места.

(102) У вас же недоделанное хранится не в хранилище. Забыли уже?

(107) Можно внешней обработкой.

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

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

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

Но все же, тут нужно выбирать по ситуации, если 30 баз и в каждой по 1-2 пользователя работает, пожалуй можно и подключить. Если одна база на 300 пользователей и 500 гиглв, наверное лучше не рисковать, баги бывают. И т.д. ...

(120) Для групповой разработки норм, но не для того чтобы внести изменения и обновить потом основную

(122) основную одну ? а если их 30 или 50 ? Гораздо быстрее через хранилище. Повторюсь, вся проблема вопроса "использовать или не использовать хранилище с рабочей" исключительно из-за того, что хранилище работает через раз)))) И в этом вина не программиста 1С, а программиста С++ написавшего хранилище. В остальном, проблем не вижу. Если релиз платформы стабильный, то проблем не вижу.

Вот тут пишут о работе 15 программистов в одной базе. Один программист во многих базах это почти везде и это понятно. А что делают 15 программистов в одной базе? Что за задачи они решают? (мне просто интересно для себя)

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

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

(124) А что такого? Представь внедрение УТ11 на овер 300 пользователей: там продажи (возможно розница), маркетинг, закупки, склад, фин отдел. Не говоря уже про обмены с сайтами, бух и проч.

Сам не работал, но слышал, что ПЭКе овер 20 прогов)

(126) +100500

(126) на РИБе из кабака в ночь на понедельник

(127)Смешно:) С каких пор функционал для 10 или для 300 пользователей разный стал?:) Ну 2 прога на допилку функционала, 1 на обмены, ну если очень захотеть то 2 - остальным то что делать?

(119) А зачем ему их захватывать? Он в своей копии делает все, прежде чем вносить изменения в хранилище. Там этого управления тупо нет.

А как вы без хранилища (если это зло и фи-фи-фи у вас) смотрите историю изменения объекта в конфигурации? +100500 cf'ников сравнивать между собой? Им какие-то еще видимо имена нужно давать соответствующие типа cf_22_10_217?

Мне правда интересно, как без хранилища можно жить, при этом иметь историю изменений конфы?

Кажется, слухи о смерти хранилища сильно преувеличены.

(133) Классическим велосипедом они пользуются - комментариями в коде. Что данный фрагмент изменил Петров Вася 12 апреля с 42 размером ноги. Вот тут начал, а вот тут прекратил. Предыдущая версия кода трогательно комментируется блоком. И так раз 10...
При этом всем возмущенно рассказывается, что эта зелёная плесень в коде очень сильно помогает.

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

(39) "Лет 5 назад, когда на фикси работал, подключал хранилище к рабочей УТ. Иногда ВДРУГ пропадали внесенные ранее в рабочую изменения. С третьего раза я все понял и далее рабочую обновлял только через cf." - я вот с третьего раза понял, что надо сперва последнюю версию из хранилища получить и уже ее ковырять. А изменения ВДРУГ пропадают обычно потому, что вносишь их не в последнюю версию конфигурации

(98) "2 программиста в своих базах правят один объект" - если один прогер захватил объект в хранилище, второй его редактировать не сможет

Это больше вопрос религии

(137) А теперь читаем (66).

(131) Мне тоже смешно тебя читать) Ларечник детектед

140 постов, и 140 мнений.
Резюме: разрабатывайте, как вам удобно, а уж жизнь откорректирует вас, с вашим методом, как ей нужно.

(141) когда "без_хранилищники" ответят на (133) тогда и разговор будет. Пока ответа нет. Его кстати и не будет. Но само решение, конечно же, есть. Но оно по трудоемкости в разы (если не в десятки раз) сложнее, чем с хранилищем. А эти разговоры - рабочую базу не подключать к хранилищу, имеют место быть очень давно, с момента изобретения оного. Однако если вы не разработчик типовой и отраслевой, то подключение хранилищу рабочей базы, единственно простой и быстрый способ обеспечить коллективную разработку с последней редакцией конфы. Про всякие новоделы аля гит и прочее мы сейчас пока умолчим.

Админ твой прав , в тестовом работай.  а после ухода всех сотр домой вноси изменения в рабочую ,не забудь архив копии делать

я динамически вношу изменения в базы , у бухов вылетает окошко обновить .их это достало особенно в период сдачи отчетности

(133)Бекапы перед внедрением все равно делаете, вот вам история на крайний случай. Но как правило никакой истории изменений не надо.

(142) Да никто не отказывается от хранилища, вопрос только в подключении его к прод

(142) что мешает вести коллективную разработку в хранилище, не подключенном к проду?

(140)Так что ж делают остальные?

(148) Не поверишь, но разрабатывают. Про внедрение в (127), конечно бред написан, но полно нетиповых или отраслевых конфигураций, в разработке которых участвует целый отдел программистов. Лично работал с конфой, где было 6 разработчиков, и это была не сильно большая контора.

(148) 3-5 на упр учет/(5-15) если производство
+2-5 регл учет+ 2-3 на обмены+ поддержка 1линия отдельно. +РП, бизнес-аналитик, архитектор, эксперт по тех части(это разные люди).
в вашем примере 10-300 юзеров фиксированная по количеству человек в отделе разработки остается только часть кроме разработчиков. по мере усложнения системы, нужно расширение именно в количестве рабочих рук.

(149) Да ладно? И в чем бред? Я послушаю и приведу пример тебе на 10 разработчиков в УТ

(149) Оптовая/розничная торговля автозапчастями, 11 магазинов + бэк, все в одной базе, 700+ активных подключений (ну по крайней мере на момент ухода), 250 000 позиций номенклатуры:

Розинца - 1, Продажи - 2, Закупки - 1, Склад - 1, Бух/Фин - 1, Обмены/выгрузки сайты/бух/антор/WMS/проч - 2, Логистика/Обеспечение - 1, ведущий (в основном постановщик/производительность) - 1

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

Не показательно конечно, но вот столкнулся я в этом году по совместной работе с организацией, в которой сидит около 8 прогов в одной базе. Это просто фиаско. каждый знает какой-то кусок в базе и когда возникает вопрос апгрейда - вместо 15 минут неделю решают как дорабатывать функционал, про скорость доработок я уже молчу. В итоге они в 8 человек работают в раз 100 медленнее и совсем не качество чем я один. Но как я сказал это совсем не говорит о том что много прогов в одной базе это точно будет плохо. Интересно узнать как без кучи прогов не обойтись в одной базе.

+(153)Точнее в каких базах и при каких задачах необходимо много прогов?

(152)Это переход с одной конфы на другую?

(151) Бред в том, что разработка и внедрение готового продукта несколько разные вещи. Для ВНЕДРЕНИЯ типового решения разработчики не нужны, нужны внедренцы. И их количество не зависит от количества пользователей базы.
Другое дело - доработка типовой. Но тут опять же - количество разработчиков никоим образом не зависит от количества пользователей в базе. Поэтому я и написал, что фраза "внедрение УТ11 на овер 300 пользователей" - бред, т.к. к количеству разработчиков они никоим образом не относится.

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

(154) В основном в самописных или в сильно переработанных типовых (где типовая была взята лишь за основу). И это, как правило, не БП и не ЗУП, и обычно про обновления от поставщика в таких конфах можно забыть, т.к. в них идёт постоянная доработка.

(156) пфф, назови г0вно-розой пахнет все равно г0вном, речь шла о количестве программистов (ок, пусть внедренцев). От пользователей базы зависит косвенно, как правило, чем больше пользователей - больше и сложнее бп и больше хотелок.

(155) изначально да, с аксесса, древнейшего и кучи баз

(156) Опять же от количества пользователей зависит производительность, иногда чела выделяют, иногда бегут к Гилеву

(159) Да не зависит от кол-ва пользователей. Совсем. У нас была своя разработка на основе одной отраслевой конфы (перепиленная на 90%). Когда добавилось ещё несколько филиалов, для нас абсолютно ничего не изменилось - в новых филиалах те же самые бизнес-процессы. И кол-во программистов зависит не от количества УЧАСТНИКОВ бизнес-процессов, а от количества САМИХ бизнес-процессов.

(161) "иногда чела выделяют, иногда бегут к Гилеву" - Такой человек называется сисадмин, и к программистам, а тем более к конфигураторы не имеет отношения.
Конечно, если вы используете запросы в цикле, то вам и отдельный программист на оптимизацию кода будет нужен :))

(159) "чем больше пользователей - больше и сложнее бп" - А вот и нет. 1 человек вполне может выполнять сложный бизнес-процесс, а 100 - простейший. Никакой зависимости тут нету.

(162) 5 и 1000 одно и тоже?

Я же написал тебе зависит от кол-ва пользователей 1.Производительность
2.Косвенно зависит, тк увеличивается объем хотелок и сложнее БП

(163) БУ_ГА_ГА, это называется "Эксперт по тех вопросам"

(164) Мля, в ларьке один чел и закупщик, продажник и логист.

(164) Кароче еще один ларечник детектед

(163) походу запросы в цикле - это все, что ты знаешь о проблемах с производительностью? А про проблемы с параллельностью не слышал? А что такое ЦУП, сервисы Гилева для чего?

(168) + это тоже должен админ уметь?

(167) Конечно ларёчник. Только вот пока доводилось работать в ларьках от 1,5 тысяч человек численностью и более. :)))
Но ты видно в более крупных корпорациях работал, куда уж мне :))

(168) Распараллеливание в несколько фоновых заданий проведение по партиям - это тоже к админу?

(170) Да-да-да, по диалогу заметно сразу))))

(168) " А что такое ЦУП, сервисы Гилева для чего?" - По мне, так бесполезная фигня это. Мы как-то и без них обходились прекрасно. Но кому-то, возможно, не хватает умения без этого обойтись.

(173) без комментариев, с тобой все понятно =)

(174) Если ты не можешь обойтись своими силами и знаниями без Гилёва, это не значит, что он жизненно необходим всем :)))

(175) Ты просто не сталкивался с проблемами крупных внедрений

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

(176) Сталкивался, и вполне успешно решали их самостоятельно. Без привлечения сторонних "оптимизаторов" типа Гилёва. Рекомендации его, конечно изучали, для общего развития, но далеко не всё из его рекомендаций для нас были новостью.

(177) Открою тебе ещё один секрет: для увеличения производительности системы тоже не надо увеличивать штат программистов. Достаточно повышать квалификацию существующих :)))

(178) Мля, да без ЦУПа и сервисов невозможно решить проблему с параллельностью

(180) Правда что ли? Ты серьёзно? А как по-твоему, их решали ДО появления ЦУПа? :)))

(179) Причем тут это? Представь есть задачи, под них выделено X программистов. Всех все устраивает, но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это

(181) Другими инструментами. А если про 1с, то раньше она и поддерживала такие объемы, как сейчас

(182) При том, что разговор изначально шёл о необходимости работы нескольких программистов в одной конфигурации. И не более.
" но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это" - Опять неудачный пример. Такие проблемы надо решать максимально быстро, а новому человеку понадобится время на изучение. Не взлетит.

(181) Не ну конечно, если ты эксперт по скл, то тогда тебе они не нужны, но я что-то в этом сомневаюсь

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

(185) Сомневайся. И да, я не эксперт по СКЛ, но работал в команде, где таковые присутствовали.

(186) Ну конечно, я ничего не понимаю. У тебя же всё просто: чем больше штат программистов, тем выше производительность. Придёт новый "варяг" и всё тут же поправит, не вникая. У нас таких "спецов" даже на порог не пускают :))

(182)Наверное надо дать задание на переделку тому кто недодумал или скосячил. А смысл нанимать нового прога, которого нанимать может пол года будете, потом пока он въедет во все еще пол года. лучше дать текущему чтоб за час ну или день разобрался и поехали дальше клепать новые задачки.

(188) Ты перевираешь смысл моих слов. Я говорил, что от количества активных подлкючений прямо и иногда косвенно зависит количество требуемых программистов

(189) Если проведение по партиям - это типовой механизм и виновных нет? Просто он перестал за ночь выполняться

(189) Поверь мне, не все программисты могут оптимизировать свой код, я те, кто могут справедливо хотят за это больше денег. Посмотри сколько спецов по платформе и сколько экспертов, это не зря так

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

(193) Я тебе ответил на это уже

(194) Ах, да. Я и забыл, что говорю с экспертом мегакорпораций. У нас, ларёчников, как-то проще всё. А главное, не раз проверено на практике и работает в жизни, а не в теориях :))

А как обновлять? Нетиповая конфа, днем в ней больше 100 юзеров. Когда её обновлять?

(196) Ночью/вечером, вестимо.

Хранилище по факту всем хорошо и удобно, кроме двух пунктов.
1) Файловый вариант может повреждаться. И в моей практике несколько раз было потеря изменений, а один раз даже повреждение конфигурации, что при получении изменений из хранилища в базе повреждалась конфигурация. Лечилось пересозданием хранилища.
2) Если брать более надежный вариант с серверным хранилищем, то начинается проблема с платформами. Что если тестовый сервер решили поднять на платформу повыше, чтобы протестировать поведение базы на новой платформе, то вы уже к хранилищу не подключитесь. Ибо несоответствие версий.

Но как бы альтернатив хранилищу я все равно сейчас не вижу. Обновление cf-ником сейчас уже выглядит настолько топорно и неудобно, что чур-чур-чур.

(191)Тогда весь ваш отдел нафиг не нужен:) Вся ваша работа ради того чтоб работал партионный учет в первую очередь.
(192)Это не программисты.

В общем итог таков:
Хранилище - для студентов.
Наняли 15 студентов, посадили их за компы, поставили над ними руководителя, подрубили их к хранилищу, что б они своими корявыми руками друг другу работу не портили и вперед. И сидят они по 10 раз одно и тоже переделывают, т.к. опыта нет и дальновидность страдает. Если что, как нам сказали, при доп проблемах быстро нанимается еще один прог: норм прога фиг найдешь, а студента конечно быстро и по той же схеме вперед.

Если говорить о написании функционала, то вот это все "Розинца - 1, Продажи - 2, Закупки - 1, Склад - 1, WMS, Логистика" программирует один человек, максимум под wms можно выделить еще одного. Вы задумайтесь где ларек, а где нет.

На предприятиях не возникает с такой скоростью количество задач, чтоб загрузить 15 программистов. Это образно каждый день надо требовать по 2-3 абсолютно новых отчета или новый документ.

200

+(199)"Это образно каждый день надо требовать по 2-3 абсолютно новых отчета или новый документ" Уточню: для каждого. Т.е. через пару недель, на новую конфу с нуля наскребут.

(163) 1С использует запросы в цикле. посоветуй ей отдельного человека на оптимизацию нанять.

(199) поржал, спасибо

(201) "каждый день надо требовать по 2-3 абсолютно новых отчета " - Ты исходишь из того, что потребуют новый отчет по данным, которые ИМЕЮТСЯ в программе. А если потребуется отчёт, под который ещё надо данные (со всеми вытекающими) создать? :))

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

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