Перенос протестированного функционала из нескольких баз в рабочую базу
Есть 5 копий БД. Все конфигурации у них привязаны к одному хранилищу. 4 базы для разработки и тестирования и 1 рабочая. Разработка ведется в нескольких базах. Возникла проблема переноса в рабочую базу не всего функционала, который уже есть в хранилище (так как протестированный так и не протестированный функционал) а только протестированного функционала.
1. Как вариант можно конечно в рабочей БД делать не полную загрузку из хранилища, а делать "Сравнить/объединить". Для чего нужно четко знать, что переносишь и где-то заранее записывать, что переноситься. Не очень удобно.
2. Еще вариант вижу как работу с 2 хранилищами. Но тут таже проблема, при подключении между хранилищами, нужно или через "Сравнить/объединить" делать, или конфигурация полностью заменяется.
3. Работа через ГитХаб. Пока не смог найти достойной информации как можно использовать его для моего случая. Нет опыта. Представляю только теоретически.
Уважаемые коллеги что посоветуете?
1. Как вариант можно конечно в рабочей БД делать не полную загрузку из хранилища, а делать "Сравнить/объединить". Для чего нужно четко знать, что переносишь и где-то заранее записывать, что переноситься. Не очень удобно.
2. Еще вариант вижу как работу с 2 хранилищами. Но тут таже проблема, при подключении между хранилищами, нужно или через "Сравнить/объединить" делать, или конфигурация полностью заменяется.
3. Работа через ГитХаб. Пока не смог найти достойной информации как можно использовать его для моего случая. Нет опыта. Представляю только теоретически.
Уважаемые коллеги что посоветуете?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Без сравнения-объединения никак не обойтись, если непротестированное кладется в хран.
А если еще и несколько доработок касались одного объекта, и перенести надо только часть из них - можете начинать вешаться.
А если еще и несколько доработок касались одного объекта, и перенести надо только часть из них - можете начинать вешаться.
(4) Да я предлагал этот вариант, но есть проблема с тем, что разработка ведется в одной базе, а тестирование в нескольких. Можно конечно отвязаться от хранилища на всех кроме одной копиях и переносить конфигурацию через файл. А в хранилище слаживать только протестированные вещи.
(5)
И только одна единственная разработка, подключенная к хранилищу. Ну и боевая на этом же хране, да.
то разработка ведется в одной базе, а тестирование в нескольких.
а вот именно для теста просто в тестовую перезаливается CF из базы разработчика. У каждого разработчика - своя отдельная тестовая для пользователей (чтобы не пересекаться). В случае больших проектов - даже несколько тестовых. Лично у меня всегда в наличии 2-3 тестовых по количеству проектов. Да даже девелоперских у меня тоже 2-3 по количеству проектов.
И только одна единственная разработка, подключенная к хранилищу. Ну и боевая на этом же хране, да.
(7) Можно, но очень нежелательно.
1. Исходная конфигурация может быть недееспособной (я могу "развалить" конфу, и только через 2-3 дня собрать воедино - связи и наличие самих методов, имен методов/объектов/реквизитов, типов параметров и объектов и т.д.)
2. В тестовых в это время пользователи уже тестируют какую-то часть функционала. Накатывать на них неизвестный функционал надо только когда а) программист уверен в работоспособности б) пользователи согласовали изменение тестовой и понимают чего ждут.
1. Исходная конфигурация может быть недееспособной (я могу "развалить" конфу, и только через 2-3 дня собрать воедино - связи и наличие самих методов, имен методов/объектов/реквизитов, типов параметров и объектов и т.д.)
2. В тестовых в это время пользователи уже тестируют какую-то часть функционала. Накатывать на них неизвестный функционал надо только когда а) программист уверен в работоспособности б) пользователи согласовали изменение тестовой и понимают чего ждут.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот