如何在方法級別管理 PL/SQL 包源？
在我們的 ERP 應用程序套件中，我們有非常少量的 PL/SQL 程序包，這些程序包本質上是龐大且單一的，包含各種各樣的功能。（這是因為每個包都需要在 ERP 套件本身中進行額外配置。）將整個 API 置於原始碼控制中是令人望而卻步的，因為同時開發項目可能會跨越管道。現在，我們在方法級別手動部署到 QA 和 PROD，通過從文本文件中複製方法來修改和添加方法到包中。（我們使用 Allround Automations 的 PL/SQL Developer 與他們合作。）這既費時又容易出錯，我想以 DevOps 方式自動化這個過程。使用現有的實用程序，有沒有辦法將包方法儲存為原始碼控制中的離散文件並將它們單獨部署到它們的包中？
使用現有的實用程序，有沒有辦法將包方法儲存為原始碼控制中的離散文件並將它們單獨部署到它們的包中？
對我來說，這聽起來是一個特殊的要求。在數據庫中，PL/SQL 包是一個單獨的原子單元（實際上有兩個單元（一個規範和一個主體），但在此上下文中無關緊要），它被作為一個整體進行修改和部署。
讓我們重新表述這個問題：
使用現有的實用程序，有沒有辦法將 Java 類方法儲存為原始碼控制中的離散文件並將它們單獨部署到它們的類中？
我會說這簡直是愚蠢的。IMO 應該像對待任何其他程式語言原始碼一樣對待 Oracle PL/SQL 原始碼。
（我不知道這樣的工具，但你很可能可以自己製作。）
你真正的問題是單一的 PL/SQL 包：
$$ … $$PL/SQL 包本質上是大的和單一的，包含各種各樣的功能。
這與您的並行開發路徑相衝突。
閱讀精美手冊：
包是一個模式對象，它對邏輯相關的 PL/SQL 類型、變數、常量、子程序、游標和異常進行分組。
最後是根本原因：
$$ … $$因為每個軟體包都需要在 ERP 套件本身中進行額外配置。
IMO 尾巴搖著狗。
解決這個問題，重構您的 PL/SQL 以具有模組化結構，您的開發/部署衝突問題大多消失。
我不知道“ERP 套件配置”的詳細資訊，但我很肯定它的 PITA 因子比目前的混亂要小得多。