How can I manage PL/SQL package source at the method level?

Question

In our ERP application suite, we have a very small number of PL/SQL packages that are large and monolithic in nature, containing a wide assortment of functionality. (This is because each package requires additional configuration in the ERP suite itself.) Putting the entirety of an API in source control is prohibitive because simultaneous development projects can leapfrog along the pipeline. Right now, we manually deploy to QA and PROD at the method level, modifying and adding methods to the package by copying them out of text files. (We work with them using PL/SQL Developer by Allround Automations.) This is time-consuming and error-prone, and I'd like to automate this process in a DevOps fashion. Using an existing utility, is there a way to store package methods as discrete files in source control and deploy them to their package individually?

Answer 1

Some pondering if you're in fact having a XY problem. YMMV.

Using an existing utility, is there a way to store package methods as discrete files in source control and deploy them to their package individually?

To me this sounds a peculiar requirement. In database a PL/SQL package is a single atomic unit (in fact there is two units (a specification and a body) but that's irrelevant in this context) that is modified and deployed as a whole.

Let's rephrase the question:

Using an existing utility, is there a way to store Java class methods as discrete files in source control and deploy them to their class individually?

I'd say that's simply silly. IMO one should treat Oracle PL/SQL source code in the same love than any other programming language source code.

(I'm not ware of such a tool, but you very likely can make that by yourself.)

Your real problem are monolithic PL/SQL packages:

[...] PL/SQL packages that are large and monolithic in nature, containing a wide assortment of functionality.

That conflicts your parallel development paths.

Reading the fine manual:

A package is a schema object that groups logically related PL/SQL types, variables, constants, subprograms, cursors, and exceptions.

And finally the root cause:

[...] because each package requires additional configuration in the ERP suite itself.

IMO tail wagging the dog.

Resolve this problem, refactor your PL/SQL to have a modular structure and your development/deployment conflict problems mostly disappear.

I don't know the "ERP suite configuration" details but I'm positive it's PITA-factor is much smaller than the current mess.