Стратегия управления пакетами Oracle без нарушения кода

Question

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

Например, в нашем экземпляре разработки разработчик приложения может захотеть изменить хранимую процедуру. Однако изменение хранимой процедуры приведет к поломке существующего Java-кода до тех пор, пока уровень DAO не будет обновлен для внесения изменений.

Моя типичная практика заключалась в том, чтобы внедрить новую процедуру в пакет «DEV». Затем разработчик может изменить свою ссылку на этот пакет, выполнить его тестирование, а затем, когда мы будем готовы, мы можем заменить процедуру в пакете «production», удалить ее из DEV, а разработчик изменит свою ссылку на производственный пакет.

Однако, я нахожу, что это не работает так плавно, как хотелось бы. Во-первых, если есть куча Java-кода, который зависит от пакета DEV, тогда я в такой же ситуации, как если бы редактировал производственный пакет напрямую - если я сломаю пакет, я сломаю кучу кода.

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

Цель состоит в том, чтобы разработчики работали. Да, это сервер разработки, но мы не хотим внезапно нарушать код.

Может кто-нибудь предложить методологии, которые работали для них, чтобы решить эту проблему?

Answer 1

Если у каждого разработчика есть своя схема в базе данных, и для всех объектов в общей схеме есть общедоступные синонимы, и весь код Java использует неквалифицированные имена объектов, то локальная копия пакета в схеме конкретного разработчика будут иметь приоритет над общей версией. Таким образом, разработчик A может взять текущую версию пакета, установить его в своей локальной схеме, внести любые изменения в пакет и внести любые изменения Java в свою собственную среду разработки (я предполагаю, что разработчики имеют свой собственный локальный сервер приложений). Когда оба набора изменений достаточно стабильны, чтобы их можно было проверить в общей среде разработки, как пакет PL/SQL, так и изменения Java могут быть встроены в общую среду разработки (общий сервер приложений разработки и реальную схему в база данных разработки). Затем разработчик может удалить свою локальную копию пакета.

Этот подход работает достаточно хорошо, пока разработчики проверяют PL/SQL из исходного элемента управления, чтобы начать их изменения, а не предполагать, что какая бы локальная копия, содержащаяся в их схеме, не была текущей - если разработчики хранят старые, локальные версии кода в своей локальной схеме, они могут столкнуться с трудными для отладки проблем, когда их версии PL/SQL и Java не синхронизированы. Вы можете решить эту проблему, автоматизируя процессы, которые, например, удаляют пакеты из схем разработчика, если они не были изменены в течение разумного периода времени, и если эти пакеты не будут проверены разработчиком в исходном контроле или путем создания сценариев которые позволяют разработчику автоматизировать обновление своей схемы как части процесса сборки.

Answer 2

Уровень Java/DAO должен быть затронут только в случае изменения спецификации процедуры (например, числа, имени и т. Д. Параметров). Стратегии смягчения для этого:

1. Добавить новые параметры с параметрами DEFAULT для параметров, чтобы их не нужно было передавать.
2. Не изменяйте порядок параметров, если они кота называются позиционно [например, pkg.proc_a (1,2,3)] или переименовывают их, если вызывается по имени [например, pkg.proc_b (p_1 => 1, p_2 => 2)]

3. Использовать пакеты для процедур и функций, так что вы можете перегрузить их

   создать или заменить упак является прок (p1 в varchar2); proc (p1 в varchar2, p2 в количестве); конец;

С перегрузки вы можете иметь несколько процедур с тем же именем в пакете только с разными номерами и/или типов данных параметров

11gR2 ввела Editioning, чтобы решить эту проблему. Он позволяет нескольким версиям пакетов и коду приложения выбирать, какая версия (версия) кода, который он хочет видеть, - стандартная «базовая» версия или версия для разработки.

Однако я подозреваю, что обновление версии базы данных не является практичным решением.