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

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

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