Господа 1Сники, расскажите, как у вас устроен процесс разработки, тестирования, и внесения изменений в боевые базы?
Недавно присоединился в качестве руководителя тех. поддержки к одному проекту. Хочу усовершенствовать озвученные выше процессы.

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

Как есть сейчас:
Подняли хранилище - жить стало легче. Остались другие проблемы. Например, со стороны заказчика отсутствует тестирование доработок до их внесения в рабочую базу. Бывает, что для тестов по отдельным задачам выделяется специальная база, но это не часто. Разработчики сами тестируют свои же разработки, и после слов «вроде работает», помещают объект в хранилище (хотя отчеты сначала помещаются во «Внешние отчеты», а потом в хранилище). К чему это приводит известно. Пользователи находят ошибку в продуктивной базе, которую надо исправить. Приходится >150 юзеров гнать из базы, чтоб срочно исправить ошибку. Или прибегать к демоническому обновлению.

Хочу поднять тестовую базу. Пока что вырисовывается схема: «Хранилище» - «Тест» - «Продуктив». Разработчики помещают измененные объекты в хранилище. Тестовая база полностью обновляется из хранилища. Пользователи тестируют функционал. Объекты, которые успешно прошли тестирование, должны быть перенесены в продуктивную базу. Вроде все красиво. Но как при обновлении продуктивной базы определить, какие объекты прошли тестирование? Например, можно создать служебную подсистему, в состав которой разработчики будут помещать нужные объекты. А я при обновлении продуктивной базы буду отмечать по этой подсистеме. Но это препятствует автоматическому обновлению базы, к которому я тоже хочу прийти.
Или создать промежуточное хранилище, куда разрабы будут помещать протестированные объекты. А продуктив обновлять только из этого хранилища.

Расскажите, как у вас это происходит?

(0) так и происходит
- хранилище+ тестовые базы разработчиков
- стенд + контрольный пример РП
- продуктив

собственно главная проблемма сабжа - "как не допустить попадания в рабочую базу еще не принятх изменений"

простой вариант -

БазаРазработчиков->ОбщееХранилище->ТестоваяБаза->CF->РабочаяБаза


сложный вариант -
ОбщееХранилище<->БазаРазработчиков->CF->ТестоваяБазаРазработчика->CF->РабочаяБаза

(0)Не складывать в хранилище не согласованные изменения - не вариант?

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

А как ты собираешся поступать с объектами которые были затронуты двумя изменениями? И 1 из них прошло, а другое нет. Причем первое затрагивает еще 10 объектов конфигурации. Следовательно надо делать отказ по всем объектам 1го изменения (и 2). Имхо полностью автоматически это не получится.

наймите тестировщика в конце концов. в иделае - косалт это, и задачи прогам он ставить должен, а не технические специалисты/заказчики

(0) вряд ли пользователи забесплатно будут тестировать. За это им бабки надо платить.

(0) "Пользователи тестируют функционал" - как-то не профессионально звучит :) Пользователи не могут/не смогут/не будут :( подчеркните нужное :) "тестировать" по определению. Они же - пользователи! Согласуйте с ними контрольные примеры, разработайте обработку и сами, своими ручками, запускайте для тестирования. До внедрения в рабочую базу. Если после этого пользователи обнаружат ошибки - корректируйте обработку и далее...

(0) у нас есть трихранилища: trunk, stable, rc.
1. Разработчики трудятся в trunk и ежедневно сливают туда изменения (даже не стабильные).
2. Когда разработчик заканчивает разработку, он тестирует на своей локальной базе сам свое поделие, как может.
3. Далее раработчик совместно с куратором разработки (ведущий чаще всего) организуют тестовую зону. Заказывают у поддержки копию, наваливаютна нее свои изменения, как считают нужным, из хранилища trunk.
4. Далее есть специальны люди - ключевые пользователи - и среди нас (есть отдел развития) и среди бизнес пользователей. Тестовая база передается им на тестирование. Все исправления в ходе тестирования делаются в хранилище разработки и накатываются на тестовую базу от туда сравнением-объединением.
5. После того, как КП протестировали тестовую базу, изменения считаются готовыми к встраиванию и помещаются в хранилище rc, где типа проходят как бы нагрузочное тестирование.
6. После того, как в trunk и rc все зашибись, изменения сливаются в stable опять же сравнением-объединением.
7. Из stable формируется комплект поставки для продуктива (продуктив на поддержке и обновляется cfu-шками).

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

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

Спасибо за ответы!
Придется делать еще одно хранилище. Но сильно усложнять тоже не хочется. Все постепенно. Пока что мы доросли до того момента, когда нельзя тащить объекты из хранилища для разработчиков напрямую в продуктив. Иногда бывает стыдно перед заказчиком. Заказчик адекватный и все это тоже понимает.

Тогда вопросы:
Условно назовем хранилища trunk и stable.
Разработчик захватывает объект в trunk. В какой

момент объект надо захватить в stable?

Если на этапе тестирования надо довносить изменения в рамках этой же задачи. Их сразу вносить в stable? Или сначала в trunk?

Думаю, сначала в trunk. Иначе все равно придется тащить конфиг из stable в trunk, чтоб актуализировать его.

Хочу некий бест практикс на эту тему собрать)

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

в 8 нет 3-уровнего сравнения, все кто пользуются git или svn плачут кровавыми слезами.
Внешние обработки все в git храню.
Cf активно но пока в тестовм режиме гоняю через 8.3 и выгрузку конфигураций. Ждемс снегопата на 8.3

Вот опять. К вопросу о тестовой базе и промежуточном хранилище. Сегодня один разработчик забыл поместить объект в хранилище. Т.е. все объекты поместил, а один забыл. Тестирую на своей базе. Обработка "Закрытие месяца" не открывается. А на его тачке наверняка все работает. Если бы сейчас этот cf полностью отправил в продуктив, завтра был бы apic fail.

Еще общался с чуваком, они ведут параллельный проект. Говорит пробовали реализовать схему с двумя хранилищами. Не взлетело. Какая-то путаница все время была.

(20) значит плохо организовали. Вон у Михалыча их аж 3 в цепочке, и ничего не путаются.
У нас 2: trunk и stable. "Гадим" в trunk-е а когда из trunk-а берем в stable то ошибки правим и там и там. Единственное с чем туго как и везде - никто stable тестить не хочет/не может. Очень не хватает набора "тестов" как в проектах на других языках. Сразу бы вылезало где кто какой функционал поломал.

(19) ".. все объекты поместил, а один забыл.". Это всетаки редкость. При нормальной команде разработчиков с "головой" во главе 99 процентов fail-ов устраняется динамическим обновлением.

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

(22) Бывает, что мы тоже его пользуем. Но как-то ссыкотно каждый раз. Я так полгода назад ухандокал базу. 3 часа откачивали.

вообще не правильная постановка вопроса по поводу тестирования пользователями. Доработка не должна переноситься в боевую базу пока пользователь не подтвердит что задача выполнена и работает. Задача не должна считаться выполненной пока пользователь не подтвердит что все тип топ уже в рабочей базе. ИМХО, естественно

(24) примерно к этому все и идет.
Сейчас есть вот как: боевая база обновляется из хранилища разработчиков. Мы задачу переводим в статус "Выполнено". Если все ок, инициатор переводит задачу в статус "Закрыто", иначе в статус "Не выполнено".

(24) это если простейшая одноклеточная задача. Типа отчет или внешняя печатная форма, тогда да. А если как у Армандо, 10 программистов работали над проектом, три хранилища, сотни объектов. И вдруг посадили пользователя, открыли ему базу и он вдруг сразу понял: задача выполнена. Это ненаучная фантастика.

(26) ну проект этот делается не для одного пользователя. Он разделяется на участки. Каждый пользователь свой участок и проверяет. Понятно отдельного пользователя не посадишь все объекты тестировать. Но каждый каждый проект это можно разложить до одноклеточных задач с конкретными пользователями кто это будет юзать

У меня на одной из работ было так:
* у программистов и бизнес-аналитиков свои тестовые базы,
* хранилище,
* рабочие базы.

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

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

А бизнес-аналитики ко вторнику писали инструкции по работе с новым куском 1С (со скринами), размещали в специальном месте на сервере и на портале.

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

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


ОЧЕНЬ удобно было!

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

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

(30) не могу сказать, была не в курсе. Но время от времени просила своих программистов накатить свежие тестовые базы.

Тут на форуме есть Сниф, спроси его, он точно скажет.