將敏捷思維引入數據庫開發

多年來，敏捷實踐攜短迭代、快發布、更快推出軟件的承諾一直吸引著應用程序開發人員。現在，同樣的做法已經進入數據庫領域，但是，數據庫開發團隊該如何采用那些做法，他們應該從哪里開始？在本系列文章的第1部分（共2部分）中，Matt Hilbert闡述了如何從版本控制入手將敏捷思維引入數據庫開發。

敏捷號稱無所不在。開發人員喜歡它，因為它簡化了流程，改進了軟件質量，實現了重復工作的自動化，并支持持續交付，使他們可以將精力集中在他們擅長的事情上：編碼。

許多公司喜歡它，因為就像Puppet Labs發布的《 2014年DevOps現狀報告 》所顯示的那樣，那些使用類似敏捷方法的企業，其利潤、市場份額和生產率目標都超出了兩倍。

Gartner甚至將將敏捷軟件開發列入了 2015年十大高科技趨勢 ，將其視為數字經濟的驅動力之一。

但這對數據庫開發人員和管理人員意味著什么？他們無法承受匆忙隨意地數據庫變更。默認情況下，他們需要事先做大量設計。

由于整個的數據庫開發過程都比較謹慎、缺少敏捷性，所以將敏捷實踐（如持續交付和自動化費力的任務）應用于數據庫開發過程是一個真正的技術挑戰。敏捷意味著向現有的做法中引入新技術、陌生的流程和沒有使用經驗的工具，同時也意味著，在現有的部署方式已經夠用的情況下，冒著風險更快、更頻繁地部署。

是那樣嗎？將敏捷思維應用于數據庫開發，開發過程會更簡潔、更迅速，浪費更少，質量由開發過程保證，可以避免后續許多部署問題。

游戲規則已經變了

事實是，敏捷和持續交付已經像野火一樣席卷了應用程序開發領域，數據庫開發領域也出現了許多敏捷活動。這是一種很自然的擴展，因為業務快速變化，功能發布速度需要加快，而數據庫不能成為瓶頸。

在數據庫開發、測試和部署方面，有一些工具和流程可供采用，而且可以同應用程序開發所使用的工具和流程一起使用。將數據庫視為另外一部分源代碼，并采用敏捷實踐，數據庫生命周期管理（DLM）會變得更簡單。

使用方法正確的話，DLM可以減輕數據庫管理員（DBA）的負擔，簡化和加速測試過程，將偶爾的、讓人滿懷擔憂的大規模部署轉化成簡單安全的頻繁部署。

同時，它將DBA的角色由看門人轉變成推動者，前者有時候會被認為阻礙了部署，而后者卻讓部署更簡潔。

那是個很大的變化，或許有些出人意料，開始實施敏捷還是比較簡單的。

統一所有人的思想

第一步是考慮協作，而不是競爭。在關于DevOps的著名小說 The Phoenix Project 中，對于應用程序開發人員和DBA之間的分化，主角Bill Palmer有一段精彩的評論：

這種分化是不必要的——在數據庫開發中采用敏捷思維，這種分化將不復存在。目標是實現更小更頻繁的發布，開發和運營團隊互相交流，并且總是在較大的問題上進行協作：提供高質量的軟件。例如，運營團隊會事先強調，建議的變更會對數據庫產生什么影響以及為開發人員帶來什么后果。

Moneysupermarket.com數據架構師David Poole贊同這種觀點。在文章《 DBA和開發人員比較：無謂的沖突導致了悲傷的故事 》，他在結論部分寫道：“經驗告訴我，當開發人員和DBA一起很好地合作時，他們不只是增加了彼此的效率；他們的效率翻倍了。”

選擇恰當的工具

第二步是要記住，敏捷意味著改進工作方式。這不是說引入工具強制執行變革，將嚴苛、陌生的規則、工具和流程強加給每個人。相反，它要求以更好的方式使用現有的工具，就像Alex Kuznetsov在《 六年敏捷數據庫開發的教訓與經驗 》中所寫的那樣：

例如，你可以使用應用程序開發人員所使用的版本控制、持續集成和發布管理工具，實現數據庫變更的版本控制、測試和部署。

這樣，就不需要引入沒有使用經驗的工具，那雖然可以完成工作，但會增加對人們的制約，而通過充分發揮數據庫工具的作用，并結合現有的應用程序開發工具，你同樣豐富了工作方式。

通常，這還會帶來額外的好處，應用程序和數據庫開發團隊齊心協力向著共同的目標努力，真正實現開發過程的整合。

小處著手

持續交付、持續集成、數據庫管理生命周期——其中每個短語都足以使有關數據庫敏捷思維的討論聽上去比實際復雜。

關鍵是從小處著手，首先對數據庫進行源碼控制或版本控制。源碼控制本身并不是一種敏捷實踐；但它可以促成類似持續集成這樣的敏捷實踐。沒有源碼控制，你就無法實現敏捷。實行源碼控制，就為實施敏捷創建了條件。

對數據庫及應用程序實行源碼控制的更大好處是，兩者的版本可以同時同步和測試。數據庫代碼的所有變更都同應用程序代碼的變更聯系在一起，任何可行的構建都可以任何時候重新生成。SQL Server最有價值專家Grant Fritchey在“ 為什么要將數據庫納入源碼控制？ ”一文中寫道：

部落記憶不是源碼控制

部分公司和組織仍然依賴手動的、腳本驅動的流程，他們常常將其稱為源碼控制。通常，其構建是圍繞一個人或一個小團隊對數據庫的深入理解和以前什么可行（現在可能仍然可行）這樣一份記憶。開發人員和DBA直接操作腳本，而不是數據庫，數據庫變更歷史很難維護。

這不是源碼控制，而是對源碼控制的畏懼。已有的數據和結構必須總是處于保護之下，那樣數據才會得到維護，才不會有任何東西丟失。對源碼控制的畏懼正是源于這樣一個事實。

盡管如此，借助源碼控制，多個人或團隊能夠在同一時間訪問代碼段或數據庫。每個代碼段都有版本，這有助于形成分支以及確保不會有任何東西丟失。或者，可以將整個代碼集版本化，使開發人員具備部署到已知狀態或恢復到先前狀態的能力。

同樣重要的是， 配備一個恰當的源碼控制系統，源碼控制實踐會成為每個人日常工作生活的一個正常部分，而不限于一個人數有限的領域。因此，如果真出現了問題，它們也可以得到快速解決，而不會變成一個潛在的危機。

簡潔為美

正如所見，對數據庫代碼實行源碼控制有極大的好處。但如果開發人員和DBA的工作變得越來越復雜而不是越來越簡單，那么實行源碼控制的好處就不復存在了。

引入一種源碼控制工具，迫使開發人員改變工作方式，或者采用不同于現有做法的策略，顯然會惹惱別人。同樣地，選擇一種不同于應用程序源碼控制系統的工具會加深而不是減輕DBA和應用程序開發人員之間的分化。

關鍵是將數據庫源碼控制集成到現有的開發流程，那樣就可以同開發人員已經熟悉的工具和做法保持一致。在SQL Server領域，這不可避免地意味著要使用——最好是在內部——SQL Server Management Studio。

借助一個插件源碼控制工具，開發人員可以繼續使用交互式開發模型，操作一個“在線”數據庫。它將對象創建腳本的源碼控制自動化，提醒用戶數據庫與源碼控制版本之間的差異，并且讓向源碼控制系統提交變更更容易。

隨著源碼控制成為正常數據庫開發流程的一部分，生產力也會得到提升。它節省了時間，使開發人員更不容易忘記向源碼控制系統提交代碼，減少了任務切換，提高了效率。由于可能有多個團隊參與應用程序和數據庫開發流程，所以一個庫也會讓查看已完工任務變得更簡單。

可見，隨應用程序一起實現數據庫源碼控制不僅可行，而且帶來了許多好處。它在開發、測試和生產環境之間同步數據庫結構，減少了有關的工作和錯誤。此外，它能確保數據庫開發團隊同其他人就變更進行溝通，并在需要時提供一個可以用于回滾的版本。

當然，它打開了通向真正的敏捷實踐（如持續集成）的大門。

僅僅實現所需要的敏捷

關于遷移到敏捷工作方式，最重要的信息可能是你所決定的變革步伐。

一旦配備了源碼控制系統，你就可以選擇引入持續集成，將數據庫變更和應用程序代碼一起構建、測試和打包，加速發布，降低部署風險。它不僅可以驗證你的數據庫結構，而且還可以在真實的測試數據上運行單元測試，并檢查數據庫變更實際上是否是按照你的意愿部署的。

然后，你可以升級發布管理流程，包括所有可以讓生產環境數據庫安全高效地變更所需要的更新腳本、變更報告和審核步驟。

這里的關鍵是自動化，讓工具負責處理每個數據庫開發人員和管理人員工作列表最底下那些重復、費力且占用大量時間的任務。

所有這一切的自動化可以將DBA解放出來，將更多的時間花在重要的工作上——降低數據庫部署失敗的風險。這也許并不奇怪，SQL Server Central最近的調查顯示，在已經使用像持續交付這樣的敏捷實踐的公司中，大約有60%的公司變更發布時間降低了；有超過40%的公司變更部署時間降低了；有30%的公司表示，由糟糕的部署所導致的時間浪費減少了。

開始的時候，將數據庫與應用程序一起實現源碼控制，但最終的好處將遠不止于此。

“精益機器”的第二部分將詳細介紹數據庫開發人員如何從像持續交付和自動部署這樣的敏捷實踐中受益。

關于作者

Matt Hilbert 是Redgate的一名技術作者，有20年的工作經驗。他為許多世界上最大的技術公司工作過，也為其中許多最小的公司工作過。他特別熱衷于研究新興技術，孜孜不倦地向廣大讀者解譯、解析、解釋技術觀點，讓人們為技術帶來的無限可能性而興奮。

查看英文原文： The Lean Machine: Bringing Agile Thinking to the Database