SOA治理中版本控制的最佳實踐是什么？版本控制工具應該具備哪些功能？
在服務的生命周期當中，版本控制是人人都要面臨的一項挑戰。首先，也是最重要的最佳實踐是，永遠都要假定事情是會變的。然后設法在一開始就定義流程和標準，在變化發生時予以應對。Gartner的Roy Schulte談到了早在2000年代中期時的SOA，指出系統做出來是為了能持續。但是，在當下，我們需要為變化而做系統。
比方說，你是否允許多個版本的服務進入生產環境運行？如果你的答案是肯定（本來也應該如此）的，消費者如何才能被引導到正確的版本？消費者會不會明確指出自己期望的版本是什么，或者是靠隱式確定的？只要是牽涉到SOA的地方，我們總是以這樣或那樣的方式在要求中明確主要版本（如1.0還是2.0），但是次要版本（1.1還是1.2）就不那樣要求。
主要版本和次要版本之間的區別在于，次要版本總是向后兼容的，而主要版本則不一定。我們通常都會努力爭取向后兼容，因為這是影響最小的變化。如果我們決定打破向后兼容性時，這么做往往會有比較好的理由。試圖通過轉換來規避這一點有可能會在中間引入顯著的復雜性，讓消費者有借口不做改變，而這正是我們不希望看到的行為。系統會針對消費者和提供商而做出改變。
版本控制工具的第二個最佳實踐是，就產品運行中應該有多少個版本設定限制。我的建議是不要超過三個主要版本，然后每一個都只保留一個次要版本。因此，1.0、2.0、3.0可以有，但是永遠不要同時出現1.1、1.2，除非是在1.2剛剛發布的短時間內保留一陣子，以便執行A/B測試時回退的需要。
為什么要三個版本？
答案部分依賴變化率的情況。如果你服務的變化率不同于正在消費系統的變化率，事情可能就無法同步。對于每一個待修改的消費系統，你必須確定現實的預期。如果每一個消費應用每年都會有一項重大發布，你就應該能夠把服務升級作為這些發布的考慮因素，生產環境下同時運行的版本不超過三個應該就行了。如果你每年發布的主要版本超過3個，那就是表明界面設計糟糕的一個跡象，說明東西沒有一直保持向后兼容性。
你也不能在未對服務消費者提出需求的情況下對服務提供商做出限制。一旦新版本到位，確保有政策指明服務消費者在必須升級前還有多少時間。每一次發布，除了業務所需的功能增強以外，組織往往很容易就會陷入做某些基礎性工作的習慣當中。如果消費者不把它當作標準慣例，服務提供商就要維護非常非常多的服務版本，導致相關維護成本的增加。
而對于內部和外部消費者，你也許有需要不同的策略。內部消費者處在組織的控制下，而外部消費者則很難告訴他們該如何花錢。這意味著升級所需的時間有可能更長一點，令向后兼容變得更加重要。
建立信任
說到向后兼容，回歸測試必須成為任何版本控制策略的核心。消費者一旦被變更搞得焦頭爛額，顯然應該會導致重大的信任問題。為了建立起信任，服務提供商應當竭盡所能去向服務消費者說明變更是否會對他們產生影響。
這要在消費者開始使用服務時從他們中當中收集回歸測試開始。然后，內一次發布，服務提供商都可以執行每一個消費者提供的測試來說明變更是否影響到他們。在每一個消費者身上進行測試非常重要。
如果測試主要由服務提供商創建，而服務消費者卻一點都沒有參與的話，他們就會說“你沒有執行我的測試，因此我無法信任你不會搞砸我的應用。”對于一個擁有大量消費者的服務來說，這些測試包會變得很大，所以有牢靠的自動化測試手段來保持回歸測試的低成本是很重要的。
最后，如果你沒有跟蹤服務消費者，那你就相當于給自己挖了一個大坑。無論你是用Excel表格，還是Access數據庫，或者是正規的SOA容器來做這件事都行，你得跟蹤這些消費者，并且對你的信息一直都要有一個身份的表示。在你試圖讓舊版退出運行時，如果你不能觀察運行時流量，不能方便地確定這些流量來自于哪些消費者的話，你就有大麻煩了。
還有技術可以扮演的角色，尤其是當你使用像ESB、XML裝置或資產網關這樣的東西時。你可以用這些來進行轉換，針對特定場景執行基于消息的路由，不過我已經發現，在保持事態控制方面，明確的版本控制策略以及預期要比試圖讓所有人根據最有利自己的特定系統去做自己想做的事情，然后再試著在其中用技術來管理混亂的效果更好。
這并不是說這些技術沒有用，技術是有用的。但是要用版本控制工具來支持這些策略，而不是取代策略。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.vmgcyvh.cn/
本文標題：SOA治理必備三劍客
相關文章
