Собственно сабж

угу

я единственный программист в фирме

(0) А на фига?

а как иначе

Даже если и единственный. Как в рабочую изменения вносить?

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

(6) почему?

(5) Ночью, когда все спят. Не?

(6) Обоснуй. На прошлой работе было несколько разработчиков. Рабочая была подключена к хранилищу. При правильном использовании хранилища и при понимании принципов работы с ним - никаких проблем.

вот так

(8) Вот именно, епстись с объединением или с выпуском релиза для обновления придется ночью. А через хранилище - несколько кликов.
Тока косяков чо-то с этим хранилищем в 8.2.16 дохрена.

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

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

Собственно

и не одна

(11) просто есть же в конфигураторе: "Загрузить конфигурацию из файла". никаких объединений и релизов не требуется.

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

(7)(9)
в хранилище очень часто неоттестеный функционал лежит, и накатывая свою часть очень легко зацепить чужое.

нарывались постоянно, пока не принял решение отключить хранилище от рабочей

Та да

(18) до боли знакомо :))))

(18) Хм, так это вопрос скорее к организации труда и профессионализму программистов. Какого лешего сливать в хранилище сырой код?

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

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

(23) а еще можно работающей бензопилой руку отрезать, всего лишь забыл выкл. нажать.

(24) спасибо кэп. никогда до подобного сравнения не додумался бы.

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

а как иначе?

как то так

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

(25) обращаетесь.

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

(18) +100

Пробовали подключать рабочую к хранилищу. Отказались из-за рисков.

(21) ыыы почувствовал себя мегаорганизованным

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

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

(34) это уже проблема постановщика аналитега начальника распределить ресурсы так что-бы не пересекались

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

Кто подключает к рабочим хранилище - самоубийцы со стажем. Имхо.

(30) А зачем с ним что-то делать? И чем он помешает накатить обновление, в случае, если эти два документа не взаимосвязаны?

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

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

а вообще идея хранилища хорошая, но реализовано имхо через жеппу

(40) нука нука? ее каждый раз надо подключать?

(39) Нарастите штат хотя бы человек до 20, потом расскажете, как оно весело, когда рабочая подключена.
З.Ы. А хранилищ у нас, например, 2. Для каждой (почти) конфигурации

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

(43) из хранилища выгружается конфига, накатывается на рабочую

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

(44) а у Вас штат?

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

(47) смотри (45)

У нас ажно два хранилища - trunk и release.
Продуктив не подключен ни к одному. В планах:
1. продуктив посадить на поддержку и обновлять обновлениями, которые получать из хранлища release.
2. тестовую среду подключить к хранилщу trunk и обновлять автоматически по расписанию как-то. Чтобы была непрерывная интеграция.
ЗЫ Код между хранилищами переносим руками, пользователей там и там заводим тоже руками

(49) Не надо забывать. Есть определённые правила совместной работы с хранилищем и их надо соблюдать. Конечно, если вы правил не читаете и не хотите им следовать, тогда хранилище не для вас. Это к вопросу о профессионализме, если что.

Ибо так

(45) А не надо захватывать чужие части документа. Если надо добавить/удалить форму - захватил весь, добавил, отпустил и пили дальше только ее

(52) в стране волшебных эльфов и сферических коней, которые кушают радугу и какают бабочками, это абсолютно справедливо. Но вот в реальной жизни не возможно ни фига собрать коллектив, где больше 5 человек и все они были одинаково офигенно профессиональные профессионалы, которые не делают ошибок, умеют ВСЁ и работают вместе хором.

(45) если очень сильно припекло:
- первый сохраняет конфу, отменяет захват в хранилище.
- второй берет себе форму, меняет что ему надо, и помещает в хранилище
- первый захватывает из хранилища нужный документ, через сравнение/объединение аккуратно объединяет.

вообще не вижу проблем. уже так делали и не раз.

(55) поэтому лучше разделять труд на участки. Каждый занимается только своим. При редактировании общего участка - прежде надо согласовать со всеми.

(49) а чо, сравнение объединение не даст этого сделать?

(57) когда разрабайтеров больше 10, эти твои теории не применимы

(55) да понятное дело, когда есть один выделенные разраб, который только и сидит что, объединяет, то ваще проблем нет.

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

(58) что не даст? База подключена к хранилищую, сделал получить конфигурацию из хранилища, попытался сохранить в ИБ и все, 1С ругается, что нету регистратора.

(62) ну клевый пример.

Могу предположить что те кто отвечают ДА ! Они анверно и демоническим обновлением пользуются ???

(59) тогда применима другая теория. Есть один главный разрабайтер, он отвечает за внесение изменений в общие пересекающиеся части. И за их контроль/тестирование перед внедрением.

Между делом проверил бэкапы своего хранилища.

(63)+ типа плюс не подключенной к хранилищу базы в том, что ты можешь добавить регистратор или удалить объект в любой момент? это ты считаешь офигенным плюсом?
а у вас как происходит обновление? если надо обновить, то чувак сидит до 11 на работке и ждет когда все повыходят из базы и объединяет?

(65) Пойдем к нам, поработаешь тем самым объединятелем. Потом расскажешь, как оно.
(48) Разработчиков в районе 20, если сопровождение и поддержка. Но поддержка в конфигурации не гадит.

(65) ага, это вот как раз, который на коне кушает радугу и какает бабочками. Друк, ну вот чего сочиняешь того, чего не видел? Ну не работает оно так в реальной жизни

(67) Плюс в том, что можно собрать нормальное работоспособное обновление.
Кроме того, одинэснеги - они раздолбаи. Удалить реквизит в регистре? Та запросто! Фигня, что потом реструктуризация дня на 4 на рабочей базе будет.

(59) И чем же они неприменимы? Тем, что начальник не умеет управлять коллективом больше, чем из 5 человек? Прогоните его и возьмите другого.

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

Надёжней релизики клепать.

Но обновление выполняю полным получением версии из хранилища.

(71) Лефмихалыч зевает

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

(68)(69) дело не в объединителе, а в старшим разработчике, который смотрит за тем, чтобы подельщики не угробили своими наработками всю базу, а также следит за быстродействием

(77) сколько народу в твоем коллективе разработчиков?

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

Скатились на мерение письками.


(76)Даже для одного хранилище необходимо.

(78) если ты не видел иного кроме своего, то не говори, что такого нет в природе ;)

(79) эти твои 10 душ, они - включая поддержку и сопровождение?

Коллизии есть, но они не приводят к тотальным последствиям. Без этого никуда не деться. А все потому что есть грамотное централизованное рук-во старшим.

+(82) или у вас оно не делится на разработку, поддержку и сопровождение и разработчики все одинаковые - сам себе архитектор, разработчик и проектировщик?

(74) а зачем?

(82) Да. Но для этого (поддержка и сопр-е) есть еще также и свои люди. Кодеры (эти 10 чел) главным образом пишут код.

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

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

(84) Тут важнее, не как у них всё поделено, а то, что всё работает.  
"А вы, друзья, как ни садитесь; Всё в музыканты не годитесь" (с)

(84) мелкие части - архитектор каждый себе сам. Каждый ответственен за свой участок и только он знает все мелочи. А за общие участки - архитектор - старший. И он же курирует их.

(85) Когда то в какой то версии был какой-то глюк/баг с хранилищем. Привычка осталась ;)

(84)
И поверь это намного лучше, чем когда нет централизованного контроля. Или, например, приходящие в разное время N франей. Вот где беда.

(90) да ну это ж долго. Разрешаю забыть привычку))

(92) А куда спешить. Пока обновляется пользователи выгоняются :)

+(87)Да, еще УФ созданная в одной конфе не всегда переносится в другую конфу без хранилище и во второй базе пустая форма. Хоть объекты и незахвачены и изменения получены.

Но все равно используем хранилище

а то!
у меня даже база PIM личная подключена к хранилищу

(22) +1

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

(77) Куда бежать, когда этих ваших "старших разработчиков" 8 человек и объекты хоть ты тресни, а пересекаются?

опять магнит из Краснодара возомнил себя вершиной идеологии разработки
хотя соглашусь, немного участвовал в команде 8 рыл еще на 8.1 сырой - то был ад с хранилищем

сотко?

*

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

(2) Даже если единственный, хранилище хранит версии конфигурации. Можно сравнить, а что ж тут было н-цать правок назад?

Славик, чо-та я очкую ©

4 хранилища для каждой рабочей базы