Обновление конфигурации, которая подключена к хранилищу
Добрый день, коллеги! Имею 10 рабочих баз ЗУП (каждая база для конкретной организации), которые подключены к хранилищу. Есть основная рабочая база головной организации. Все доделки конфигурации головной организации через хранилище заливаются на другие базы.
//
Пришло свежее обновление ЗУП 74.1, нужно ставить. Программист, который занимался ЗУПом ушла в декрет, теперь поддерживаю я.
//
Для начала посмотрел версию конфигурации поставщика, она отличается от текущей версии конфигурации (69.3 - 73.1). Значит программист на тестовой базе отключался от хранилища, ставил обновление, подключался к хранилищу, заливал на тест конфигурацию хранилища и файл *cf просто накатывал сверху, с последующим помещением всех изменений в хранилище. Вроде бы все по уму, но версия конфигурации поставщика через хранилище не обновлена, что есть, пусть и маленькая, но халтура! Руководство требует обновить версию конфигурации поставщика, хотя бы, для базы головной организации, мол, остальные обождут.
//
Как правильней подойти к процессу?
Мыслю так:
- На тестовой базе, отключаемся от хранилища, делаем файл *cf;
- Ставлю обновления с 70.1 (если они видны в окне обновлений), не обращая внимание на доделки;
- На версию 73.1 накатываю сохраненный файл *cf;
- Ставлю обновление 74.1 с детальный просмотром доделок;
- Полученный файл *cf сохраняю;
- Из базы головной организации выгоняю всех пользователей и также обновляю конфигурацию теперь уже до 74.1;
- Подключаюсь к хранилищу и накатываю последний файл *cf, заношу данные в хранилище.
Или можно как то иначе подойти к процессу?
Спасибо!
//
Пришло свежее обновление ЗУП 74.1, нужно ставить. Программист, который занимался ЗУПом ушла в декрет, теперь поддерживаю я.
//
Для начала посмотрел версию конфигурации поставщика, она отличается от текущей версии конфигурации (69.3 - 73.1). Значит программист на тестовой базе отключался от хранилища, ставил обновление, подключался к хранилищу, заливал на тест конфигурацию хранилища и файл *cf просто накатывал сверху, с последующим помещением всех изменений в хранилище. Вроде бы все по уму, но версия конфигурации поставщика через хранилище не обновлена, что есть, пусть и маленькая, но халтура! Руководство требует обновить версию конфигурации поставщика, хотя бы, для базы головной организации, мол, остальные обождут.
//
Как правильней подойти к процессу?
Мыслю так:
- На тестовой базе, отключаемся от хранилища, делаем файл *cf;
- Ставлю обновления с 70.1 (если они видны в окне обновлений), не обращая внимание на доделки;
- На версию 73.1 накатываю сохраненный файл *cf;
- Ставлю обновление 74.1 с детальный просмотром доделок;
- Полученный файл *cf сохраняю;
- Из базы головной организации выгоняю всех пользователей и также обновляю конфигурацию теперь уже до 74.1;
- Подключаюсь к хранилищу и накатываю последний файл *cf, заношу данные в хранилище.
Или можно как то иначе подойти к процессу?
Спасибо!
По теме из базы знаний
- Параметры командной строки 1С:Предприятие
- Автоматическое обновление конфигурации и другие регламентные операции с базами (на сервере)
- Обновление многих баз из хранилища + дополнительные функции обновление/выгрузки баз. Пакетное выполнение
- Технология разветвленной разработки конфигураций 1С
- Исполняемый файл (батник) автоматического подключения базы к хранилищу основной конфигурации и расширения(й)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
1. Захватываете в тестовой базе корень со всей иерархией.
2. Обновляете, как обычно, как будто хранилища нет. Удобно при этом наложить фильтр "Показывать отличия основной конфигурации от старой конфигурации поставщика".
3. Запускаете тестовую базу, соглашаетесь с ИТС, проходите процедуру обновления данных.
4. Операторски тестируете ключевые механизмы, которые требуются все время и срочно (на случай, если что-то отвалится при обновлении, чтобы вы исправили это до выноса в рабочую базу)
5. Помещаете все объекты в хранилище
6. Выгоняете всех из рабочей базы, выгружаете копию (если храбры, то можно не выгружать)
7. Получаете корень из хранилища с иерархией, нажимаете F7 (при этом, конфигурация поставщика тоже вам придет)
8. Запускаете, соглашаетесь с ИТС, проходите процедуру обновления данных.
Я, собственно, почему написал свой вариант. Коллеги предложили другой алгоритм, который мне показался сложнее. Но может я где-то что-то упускаю.
Это не относится к (9), там все по-другому.
1. Захватываете в тестовой базе корень со всей иерархией.
2. Обновляете, как обычно, как будто хранилища нет. Удобно при этом наложить фильтр "Показывать отличия основной конфигурации от старой конфигурации поставщика".
3. Запускаете тестовую базу, соглашаетесь с ИТС, проходите процедуру обновления данных.
4. Операторски тестируете ключевые механизмы, которые требуются все время и срочно (на случай, если что-то отвалится при обновлении, чтобы вы исправили это до выноса в рабочую базу)
5. Помещаете все объекты в хранилище
6. Выгоняете всех из рабочей базы, выгружаете копию (если храбры, то можно не выгружать)
7. Получаете корень из хранилища с иерархией, нажимаете F7 (при этом, конфигурация поставщика тоже вам придет)
8. Запускаете, соглашаетесь с ИТС, проходите процедуру обновления данных.
Я, собственно, почему написал свой вариант. Коллеги предложили другой алгоритм, который мне показался сложнее. Но может я где-то что-то упускаю.
Это не относится к (9), там все по-другому.
(15)
У кого-нибудь есть опыт работы с хранилищем, чтобы п.1 выполнить посередине п.2, да при этом сохранить все доработки, внесённые другими разработчиками за это время?
1. Захватываете в тестовой базе корень со всей иерархией.
2. Обновляете, как обычно, как будто хранилища нет. Удобно при этом наложить фильтр "Показывать отличия основной конфигурации от старой конфигурации поставщика".
2. Обновляете, как обычно, как будто хранилища нет. Удобно при этом наложить фильтр "Показывать отличия основной конфигурации от старой конфигурации поставщика".
У кого-нибудь есть опыт работы с хранилищем, чтобы п.1 выполнить посередине п.2, да при этом сохранить все доработки, внесённые другими разработчиками за это время?
(15) честно не понял, а почему сразу так не сделали? вроде логично нафига что-то тыкать. конфа обновилась тут - и обновилась там.к аким образом вообще можно было рассинхрониться не понимаю? Кф - ник в себе содержит все , в том числе и поставщика, что за прекол
достаточно захватить корень хранилища и любой объект из дерева метаданных, который будет затронут обновлением.
При обновлении из комплекта поставки обновляйте (извиняюсь за тавтологию) единственный выбранный объект. при необходимости - потом восстановите версию объекта из хранилища.
Конфигурация поставщика неминуема будет обновлена.
Далее она спокойно уйдет через хранилище во все необходимые места.
При обновлении из комплекта поставки обновляйте (извиняюсь за тавтологию) единственный выбранный объект. при необходимости - потом восстановите версию объекта из хранилища.
Конфигурация поставщика неминуема будет обновлена.
Далее она спокойно уйдет через хранилище во все необходимые места.
Помогите, пожалуйста!
Есть рабочая базу, подключенную к рабочему хранилищу. К этому хранилищу ограниченный доступ - не всем программистам.
Есть тестовая база, подключенная к тестовому хранилищу. Доступ к этому хранилищу имеют все программисты.
Все доработки ведутся в тестовом хранилище. Затем их переносим в рабочее хранилище (сравнением и объединением). И затем уже из рабочего хранилища измененные объекты получаем в рабочую базу.
Еще ни разу не делала обновления конфигурации при такой организации баз и хранилищ...
Вопрос: как нужно устанавливать обновления? Нужно установить 5 ключевых обновлений.
Копию базы, отключенную от хранилища - я обновила, с учетом наших доработок. Сохранила cf - для каждого ключевого обновления.
Начинать нужно опять в тестового хранилища?
Захватить все объекты тестового хранилища, установить обновление, без применения обновления к БД - сразу загрузить cf? И применить обновление.
Верно?
И так последовательно все 5 обновлений.
Аналогично сделать для рабочего хранилища?
Есть рабочая базу, подключенную к рабочему хранилищу. К этому хранилищу ограниченный доступ - не всем программистам.
Есть тестовая база, подключенная к тестовому хранилищу. Доступ к этому хранилищу имеют все программисты.
Все доработки ведутся в тестовом хранилище. Затем их переносим в рабочее хранилище (сравнением и объединением). И затем уже из рабочего хранилища измененные объекты получаем в рабочую базу.
Еще ни разу не делала обновления конфигурации при такой организации баз и хранилищ...
Вопрос: как нужно устанавливать обновления? Нужно установить 5 ключевых обновлений.
Копию базы, отключенную от хранилища - я обновила, с учетом наших доработок. Сохранила cf - для каждого ключевого обновления.
Начинать нужно опять в тестового хранилища?
Захватить все объекты тестового хранилища, установить обновление, без применения обновления к БД - сразу загрузить cf? И применить обновление.
Верно?
И так последовательно все 5 обновлений.
Аналогично сделать для рабочего хранилища?
(11) 1. Остановить сервер хранилища.
2. Переименовать каталог хранилища базы
3. Запустить сервер хранилища
4. Войти в конфигуратор
5. конфигурация - хранилище - создать хранилище.
6. Указываем путь (по аналогии со старым путем), логин/пароль администратора
7. Нажимаем на кнопочку "ок" или "создать" (не помню как точно)
8. Ждем. Тыкаем Ок
9. Опять ждем.
10. Еще раз ждем.
11. Тыкаем ОК.
12. Создаем новых пользователей хранилища.
2. Переименовать каталог хранилища базы
3. Запустить сервер хранилища
4. Войти в конфигуратор
5. конфигурация - хранилище - создать хранилище.
6. Указываем путь (по аналогии со старым путем), логин/пароль администратора
7. Нажимаем на кнопочку "ок" или "создать" (не помню как точно)
8. Ждем. Тыкаем Ок
9. Опять ждем.
10. Еще раз ждем.
11. Тыкаем ОК.
12. Создаем новых пользователей хранилища.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот