Всем привет
Интересует опыт тех, кто сопровождает продуктовые базы 1С, работающие в режиме 24×7, где окно обновления ограничено, например, с 2:00 до 2:30 ночи.

У нас сейчас следующая ситуация:

Разработчики работают в смешанной среде: часть в Конфигураторе, часть в EDT.

Сборка релиза .cf требует ручной синхронизации изменений, что занимает много времени и несёт риск ошибок
Jenkins уже используется в CI/CD, есть мысль накатывать релизы через Jenkins напрямую в рабочую базу (по расписанию или вручную).

Хотелось бы обсудить:

Как у вас организован процесс релизов в 24×7-средах?

Как вы минимизируете трудозатраты на сборку .cf, если разработка ведётся и в EDT, и в Конфигураторе?

Используете ли вы Jenkins или другие CI/CD-инструменты для автоматизации обновлений рабочих баз?

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

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

Мощный вопрос

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

(0) Имхо у вас там овер
И овертехнологии и оверпутаница с овербардаком...

Ибо собирать cf для обновления конечно можно автоматом с разными DevOps
А вот обновлять базы только вручную или под пристальным присмотром (процесса и результата) после нажатия кнопки ответственным спецом

>Как у вас организован процесс релизов в 24×7-средах?
По максимуму переносить код доработок в расширения
Для обновления конфы выделять окна
Или использовать специальные методы, например РИБ (есть технология от самой 1С на ее основе)

Самое тяжкое когда обновление типовой очередное

(0) Я тут записываю для себя кучу новых модных терминов. И вот о них как раз и хотел спросить. Продуктовая база или продуктивная?

(4) если контора продуктами торгует, то ..продукутовая

(5) Человек ерничает, а ты ведешься.

(6) Видимо это такой современный стиль, как-нибудь написать, а в ответ на уточнения: ёрничает, душнила.. Это же 1С - тут точность нужна! )
Просто последнее время много где повылазила эта "продуктовая база", почему-то именно такое написание, вот и уточняю.

Для режима работы 24/7 в 8.5 планируют новое динамическое обновление, с обновлением структуры базы.

(0) Имхо, у вас бардак. Примите волевое решение, все в конфигуратор или все в ЕДТ. Опыт автоматизированного обновления по ночам есть, в крупном холдинге. Там было порядка 25 баз на единой конфе (да, у каждой организации своя база), обновлялось все по ночам Обновлятором из заранее подготовленного cf

(3), (9)
Конфа отраслевая, специализированная, написана самостоятельно, с использованием БСП. Расширения используем, но на случай бага на проде.
Чтобы обновлял ночью спец на проде, это видится крайне избыточно, пусть он спит лучше. Моё мнение: если можно автоматизировать процесс, то нужно автоматизировать.

Загнать всех в EDT оказалось проблематично. Есть замечательные разработчики, которые ну ни в какую не хотят его осваивать, хотя у самих у кого снегопат, у кого труконф.
(8) ждём с нетерпением этого функционала.
(9) Вы обновлялись по ночам из cf, при помощи oscript по расписанию или это какой-то другой софт? Насколько стабильно работает?

(9) что было если например в регистре в составном типе было усечение типов колонки и появлялись неуникальные записи и обновление не применялось? как себя вела система Обновления при этом? cf в копии мог быть подготовлен, но в копии не было записей в РС, а в рабочей есть

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

(0) Нормально обновлялись раньше без всяких CI/CD и прочей ерунды.

Делается так -обновляете сначала конфу в конфигураторе, все проверяете. Далее в тех. окно запускаете обновление БД.

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

(0) некоторые из не самых основных баз давно обновляются полностью автоматически, какие-то нестыковки случаются раз в несколько месяцев.

Конечно по факту обновления летит результат в телегу, успех или нет.

Если у вас ночью случится этот неуспех - пусть уже ночной саппорт решает, пробует обновить вручную. Наверняка такой саппорт есть если 24*7

(14) какой софт  используете для автоматического обновления? Забираете изменения из хранилища или полностью накатываете cf?

софт вот этот https://github.com/vanessa-opensource/vanessa-runner

из хранилища

после обновления просто запускаю обработку через execute которая шлет телегу в телегу

(0) Было дело, работал в такой организации 5 лет, но только в конфигураторе. За первый год работы всё максимально сделал универсальным и настраиваемым, т.е. самописку заменил на стандартную УПП, плюс туда нестандартные блоки в виде подсистем внеедрил. Всё. Остальные четыре года пузо чесал и обновлял всё самое частое раз в неделю, как раз во время свободного окна.
Так что тут два пути, в т.ч. и у вас: Либо быстро работать руками, либо научиться работать головой.

(10) Чувак, ты не знаешь про обновлятор? Ну блин, у меня даже слов нет. Даже тут была тема автора. Работает более чем стабильно, сам понимаешь, 25 баз с под тыщу пользователей в сумме это не хухры мухры