部署管理器與 DBA 籠子比賽在將發布推送到產品時
我們公司現在已經為 MS Windows 方面聘請了一名全職發布工程師，我們正在考慮 MS SQL Server 的發布管理流程。
如果我們對他們部署 SQL Server 腳本的能力有信心，那麼讓發布管理器來做這件事是常見的，還是 DBA 通常做的事情？我們的企業發展迅速，我們的 DBA 有點超負荷（令人驚訝的是還有什麼新東西），但我們可以僱傭更多人，但那是另一回事。
你們是怎麼管理這個的？您是否允許發布經理訪問 prod 以推出更改？您是否會剝奪權利並在需要釋放時將其打開？我想我會讓他們訪問一個 sproc，讓他們可以訪問一個小時的 prod，但它會記錄誰呼叫它。
還是我完全不在，這是 DBA 應該始終管理的事情？
任何想法將不勝感激！
編輯：
更新： 當我們遇到異常時會發生什麼？例如，一個開發人員說“這些表應該與其他環境相匹配（我的環境是指客戶產品環境，而不是 qa/stage/etc.）”。通常他們會進行抽查。我做了一個校驗和並註意到最終只是空白問題的問題。在這種情況下，我們是否在進行基本故障排除後將其推回發布經理/質量檢查人員進行修復？
另一個例子：我們有大約 20 個開發人員編寫的腳本，有時他們相互依賴。腳本的順序是錯誤的。我跟不上 20 名開發人員的工作並管理數據，但經過一些故障排除後，我們發現了問題並更改了順序。這是 DBA 通常應該深入參與的事情，還是在基本測試和查看之後公平，我們將其發送回發布經理和開發人員進行修復？
首先，每個環境都不一樣。在我的環境中有效的東西不會自動在你的環境中有效。（我們 = DBA 團隊）
在我的這個過程中，我們有以下環境
開發 - 通常我們會恢復實時副本以準備發布並根據需要清理數據。然後我們將其備份並允許開發人員隨意恢復到該備份。然後他們準備並測試他們的部署腳本。我們希望開發人員在升級/發布過程需要進入 UAT 之前已經成功地測試了升級/發布過程。在這個階段，我們經常需要提供幫助和建議
UAT - 我們將再次恢復 live 和 sanitize 的副本（如果我們要使用 QA 環境）。然後，發布和配置管理器為我們提供來自開發人員的正確升級腳本，我們將檢查它們，在監控的同時執行它們，以便能夠提供 CAB 所需的所有資訊，包括服務失去、升級時間和所需的任何更改到維護/監控腳本，然後我們會建議發布經理。
有時我們會使用 QA 環境，通常是在上述兩種環境中使用了經過清理的數據並且業務需要 QA 而不是測試團隊時。
CAB - 發布經理為 CAB 提供所有資訊，以便他們從後續步驟中做出決定，以準確列出發布期間發生的情況。他們還負責儲存用於從 Dev 到 UAT 的腳本，並將它們提供給我們以發佈到現場。我們只使用由發布管理器提供並在 CRP 中引用的腳本。我們顯然會檢查腳本是否與我們在 UAT 中使用的腳本相同，因為我非常謹慎
Live - 我們按照 CAB 授權的變更發布計劃中的步驟進行部署，通常與其他團隊協調
我們這樣做的部分原因是因為這是我們必須在此處遵循的過程（使用 CAB 等），但在回答您的問題時，這是因為 DBA 團隊負責數據的安全性和可訪問性。也因為我們擁有從意外問題中恢復過來的技能、知識和經驗。Live 數據庫發生的事情是我們的責任，我們非常重視。除 DBA 團隊外，任何人不得在實時數據庫上執行任務。我們是監護人和保鏢（門男/女）
為了您的更新。我將此類問題退回給開發人員，並要求他們在我部署到 UAT 之前修復它。一旦腳本完成（在 UAT），我們就知道它將在現場執行。
對於您的另一個範例-這是發布經理的工作。如果他們向我們提供失敗的腳本，我們會將其退回給他們，並要求他們在我們部署到 UAT 之前對其進行修復。我們不會將任何需要修改或更改提供的說明的東西部署到 UAT 中，並且在少數情況下會發生這種情況（在我們執行腳本以使版本能夠通過 UAT 後，開發人員使用應用程序帳戶來操作一些數據）我在 CAB 中站出來解釋這一點，並解釋說我不樂意在沒有對版本進行正確測試的情況下發布它。這通常有效:-) 我知道我很苛刻，但我也很公平。
我告訴發布經理和開發人員，將發布傳遞給 UAT 的過程不僅是對發布的測試，而且是對發布將如何執行的測試，因此我們將在兩個範例中遵循完全相同的步驟（開發 - UAT 和 Live ) 並且如果它在 UAT 中失敗，它會返回給他們進行修復。
我希望這會有所幫助