|
Версионность отдельных страниц в Apex
#38777970
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
|
Участник
Откуда: Харків, Україна
Сообщения: 7 838
|
|
Mr_FrostТ.к. в каждый момент времени в разработке находится как минимум одна-две страницы,
устанавливать на сервер заказчика все приложение целиком нельзя.
Не пойму, как из первого следует второе.
Между разработкой и заказчиком могут (и должны) стоять:
Площадка(и) тестирования. Сюда должны уходить и проверяться покомпонентные изменения с площадки(ок) разработки.
Площадка(и) аккумулирования изменений. Сюда должны устанавливаться проверенные покомпонентные изменения, здесь они накапливаются в ожидании очередного релиза. Отсюда формируется полный экспорт приложения для установки на площадку заказчика. В сборку вместе с экспортом готового релиза должен входить экспорт предыдущей версии и всё необходимое для возврата объектов БД к предыдущему состоянию, если случится непредвиденное на площадке заказчика.
Эталонная рабочая площадка (или несколько). Сюда устанавливается патч с релизом, ушедшим заказчику.
По-хорошему, у заказчика должны быть pre-production site для установки и проверки патчей, production site собственно для работы и mirror site для резервирования.
Все или часть этих площадок можно организовать как в разных экземплярах APEX, так и в разных рабочих пространствах одного экземпляра. И при качественной организации доставки изменений от первого пункта к последнему вот это:
Mr_Frostиногда возникает необходимость быстро исправить что-то прямо на сервере у заказчика
не должно появляться вообще.
Mr_FrostЖизнь вынуждает иногда быстро реагировать и делать что-то у заказчика
Это не жизнь, это отсутствие методологии. Подобное ведёт к попыткам решения последствий административных и организационных проблем техническими изысками.
База заказчика для разработчика вне процесса доставки ПО должна быть доступна только на чтение. Запросы -- пожалуйста. Отладочная информация -- пожалуйста. "Да я здесь только кнопочку поправлю!" -- спасибо, ждём патч, пока что откатываемся на предыдущий релиз или терпим.
Mr_FrostКак потом проверить, что версия страницы у заказчика соответствует версии на сервере разработки?
Выгрузить обе, прогнать через sed, удаляя строки: начинающиеся с prompt; содержащие "+ wwv_flow_api.g_id_offset", "wwv_flow_api.set_security_group_id", "p_last_upd_yyyymmddhh24miss". Сравнить Вашим любимым средством поиска и отображения различий: diff, vimdiff, meld... Есть различия -- устанавливать в стороне копию приложения и начинать разбираться.
Только различие может быть не обязательно в странице. Вы ведь можете срочно поправить что-то в Shared Components. Или вообще в JS-файле, который уже правится другим разработчиком на соответствующем сервере.
Mr_FrostНапрашивается какая-то система версионности не всего приложения, а отдельных страниц, но как это
сделать максимально просто и удобно?
Хранить ревизию в комментариях (Edit ...->Comments), а приложение в VCS -- в виде компонентов. STFW APEXExportSplitter -- идущее вместе с APEX средство для декомпозиции файлов экспорта. |
|
|
