在WinOps 2017大會上，Sabin.io首席顧問Simon Sabin做了一個演講，介紹如何將數據庫更改加入到持續部署模型中。從數據庫所有者的角度看，要實現在多個服務或應用間共享數據庫，關鍵之一就是將這些共享數據庫看成是API。
Sabin建議考慮使用視圖、觸發器和存儲過程等機制。它們可以更改數據庫的內部結構，并同時保持向后兼容的應用數據操作。他舉了一個例子，一個存儲信用卡號的數據庫表已經從純文本改為被加密的，但要保證應用依然以純文本方式檢索卡號。例子中是通過查詢視圖實現的，而實際的數據庫表通過觸發器實現信息的加密和解密。處理結構如下圖所示：
數據庫向應用提供隱式的合約和接口，其中數據庫的內部更改（通常出于性能、安全和其它一些改進的需要）不應該影響到應用。這一原則可以類比為API，突破性更改同樣遵循最小化原則，并應給出大量的通知信息，保證應用在實際數據更改之前采納和部署前向兼容更改。對數據庫應用消費者驅動合約，這樣的方法是可延展的。
按Sabin的說法，需要這一方法去調和對共享數據庫的不同視角。應用開發人員總是將數據庫看成是“沉默的存儲”，而數據庫管理員（DBA）則將數據庫看成是關鍵業務數據的倉儲之所。理想情況下，每個應用團隊會有自己的數據庫，團隊中也應具有DBA角色，但這通常難以達到。
當應用本身就需要模式或其它更改時，Sabin建議降低批處理的規模（因為在數據庫中實現可靠性和一致性是一個復雜的任務），一次應用一個小更改，并更改相應的應用代碼。選取何種遷移機制，是金模式（Gold Schema）還是遷移腳本方式，依賴于更改的具體類型。在Sabin看來，相比于對抗式的，這一機制更多是補充式的。對于模式更改，適用于金模式機制。金模式定義了目標模式（期望狀態），并使用類似于SQLCompare這類的工具做了當前狀態和期望狀態間的“差異比較”。遷移腳本包括DBDeploy、Flyway或ReadyRoll等，該機制可能更適用于更復雜的修改。
Sabin還推薦了其它一些方法，包括：指定數據庫去適合自身工具而非其它方法，將部署信息添加到數據庫自身中以便于追蹤和診斷問題，將數據庫更改作為交付流水線一部分看待以提升可審校性和合規性。演講的最后，Sabin建議使用區分在“私有”和“公開”的方法極大地改進數據安全（在持續發生關鍵數據泄漏時）。例如，讓一個可訪問（“公開”）的小型數據庫中提供對較大規模的安全（“私有”）數據庫的視圖，而“私有”數據庫是不應被應用本身直接訪問的。
正如DevSecOps運動是經過一段時間后才得以確立，將數據庫更改加入到集成持續部署過程中的理念業已存在一段時間了，并被冠以各種稱法。Sabin將其稱為“Data DevOps”，也有人將其稱為“數據庫生命周期管理”（DLM，Database Lifecycle Management）。另一位WinOps 2017大會演講者，Eduardo Piairo，指出：
DevOps并非是要定義一個處理數據庫更改的新過程，而是將數據庫更改和應用及架構代碼一并集成到服務生命周期中。
查看英文原文： Treating Shared Databases Like APIs in a DevOps World
京公網安備 11010502049343號