Всем привет
Интересует опыт тех, кто сопровождает продуктовые базы 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 баз с под тыщу пользователей в сумме это не хухры мухры

(0) сборка заранее, автотесты
Обновление может быть автоматизировано, но все равно должен быль дежурный, который дождется уведомления, что всё встало корректно.

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

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

Автоматизированное обновление
Хаха
Очень смешно

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

Нюню

(20)+ А еще фоновые (от регламентных) длительные которые тупо не убиваются и/или постоянно все новые лезут и лезут

Некто перед этим на копии прода конечно же отладил обновление
Но вот забыл что копия монопольная (с одним юзером а не всеми) и регламенты там обычно вырублены
Ну даже если заранее отладить - пока ночь/время обновления пришло в рабочей базе может что угодно поменяться
И куча патчей от 1С накатиться и юзеры потопчутся и фигак при обновлении будет (19)