Имя: Пароль:
   
1C
1С v8
работать в тестовом или в рабочем конфигураторе?
0 ASimonova
 
23.10.17
10:44
у нас скульная база с 10-20 постоянно рабочими пользователями. я программист, всегда работала в рабочем конфигураторе, потом в конце рабочего дня принимала все изменения. переехали на новый сервер, появились ошибки СУБД, теперь админ мне говорит, что так нельзя и надо работать в тестовом конфигураторе, а рабочий вообще не открывать пока пользователи в базе.
у меня очень много мелких изменений, в т.ч. в структуре баз данных, так что временно'й целесообразности в этом нет: принятие этих изменений в рабочем конфигураторе займет столько же времени сколько и в тестовом. насколько прав наш админ? действительно все работают в тестовом несмотря ни на что?
1 ASimonova
 
23.10.17
10:52
(0) к слову сказать админы сервера говорят, что ошибки СУБД из-за 32-х битной версии скуля, и им я верю больше.
2 Sserj
 
23.10.17
10:54
Все 1С-ники делятся на 2 группы. Которые уже убивали свои базы и те которым это еще предстоит
:)
3 Numerus Mikhail
 
23.10.17
10:55
Работать в рабочей базе - зло.
4 spock
 
23.10.17
10:56
Программировать на 'бою' - это фиаско, братан.
5 FormatC
 
naïve
23.10.17
10:57
а как тестировать свои доработки? конечно нужна тестовая база
6 VladZ
 
23.10.17
10:58
(0) Тестовая база нужна тебе, юный падаван!
7 1dvd
 
23.10.17
10:59
в крупных конторах прог не имеет доступа в бобевую
8 Jonny_Khomich
 
23.10.17
10:59
(6) "База нужна тебе тестовая" так правильнее
9 ASimonova
 
23.10.17
11:01
всем спасибо, все понятно)))
10 ASimonova
 
23.10.17
11:01
а если я буду в конце дня не принимать миллион мелких изменений в рабочую а просто буду сверху конфу накатывать из тестовой, так делается?
11 1dvd
 
23.10.17
11:03
(10) не возражаем
12 Timon1405
 
23.10.17
11:03
почитайте про разработку через хранилище
13 h-sp
 
23.10.17
11:04
(8) всё-таки быстрее тренироваться на кроликах
14 ASimonova
 
23.10.17
11:05
(12) насколько я знаю, тестировать предприятия через хранилище нельзя, так ведь?
15 d4rkmesa
 
23.10.17
11:05
(10) Обычно делается - в простом случае все изменения разрабатываются в тестовой и помещаются в репозиторий (хранилище), откуда потом все вместе забирается в рабочую базу. Если все сложнее, и рабочая не подключена к хранилищу, в режиме сравнения-объединения свои изменения переносите в рабочую.
16 Numerus Mikhail
 
23.10.17
11:06
(14) Что значит нельзя? Все можно, почитайте про это сначала.
17 Ёпрст
 
23.10.17
11:06
(14) неправильно понимаешь
18 ASimonova
 
23.10.17
11:11
(12) (15) (16) (17) спасибо, подключаю хранилище
19 Wirtuozzz
 
23.10.17
11:15
(0) Вам перед рабочим днем не выдают полотенце с красным кругом?

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

В рабочем конфигураторе даже отладки не должно быть. Должна быть только возможность обновить конфу из хранилища. Все остальное в тестовой базе.
20 vde69
 
23.10.17
11:16
(19) эммммм... отладка в рабочей иногда нужна, а вот хранилище к рабочей подключать - верный путь к геморою....
21 mehfk
 
23.10.17
11:18
(20) >> вот хранилище к рабочей подключать - верный путь к геморою
Почему?
22 Wirtuozzz
 
23.10.17
11:18
(20) У нас нет в рабочей отладки, есть свежий бекапчик, при необходимости бекап заливается в скульную тестовую базу. Почему подключать хранилище к рабочей - гемморой? чем это черевато и как вносить доработки, через CF?
23 Fish
 
23.10.17
11:18
(20) При грамотном использовании никакого геморроя.
24 Wirtuozzz
 
23.10.17
11:19
(23) какое использование не грамотное?
25 vde69
 
23.10.17
11:20
(22) иногда ошибки проявляются ТОЛЬКО при работе на боевой, например всякие обмены и прочее....

(21) по тому, что есть шанс накатить что-то не оттестированое, но уже положенное в хранилище
26 1dvd
 
23.10.17
11:20
(20) +100500
27 DexterMorgan
 
23.10.17
11:22
(20) +100
28 mehfk
 
23.10.17
11:22
(25) >> есть шанс накатить что-то не оттестированое, но уже положенное в хранилище
Какая разница - попадет это в боевую базу напрямую из хранилища или через промежуточный cf?
29 Wirtuozzz
 
23.10.17
11:24
(25) А зачем что то не оттестированное убирать в хранилище? Что может это заставить сделать?
30 DexterMorgan
 
23.10.17
11:25
(28) Ну как бы при сравнении объектов, видно, что какой-то удак добавил реквизит в РТУ, а база на Овер 400ГБ и рту хренова туча и реструктуризация за ночь не пройдет,ну типа как пример
31 DexterMorgan
 
23.10.17
11:25
(28) Точнее это нагляднее все
32 Wirtuozzz
 
23.10.17
11:26
(31) понял.
33 vde69
 
23.10.17
11:27
(29) например я добавил объект а нужная роль захвачено другим разработчиком, я кладу свой объект и говорю, что бы тот включил ее в роли... А роли в конфу не кладут, так там еще много работы.

в данном случае в рабочую конфу попадет объект без прав...
34 Сияющий в темноте
 
23.10.17
11:33
сложно представить,что попадёт в базу при такой работе,нсли нет хранилища
35 DexterMorgan
 
23.10.17
11:36
(34) Никто не против хранилища, это отличный инструмент, просто есть мнение, что не нужно подключать его к рабочей базе
36 Heckfy
 
23.10.17
11:40
По хорошему, прод для разработки вообще должен быть не доступен. Должны быть подняты среда для разработки/тестовая среда/сертификационная среда. Релиз документируется и передается админам для установки в прод.
Как то так, если коротЕнько.
37 1dvd
 
23.10.17
11:41
(36) +1
38 Лефмихалыч
 
naïve
23.10.17
11:43
(0) в приличном обществе за такие фокусы по щекам хлещут
39 Fuas4
 
23.10.17
11:43
Поддержку (35) Лет 5 назад, когда на фикси работал, подключал хранилище к рабочей УТ. Иногда ВДРУГ пропадали внесенные ранее в рабочую изменения. С третьего раза я все понял и далее рабочую обновлял только через cf. Сейчас может и починили хранилище, но я не проверяю
40 Мимохожий Однако
 
23.10.17
11:44
Работать и отлаживать надо тестовой. Остальное по вкусу.
41 Dmitrii
 
23.10.17
11:45
(33) И как эта проблема решается, в условиях, когда боевая база НЕ подключена к хранилищу?

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

Пример надуманный и никак не связан с вопросом подключения продуктива к хранилищу.
42 Джинн
 
23.10.17
11:47
(0) Разрабатывать в рабочей базе - извращение в принципе.
43 Лефмихалыч
 
naïve
23.10.17
11:49
(35) +9000! Рабочую базу нельзя к хранилищу подключать.
Рабочая база должна обновляться комплектами поставки, выгружаемыми из пустой базы, подключенной к хранилищу.
44 la luna llena
 
23.10.17
11:50
(0) вы и отлаживаете в рабочей базе?
о_О
самоубивцы
45 dmpl
 
23.10.17
11:53
(30) Это про текст электронного чека история?
46 d4rkmesa
 
23.10.17
12:17
(44) Иногда, когда нет выбора, не грех и к рабочей подключиться, если база сравнительно небольшая (<200 пользователей). Конечно, за блокировку транзакций пользователям нужно на месте руки отрывать.
47 Alligator219
 
23.10.17
12:19
(39) У многих была такая проблема. Очень многих.
48 Веселый собака
 
23.10.17
12:23
(43) Можно. И нужно.
Главное, в ней отладку не делать.
Всегда есть две конфигурации в любой базе- хранилища и собственно бызы. И они не пересекаются, пока не применишь изменения.
49 ptiz
 
23.10.17
12:28
С таким уровнем вопросов, как у автора, и "миллион мелких изменений в рабочую" - мне страшно за базу!
50 dmpl
 
23.10.17
12:28
(48) Предлагаешь изменения без тестирования применять? Круто, чо.
51 Лефмихалыч
 
naïve
23.10.17
12:29
(48) обновление из хранилища может создать два объекта с одним имемем, регистр без регистратора и прочие подобные штуки, от которых конфигурация станет неконсистентна, и это - вполне штатная ситуация.
Подключать рабочую базу к хранилищу - плохая затея.
52 aka AMIGO
 
23.10.17
12:29
(50) Можно и в рабочей тестировать. Только выгнать всех из базы, пусть пока чайку попьют, покурят.. или уж пообедают, пока 1с-ник тестит базу :)
53 Веселый собака
 
23.10.17
12:33
(50) Блин, написал, же, тестирование- в тестовой базе.
54 Лефмихалыч
 
naïve
23.10.17
12:36
(52) нельзя такое делать. Это прямая дорога к потерям данных и затяжным авариям. Добродетельные люди так не делают и уж тем более ни кому не рекомендуют так делать.
55 Веселый собака
 
23.10.17
12:37
(54) А вот с этим соглашусь.
56 dmpl
 
23.10.17
13:01
(53) И смысл тогда хранилище к рабочей подключать?
57 Fuas4
 
23.10.17
13:05
(47) Починили ее уже?
58 Alligator219
 
23.10.17
13:18
(57) Как-то не тянет проверять)))
59 Heckfy
 
23.10.17
13:21
ИМХО, рабочую можно на свое хранилище посадить. Так, для информации, какие изменения и когда накатывались. Плюс, какая никакая защита от дурака. Что бы что то поправить, захват их хранилища нужно делать.
60 Segate
 
23.10.17
13:30
В хранилище всегда должна быть актуальная конфа. тогда проблем не будет xD
Но вообще обновлять лучше из поставки.
61 Лефмихалыч
 
naïve
23.10.17
13:32
(59) для этого поставки придуманы
(60) "В хранилище всегда должна быть актуальная конфа" - а работать программистам где? В базе, не подключенной к хранилищу?
62 ИС-2
 
naïve
23.10.17
13:33
(0) крута, раз умудряешься делать без отладки и тестировки.

База не может падать из-за того, что открыт конфгуратор
63 Лефмихалыч
 
naïve
23.10.17
13:35
(62) может. Например, на блокировках, если программист (или лицо, им прикидывающееся) грамотно остановится отладчиком внутри транзакции проведения документа
64 Heckfy
 
23.10.17
13:37
(61) Можно и поставками. Но, я бы, наверное, еще и хранилище прилепил.
(63) Ну, это будет не "падение базы". :)
65 Веселый собака
 
23.10.17
13:39
(56) Смысл подключения рабочей базы к хранилищу
1. в быстром применении конфигурации хранилища после тестирования в тестовой
2. база хранилища однозначно коррелирует по содержимому конфигурации с рабочей, т.к. ею порождена.
66 Segate
 
23.10.17
13:39
(61) ну какбэ а в чем проблема? недоделанный функционал в хранилище не выкладывается. и все ок
67 ptiz
 
23.10.17
13:40
Как обычно в таких фирмах на 20 юзеров - считают, что выросли из коротких штанишек, и начинают программу дорабатывать, причем "срочно". Если до завтра кнопочку или отчетик не сделаешь - прям умрут все, не иначе!
68 Веселый собака
 
23.10.17
13:42
(66) Я больше скажу ;)
Если передумал что-то менять, сделай отмену захвата объекта в хранилище и все станет как было.
69 Веселый собака
 
23.10.17
13:43
(67) Марь иванна отлучит от печенюшек и сошлет заправлять картриджи.
70 Лефмихалыч
 
naïve
23.10.17
13:43
(66) когда программистов больше одного, это перестает работать. Да и изменения можно тупо потерять из-за каких-либо технических проблем на компе программиста, если оные изменения не отправлять своевременно в хранилище. Для одиночки - вариант, но и тут, если тебе надо хотфикс выпустить здесь и сейчас к объекту, надо которым у тебя затяжная разработка, то - всё, пипец, сливай вАду.
71 AlfaDog
 
23.10.17
13:49
(66) +1

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

(70) Если не умеете работать по данной схеме не пишите , что это не работает. Отлично работает, если руки прямые.
72 Segate
 
23.10.17
13:49
(70) ну хз... работал в команде из 50+ программистов в одном хранилище и ничего=) просто надо соблюдать правила, коментировать что выкладываешь и не захватывать лишнего
73 Лефмихалыч
 
naïve
23.10.17
13:51
(72) и прод был подключен к этому хранилищу?
74 Segate
 
23.10.17
13:52
(72) прод обновляли поставкой, но база донор была подключена к нему
75 Лефмихалыч
 
naïve
23.10.17
13:54
(74) так и ну о чем ты тут тогда рассказываешь? 50+ и не было проблем... В этом я и не сомневаюсь. Речь-то про другое немного.
76 Лефмихалыч
 
naïve
23.10.17
13:54
(74) см (43) про поставки
77 Segate
 
23.10.17
13:54
(75) про что все таки речь-то? Расскажи нам )
Я сразу написал. что лучше обновлять поставкой, но если руки из нужного места, то и из хранилища обновлять можно. это не проблема.
78 Segate
 
23.10.17
13:57
(76) скажем так, опиши кейс, когда подключение рабочей к хранилищу влекло за собой потерю данных в рабочей базе, ну или хотя-бы маломальские глюки не из за кривизны рук программеров, а из за специфики работы с хранилищем
79 Лефмихалыч
 
naïve
23.10.17
13:58
(77) я уже рассказал - (70).
Когда изменения в хранилище помещаются ТОЛЬКО протестированные и уже готовые к релизу, тогда выпуск хотфиксов к объектам, над которыми ведется разработка, не возможен. Либо - это откатить нафиг все разработки, выпустить хотфикс и потом натягивать результаты разработок обратно.
80 Лефмихалыч
 
naïve
23.10.17
14:01
+(79) опять же - разделить работу над связанными объектами между несколькими разработчиками нельзя в этом случае: ты новый объект и любые изменения не можешь поместить до завершения всех тестов. Например, поручить разработку UI и печатных форм по ТЗ падавану, а самому заняться проведением, ты уже не сможешь, т.к. в хранилище недоделанный документ нельзя слить. Ну, или он попадет в продуктив недоделанным, а там могут, например, отчеты обсыпаться изза недоастатка прав или - обмены колом встанут. Да мало ли.
По этому я и говорю - для одного программиста эта схема прокатывает. Даже для пятидесяти одиночек прокатывает. Но командной работы не будет.
81 Лефмихалыч
 
naïve
23.10.17
14:04
не гвооря уже о том, что при коллективной разработке в данном случае может случиться ситуация, при которой Вася ждет Петю, а Петя - Васю и оба сидят, курят бамбук, два не связанных пользюка не закончат тесты, хотя могли бы сложиться в хранилище и работать спокойно дальше.

Одно хранилище - это для одиночек. Подключать прод к хранилищу - для любителей аквалангов и гамаков.
82 Heckfy
 
23.10.17
14:04
(80) Присоединюсь к коллегам: Вы просто не умеете их готовить!
Из личной практики, у меня отдел разрабов 1С (~15 человек) отлично через хранилище работали.
А вообще, см. (36)
83 Лефмихалыч
 
naïve
23.10.17
14:07
(82) Какое отношение эта сентенция ко мне имеет? Где я сказал, что с хранилищем плохо?


с (36) полностью согласен.
84 Лефмихалыч
 
naïve
23.10.17
14:10
я говорю о том, что (66) препятствует командной разработке.
85 Segate
 
23.10.17
14:11
(79) кстати интересная тема.
на самом деле все не так страшно как кажется. Во первых у нас был механизм замен. т.е. без обновления в режиме предприятия можно было поставить под замену(изменить текст выполняемого кода) любую процедуру, любую форму. это покрывает 99% всех потребностей.
И ситуация когда для разработки разного функционала требуется, допустим, один и тот же объект.довольно редка, и скорее находится в области правильного распределения задач, нежели в области непосредственно разработки. Но при возникновении подобных ситуаций(допустим необходимость использования одного общего модуля) всегда можно экранировать свой код в хранилище и отпускать объект. Это не так уж и сложно.
86 Лефмихалыч
 
naïve
23.10.17
14:15
(85) ну, эти подмены - это костыль, согласись?

Да и задачи могут быть распределены идеально, но пользователи здесь и сейчас нашли багу в существующем давно объекте, надо которым сейчас работают программисты, и вот этот баг болит и мешает ходить. Да, это не часто. Но, когда случается, приходится сохранять конфу рзработчика в файл, отменять захваты, выпускать хотфикс, пото сравнением-объединением натягивать конфу разработчика из файла. Тягомотина та еще.
87 Лефмихалыч
 
naïve
23.10.17
14:16
отклонились насовсем от темы. Автору до таких материй еще очень далеко. Если вообще - когда-нибудь...
88 Segate
 
23.10.17
14:20
(85) костыль, но он решает кучу проблем разом. Поправить багу в процедуре без обновления, поправить багу на форме без обновления... крайне удобно. единственное, что нельзя поправить - это изменять данные типа нельзя увеличить длину наименования объекта например... Но это уже очень редко идет под названием баг, а скорее хотелка, и она записывается в план на следующее обновление...
89 aka AMIGO
 
23.10.17
14:28
(54) Знаю яааа!! :)
Естественно, надо всё делать в локальной
В конфигуратор рабочей БД надо лесть только для обновления своими нетленками..
Да и то - после непременного бэкапа..
90 aka AMIGO
 
23.10.17
14:31
ЗЫ. для 7-ки, кто помнит, была TurboMD.dll, позволяющая динамически обновить БД.
Молодцы были создатели, ребята, думающие и делающие правильное дело..
91 Segate
 
23.10.17
14:50
(87) по теме автора то сказать нечего.

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

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

(66) Потом будут пропадать изменения, сделанные другими программистами.
93 Lama12
 
23.10.17
15:00
Все не читал. Судя по всему, ошибки не из-за конфигуратора. Хотя это не корректно. Пусть лучше админы настраивают скуль правильно. И вообще, 32 разряда для СУБД сейчас, это мовитон.
94 Segate
 
23.10.17
15:05
(92) работаю с хранилищем уже почти 8 лет, ни разу без логики ничего не пропало. ЧЯДНТ?

Была пара раз, когда при нарушении связи с хранилищем все синхронизировалось, но и тогда можно было просто сохранить цф до обновления, и потом сравнить-объеденить и ничего не потерять.
95 dmpl
 
23.10.17
15:13
(94) Оно с логикой пропадет, потом весь отдел депремируют. Легче станет от того, что логика была?
96 Segate
 
23.10.17
15:19
(95) ну расскажи как? =) Я уже просил описать кейс, когда при нормальной работе с хранилищем пропадают изменения... мне пока никто не рассказал
97 AlfaDog
 
23.10.17
15:25
(86)


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

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



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

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

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

(92) За 4 года ничего не пропало у нас. Что мы делаем не так?
98 dmpl
 
23.10.17
15:26
(96) Очень просто. 2 программиста в своих базах правят один объект. Потом первый вносит изменения и разблокирует объект в хранилище, затем второй вносит изменения, и по недосмотру затирает изменения первого программиста. Объект же свободен, а то, что у него в копии была устаревшая версия - он и не знал.
99 dmpl
 
23.10.17
15:28
(97) Вы (66) вообще читали?
100 vi0
 
naïve
23.10.17
15:31
(0) сегодня вроде не первое апреля
101 vi0
 
naïve
23.10.17
15:32
(98) а причем здесь хранилище?
102 Segate
 
23.10.17
15:35
(98) походу кто-то тут не представляет, как работает хранилище )
103 vde69
 
23.10.17
15:39
(97) не верю...

не однократно встречал проблемы с хранилищем, даже на ровном месте, банально падает оно периодически при частом совместном использовании (как минимум раз в год его пересоздавать надо), а уж про "потеряли мои изменения" и не говорю, это вообще песня постоянная ...
104 Segate
 
23.10.17
15:40
(103) за 8 лет работы лично у меня было ровно одно падение хранилища(восстановили из бекапа) и пара тройка проблем с данными, но только по моей или еще чьей нибудь глупости...
Рил ток, синк эбаут ит xD
105 AlfaDog
 
23.10.17
15:42
(103)

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

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

А так и базы бывают падают. Бэкапы никто не отменял.
106 Smile 8D
 
23.10.17
15:44
(103) На 8.1 и 8.2 регулярно были такие проблемы с выходом из строя хранилища. На 8.3 уже несколько лет работаем и (тьфу тьфу тьфу) никаких проблем с потерей данных или выходом из строя базы хранилища не было.
107 akronim
 
23.10.17
16:05
(85) "без обновления в режиме предприятия можно было поставить под замену(изменить текст выполняемого кода) любую процедуру, любую форму"

Выполнить(СтрокаВ10кб) ??
108 Segate
 
23.10.17
16:08
(107) тип того.
109 _Дайвер_
 
23.10.17
16:12
(0) Давай познакомимся) Я тебя буду оберегать, и будем учиться друг у друга;)
110 Segate
 
23.10.17
16:13
(109) я все думал, как скоро появится пикапер который глянув на фоточку тс начнет ее клеить.
111 _Дайвер_
 
23.10.17
16:16
(110) Красивые и умные девушки прекрасны! Особенно если она еще программист)
112 _Дайвер_
 
23.10.17
16:18
А по теме, я лично работаю в тестовых конфигурациях, и потом обновляю при помощи Сравнить/Объеденить
113 Mr_Best
 
23.10.17
16:24
(96) как, как, вот так Коллеги, осторожно, версия 8.3.10.2580

Но от хранилища подключенного к рабочей отказываться не хочется, так как если руки прямые + сама 1С не глючит, это крайне удобно. Проверено годами. Заморачиватся с поставкой какой смысл, если ты конфигурации для своей конторы пишешь ?
114 Mr_Best
 
23.10.17
16:27
По моему опыту с хранилищем подключенным к боевой работать можно и нужно. Единственный риск - это кривые руки разработчиков платформы, из за которых хранилище может дать сбой как по ссылке выше.
115 sapphire
 
23.10.17
16:53
(114) да, да, да, конечно.
Еще git поднять, сервер сборки, сервер тестирования, сервер публикации релиза...

(0)
1) работать в рабочем конфигураторе моветон.
2) разрабатывать на разработческой
3) тестировать на тестовой.
116 spiller26
 
23.10.17
16:55
(114) 2 раза на грабли наступал при динамическом обновлении.
Больше не охото, работа становилась на пару часов пока чинил.
Если ляжет порвут первые это бухи, потом и другие подтянуться.
Лучше используйте регламентный час, для обновления и разработку вести на сервере разработчиков, чтобы не мешать пользователям.
На боевом серваке тестить тоже зло, не есть хорошо.
117 dmpl
 
23.10.17
17:05
(101) Читаем (66) до просветления. Подсказка: где будет храниться недоделанный функционал, и как будет обеспечиваться актуальность этого места.

(102) У вас же недоделанное хранится не в хранилище. Забыли уже?
118 dmpl
 
23.10.17
17:06
(107) Можно внешней обработкой.
119 Segate
 
23.10.17
17:08
(117) я помню =) и знаю что с конкретным объектом в один момент времени работает один программист. Он, по завершении кладет изменения в хранилище, следующий при захвате объекта получает эти изменения и продолжает разработку. не получить их он не может, это стандартная процедура при работе с хранилищем. и я не вижу в какой момент могут потеряться данные )
120 DexterMorgan
 
23.10.17
17:34
(119) Я точно не вспомню, но возникали проблемы при динамическом обновлении какой-то конфигурации (не рабочей) подключенной к хранилищу, приводящие к потере изменений. Как гарантировать, что какой-то программист не задинамится?
А нужно ли это вообще? Ну и опять же наглядность изменений при сравнении-объединении не бывает лишней никогда. В какой-то мере это частично решает проблему хотфиксов. Я честно не вижу плюсов подключения рабочей к хранилищу, вообще никаких, кроме некритичного увеличения скорости обновления
121 Mr_Best
 
23.10.17
17:42
(119) ну когда у тебя 30 баз однотипных, то падения скорости обновления + количество человеческого фактора без использования хранилища очень заметно возрастает.

Но все же, тут нужно выбирать по ситуации, если 30 баз и в каждой по 1-2 пользователя работает, пожалуй можно и подключить. Если одна база на 300 пользователей и 500 гиглв, наверное лучше не рисковать, баги бывают. И т.д. ...
122 _Дайвер_
 
23.10.17
17:42
(120) Для групповой разработки норм, но не для того чтобы внести изменения и обновить потом основную
123 Mr_Best
 
23.10.17
17:46
(122) основную одну ? а если их 30 или 50 ? Гораздо быстрее через хранилище. Повторюсь, вся проблема вопроса "использовать или не использовать хранилище с рабочей" исключительно из-за того, что хранилище работает через раз)))) И в этом вина не программиста 1С, а программиста С++ написавшего хранилище. В остальном, проблем не вижу. Если релиз платформы стабильный, то проблем не вижу.
124 DomovoiAtakue
 
23.10.17
18:05
Вот тут пишут о работе 15 программистов в одной базе. Один программист во многих базах это почти везде и это понятно. А что делают 15 программистов в одной базе? Что за задачи они решают? (мне просто интересно для себя)
125 DomovoiAtakue
 
23.10.17
18:23
К чему вообще приплели хранилище? ТС работает одна, зачем ей хранилище? Хранилище - глючная вещь и если у кого-то за его практику не было глюков, то просто повезло или у вас мало опыта, читайте мисту. Хранилище вообще ставят только студентам, профессионалы итак знают какие объекты им нужны будут и в чужие не полезут.
Кстати тут упоминали динамическое обновление - табу, может полететь база или побиться.
126 0xFFFFFF
 
23.10.17
18:33
(0) админ врет. В тестовой разрабатывают только трУсы, пороха не нюхавшие.
Настоящие мужики пишут сразу в боевой. Тем более когда очень много мелких изменений. Ну там реквизит добавить в справочник/рег сведений на пару миллионов строк или например расчет цен поменять - тестовая-шместовая - нафиг эти прослойки, долго это все.
Девиз настоящего одинэсника - куяк куяк и в продакшн.
Будьте смелее, не бойтесь своих желаний.
127 DexterMorgan
 
23.10.17
18:41
(124) А что такого? Представь внедрение УТ11 на овер 300 пользователей: там продажи (возможно розница), маркетинг, закупки, склад, фин отдел. Не говоря уже про обмены с сайтами, бух и проч.
128 DexterMorgan
 
23.10.17
18:46
Сам не работал, но слышал, что ПЭКе овер 20 прогов)
129 Mr_Best
 
23.10.17
18:48
(126) +100500
130 Йохохо
 
23.10.17
18:51
(126) на РИБе из кабака в ночь на понедельник
131 DomovoiAtakue
 
23.10.17
19:07
(127)Смешно:) С каких пор функционал для 10 или для 300 пользователей разный стал?:) Ну 2 прога на допилку функционала, 1 на обмены, ну если очень захотеть то 2 - остальным то что делать?
132 dmpl
 
23.10.17
20:35
(119) А зачем ему их захватывать? Он в своей копии делает все, прежде чем вносить изменения в хранилище. Там этого управления тупо нет.
133 Новиков
 
23.10.17
22:06
А как вы без хранилища (если это зло и фи-фи-фи у вас) смотрите историю изменения объекта в конфигурации? +100500 cf'ников сравнивать между собой? Им какие-то еще видимо имена нужно давать соответствующие типа cf_22_10_217?

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

Кажется, слухи о смерти хранилища сильно преувеличены.
134 Филиал-msk
 
23.10.17
22:29
(133) Классическим велосипедом они пользуются - комментариями в коде. Что данный фрагмент изменил Петров Вася 12 апреля с 42 размером ноги. Вот тут начал, а вот тут прекратил. Предыдущая версия кода трогательно комментируется блоком. И так раз 10...
При этом всем возмущенно рассказывается, что эта зелёная плесень в коде очень сильно помогает.
135 youalex
 
23.10.17
22:30
(0) Админ прав. Ты тоже - права. Но работать лучше в тестовой базе, изменения на рабочую накатывать с тестового сф-ника (как хороший вариант - через поставку из хранилища, к к которой подключена твоя тестовая база)
136 rudnitskij
 
23.10.17
23:28
(39) "Лет 5 назад, когда на фикси работал, подключал хранилище к рабочей УТ. Иногда ВДРУГ пропадали внесенные ранее в рабочую изменения. С третьего раза я все понял и далее рабочую обновлял только через cf." - я вот с третьего раза понял, что надо сперва последнюю версию из хранилища получить и уже ее ковырять. А изменения ВДРУГ пропадают обычно потому, что вносишь их не в последнюю версию конфигурации
137 rudnitskij
 
23.10.17
23:30
(98) "2 программиста в своих базах правят один объект" - если один прогер захватил объект в хранилище, второй его редактировать не сможет
138 jsmith82
 
24.10.17
00:07
Это больше вопрос религии
139 dmpl
 
24.10.17
08:13
(137) А теперь читаем (66).
140 DexterMorgan
 
24.10.17
09:26
(131) Мне тоже смешно тебя читать) Ларечник детектед
141 aka AMIGO
 
24.10.17
09:29
140 постов, и 140 мнений.
Резюме: разрабатывайте, как вам удобно, а уж жизнь откорректирует вас, с вашим методом, как ей нужно.
142 Новиков
 
24.10.17
09:33
(141) когда "без_хранилищники" ответят на (133) тогда и разговор будет. Пока ответа нет. Его кстати и не будет. Но само решение, конечно же, есть. Но оно по трудоемкости в разы (если не в десятки раз) сложнее, чем с хранилищем. А эти разговоры - рабочую базу не подключать к хранилищу, имеют место быть очень давно, с момента изобретения оного. Однако если вы не разработчик типовой и отраслевой, то подключение хранилищу рабочей базы, единственно простой и быстрый способ обеспечить коллективную разработку с последней редакцией конфы. Про всякие новоделы аля гит и прочее мы сейчас пока умолчим.
143 Шаман
 
24.10.17
09:57
Админ твой прав , в тестовом работай.  а после ухода всех сотр домой вноси изменения в рабочую ,не забудь архив копии делать
144 Шаман
 
24.10.17
09:59
я динамически вношу изменения в базы , у бухов вылетает окошко обновить .их это достало особенно в период сдачи отчетности
145 DomovoiAtakue
 
24.10.17
11:29
(133)Бекапы перед внедрением все равно делаете, вот вам история на крайний случай. Но как правило никакой истории изменений не надо.
146 DexterMorgan
 
24.10.17
11:32
(142) Да никто не отказывается от хранилища, вопрос только в подключении его к прод
147 DexterMorgan
 
24.10.17
11:33
(142) что мешает вести коллективную разработку в хранилище, не подключенном к проду?
148 DomovoiAtakue
 
24.10.17
11:38
(140)Так что ж делают остальные?
149 Fish
 
24.10.17
11:45
(148) Не поверишь, но разрабатывают. Про внедрение в (127), конечно бред написан, но полно нетиповых или отраслевых конфигураций, в разработке которых участвует целый отдел программистов. Лично работал с конфой, где было 6 разработчиков, и это была не сильно большая контора.
150 Timon1405
 
24.10.17
11:57
(148) 3-5 на упр учет/(5-15) если производство
+2-5 регл учет+ 2-3 на обмены+ поддержка 1линия отдельно. +РП, бизнес-аналитик, архитектор, эксперт по тех части(это разные люди).
в вашем примере 10-300 юзеров фиксированная по количеству человек в отделе разработки остается только часть кроме разработчиков. по мере усложнения системы, нужно расширение именно в количестве рабочих рук.
151 DexterMorgan
 
24.10.17
15:07
(149) Да ладно? И в чем бред? Я послушаю и приведу пример тебе на 10 разработчиков в УТ
152 DexterMorgan
 
24.10.17
15:20
(149) Оптовая/розничная торговля автозапчастями, 11 магазинов + бэк, все в одной базе, 700+ активных подключений (ну по крайней мере на момент ухода), 250 000 позиций номенклатуры:

Розинца - 1, Продажи - 2, Закупки - 1, Склад - 1, Бух/Фин - 1, Обмены/выгрузки сайты/бух/антор/WMS/проч - 2, Логистика/Обеспечение - 1, ведущий (в основном постановщик/производительность) - 1
153 DomovoiAtakue
 
24.10.17
15:23
(150)Я думаю конечно что это ерунда какая-то а не работа, но спорить не буду, допустить могу что имеет место найтись такой случай когда сели куча прогов и быстро стартанули конфу и предусмотрев нужды клиента допилили ее. Но в теме как я понял приводят примеры постоянной работы кучей прогов в одной базе.

Не показательно конечно, но вот столкнулся я в этом году по совместной работе с организацией, в которой сидит около 8 прогов в одной базе. Это просто фиаско. каждый знает какой-то кусок в базе и когда возникает вопрос апгрейда - вместо 15 минут неделю решают как дорабатывать функционал, про скорость доработок я уже молчу. В итоге они в 8 человек работают в раз 100 медленнее и совсем не качество чем я один. Но как я сказал это совсем не говорит о том что много прогов в одной базе это точно будет плохо. Интересно узнать как без кучи прогов не обойтись в одной базе.
154 DomovoiAtakue
 
24.10.17
15:25
+(153)Точнее в каких базах и при каких задачах необходимо много прогов?
155 DomovoiAtakue
 
24.10.17
15:38
(152)Это переход с одной конфы на другую?
156 Fish
 
24.10.17
15:40
(151) Бред в том, что разработка и внедрение готового продукта несколько разные вещи. Для ВНЕДРЕНИЯ типового решения разработчики не нужны, нужны внедренцы. И их количество не зависит от количества пользователей базы.
Другое дело - доработка типовой. Но тут опять же - количество разработчиков никоим образом не зависит от количества пользователей в базе. Поэтому я и написал, что фраза "внедрение УТ11 на овер 300 пользователей" - бред, т.к. к количеству разработчиков они никоим образом не относится.
157 ildary
 
24.10.17
15:41
(153) есть еще такой вариант - программистов много, потому что персонал совсем буратинистый и приходится каждому подтирать сопли (помогая найти ему кнопку выбора периода), а также для написания сотрудникам 100500 вариантов отчетов (у меня совещание через полчаса, а у меня цифры не готовы).
158 Fish
 
24.10.17
15:46
(154) В основном в самописных или в сильно переработанных типовых (где типовая была взята лишь за основу). И это, как правило, не БП и не ЗУП, и обычно про обновления от поставщика в таких конфах можно забыть, т.к. в них идёт постоянная доработка.
159 DexterMorgan
 
24.10.17
15:46
(156) пфф, назови г0вно-розой пахнет все равно г0вном, речь шла о количестве программистов (ок, пусть внедренцев). От пользователей базы зависит косвенно, как правило, чем больше пользователей - больше и сложнее бп и больше хотелок.
160 DexterMorgan
 
24.10.17
15:47
(155) изначально да, с аксесса, древнейшего и кучи баз
161 DexterMorgan
 
24.10.17
15:48
(156) Опять же от количества пользователей зависит производительность, иногда чела выделяют, иногда бегут к Гилеву
162 Fish
 
24.10.17
15:49
(159) Да не зависит от кол-ва пользователей. Совсем. У нас была своя разработка на основе одной отраслевой конфы (перепиленная на 90%). Когда добавилось ещё несколько филиалов, для нас абсолютно ничего не изменилось - в новых филиалах те же самые бизнес-процессы. И кол-во программистов зависит не от количества УЧАСТНИКОВ бизнес-процессов, а от количества САМИХ бизнес-процессов.
163 Fish
 
24.10.17
15:50
(161) "иногда чела выделяют, иногда бегут к Гилеву" - Такой человек называется сисадмин, и к программистам, а тем более к конфигураторы не имеет отношения.
Конечно, если вы используете запросы в цикле, то вам и отдельный программист на оптимизацию кода будет нужен :))
164 Fish
 
24.10.17
15:52
(159) "чем больше пользователей - больше и сложнее бп" - А вот и нет. 1 человек вполне может выполнять сложный бизнес-процесс, а 100 - простейший. Никакой зависимости тут нету.
165 DexterMorgan
 
24.10.17
15:52
(162) 5 и 1000 одно и тоже?

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

(163) БУ_ГА_ГА, это называется "Эксперт по тех вопросам"
166 DexterMorgan
 
24.10.17
15:53
(164) Мля, в ларьке один чел и закупщик, продажник и логист.
167 DexterMorgan
 
24.10.17
15:54
(164) Кароче еще один ларечник детектед
168 DexterMorgan
 
24.10.17
15:56
(163) походу запросы в цикле - это все, что ты знаешь о проблемах с производительностью? А про проблемы с параллельностью не слышал? А что такое ЦУП, сервисы Гилева для чего?
169 DexterMorgan
 
24.10.17
15:56
(168) + это тоже должен админ уметь?
170 Fish
 
24.10.17
15:56
(167) Конечно ларёчник. Только вот пока доводилось работать в ларьках от 1,5 тысяч человек численностью и более. :)))
Но ты видно в более крупных корпорациях работал, куда уж мне :))
171 DexterMorgan
 
24.10.17
15:57
(168) Распараллеливание в несколько фоновых заданий проведение по партиям - это тоже к админу?
172 DexterMorgan
 
24.10.17
15:57
(170) Да-да-да, по диалогу заметно сразу))))
173 Fish
 
24.10.17
15:59
(168) " А что такое ЦУП, сервисы Гилева для чего?" - По мне, так бесполезная фигня это. Мы как-то и без них обходились прекрасно. Но кому-то, возможно, не хватает умения без этого обойтись.
174 DexterMorgan
 
24.10.17
16:00
(173) без комментариев, с тобой все понятно =)
175 Fish
 
24.10.17
16:01
(174) Если ты не можешь обойтись своими силами и знаниями без Гилёва, это не значит, что он жизненно необходим всем :)))
176 DexterMorgan
 
24.10.17
16:03
(175) Ты просто не сталкивался с проблемами крупных внедрений
177 DexterMorgan
 
24.10.17
16:05
(175) Я не говорю, что он необходим, я говорю о проблемах возникающих в высоконагруженных системах, напрямую зависящих от количества пользователей
178 Fish
 
24.10.17
16:05
(176) Сталкивался, и вполне успешно решали их самостоятельно. Без привлечения сторонних "оптимизаторов" типа Гилёва. Рекомендации его, конечно изучали, для общего развития, но далеко не всё из его рекомендаций для нас были новостью.
179 Fish
 
24.10.17
16:06
(177) Открою тебе ещё один секрет: для увеличения производительности системы тоже не надо увеличивать штат программистов. Достаточно повышать квалификацию существующих :)))
180 DexterMorgan
 
24.10.17
16:07
(178) Мля, да без ЦУПа и сервисов невозможно решить проблему с параллельностью
181 Fish
 
24.10.17
16:08
(180) Правда что ли? Ты серьёзно? А как по-твоему, их решали ДО появления ЦУПа? :)))
182 DexterMorgan
 
24.10.17
16:08
(179) Причем тут это? Представь есть задачи, под них выделено X программистов. Всех все устраивает, но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это
183 DexterMorgan
 
24.10.17
16:10
(181) Другими инструментами. А если про 1с, то раньше она и поддерживала такие объемы, как сейчас
184 Fish
 
24.10.17
16:11
(182) При том, что разговор изначально шёл о необходимости работы нескольких программистов в одной конфигурации. И не более.
" но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это" - Опять неудачный пример. Такие проблемы надо решать максимально быстро, а новому человеку понадобится время на изучение. Не взлетит.
185 DexterMorgan
 
24.10.17
16:11
(181) Не ну конечно, если ты эксперт по скл, то тогда тебе они не нужны, но я что-то в этом сомневаюсь
186 DexterMorgan
 
24.10.17
16:12
(184) Ерунда, для того, чтобы решить проблемы с производительностью, в логику самой выгрузки вникать, как правило, не нужно. Ты просто нихя не понимаешь в этой теме
187 Fish
 
24.10.17
16:13
(185) Сомневайся. И да, я не эксперт по СКЛ, но работал в команде, где таковые присутствовали.
188 Fish
 
24.10.17
16:15
(186) Ну конечно, я ничего не понимаю. У тебя же всё просто: чем больше штат программистов, тем выше производительность. Придёт новый "варяг" и всё тут же поправит, не вникая. У нас таких "спецов" даже на порог не пускают :))
189 DomovoiAtakue
 
24.10.17
16:17
(182)Наверное надо дать задание на переделку тому кто недодумал или скосячил. А смысл нанимать нового прога, которого нанимать может пол года будете, потом пока он въедет во все еще пол года. лучше дать текущему чтоб за час ну или день разобрался и поехали дальше клепать новые задачки.
190 DexterMorgan
 
24.10.17
16:19
(188) Ты перевираешь смысл моих слов. Я говорил, что от количества активных подлкючений прямо и иногда косвенно зависит количество требуемых программистов
191 DexterMorgan
 
24.10.17
16:20
(189) Если проведение по партиям - это типовой механизм и виновных нет? Просто он перестал за ночь выполняться
192 DexterMorgan
 
24.10.17
16:22
(189) Поверь мне, не все программисты могут оптимизировать свой код, я те, кто могут справедливо хотят за это больше денег. Посмотри сколько спецов по платформе и сколько экспертов, это не зря так
193 Fish
 
24.10.17
16:22
(190) Косвенно - возможно, но очень косвенно. А вот прямой зависимости нет и быть не может. Если, конечно, на программистах не лежит функция службы техподдержки - тогда да, чем больше пользователей, тем и программистов понадобится больше. Но я бы это решил созданием службы поддержки без увеличения штата программистов.
194 DexterMorgan
 
24.10.17
16:23
(193) Я тебе ответил на это уже
195 Fish
 
24.10.17
16:26
(194) Ах, да. Я и забыл, что говорю с экспертом мегакорпораций. У нас, ларёчников, как-то проще всё. А главное, не раз проверено на практике и работает в жизни, а не в теориях :))
196 ac13
 
naïve
24.10.17
16:26
А как обновлять? Нетиповая конфа, днем в ней больше 100 юзеров. Когда её обновлять?
197 Fish
 
24.10.17
16:28
(196) Ночью/вечером, вестимо.
198 Ymryn
 
24.10.17
16:35
Хранилище по факту всем хорошо и удобно, кроме двух пунктов.
1) Файловый вариант может повреждаться. И в моей практике несколько раз было потеря изменений, а один раз даже повреждение конфигурации, что при получении изменений из хранилища в базе повреждалась конфигурация. Лечилось пересозданием хранилища.
2) Если брать более надежный вариант с серверным хранилищем, то начинается проблема с платформами. Что если тестовый сервер решили поднять на платформу повыше, чтобы протестировать поведение базы на новой платформе, то вы уже к хранилищу не подключитесь. Ибо несоответствие версий.

Но как бы альтернатив хранилищу я все равно сейчас не вижу. Обновление cf-ником сейчас уже выглядит настолько топорно и неудобно, что чур-чур-чур.
199 DomovoiAtakue
 
24.10.17
16:38
(191)Тогда весь ваш отдел нафиг не нужен:) Вся ваша работа ради того чтоб работал партионный учет в первую очередь.
(192)Это не программисты.

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

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

На предприятиях не возникает с такой скоростью количество задач, чтоб загрузить 15 программистов. Это образно каждый день надо требовать по 2-3 абсолютно новых отчета или новый документ.
200 vis_tmp
 
24.10.17
16:44
200
201 DomovoiAtakue
 
24.10.17
16:47
+(199)"Это образно каждый день надо требовать по 2-3 абсолютно новых отчета или новый документ" Уточню: для каждого. Т.е. через пару недель, на новую конфу с нуля наскребут.
202 dmpl
 
24.10.17
16:53
(163) 1С использует запросы в цикле. посоветуй ей отдельного человека на оптимизацию нанять.
203 DexterMorgan
 
24.10.17
16:55
(199) поржал, спасибо
204 Fish
 
24.10.17
16:56
(201) "каждый день надо требовать по 2-3 абсолютно новых отчета " - Ты исходишь из того, что потребуют новый отчет по данным, которые ИМЕЮТСЯ в программе. А если потребуется отчёт, под который ещё надо данные (со всеми вытекающими) создать? :))
205 Лефмихалыч
 
naïve
24.10.17
20:55
(198) Во-первых, серверное хранилище - точно такое же файловое, как и любое другое.
Во-вторых, это не проблемы с версиями, а порядок и защита от дурачков, которые в одно хранилище ломятся с нескольких платформ. Это, кстати, самая распространенная причина клинической смерти конфигурации - два дебила с разными версиями конфигуратора.
206 Sayan_mi
 
26.10.17
15:14
Народ, а не подскажите ли как из тестовой проще переносить информацию в хранилище? Т.е держим ещё одну базу для работы с хранилищем, захватываем объект и переносим в него то что сделали в тестовой? Или есть ещё какие варианты? А если добавили новый объект то захватываем всё хранилище и создаём его заново(хорошо что хоть отладили на тестовой)?
Ошибка? Это не ошибка, это системная функция.