10大準則令完美的開發/測試實驗室成為可能

　　你是否擁有一些實現超敏捷軟體開發所必備的特質？創業公司Ravello Systems探討了通過將雲規範化，來構建夢寐以求的開發/測試實驗室的關鍵準則。

　　在這樣一個競爭優勢與業務敏捷度近乎畫上等號的世界中，現實情況是，企業往往需要非常多的時間投入，來開發和測試驅動業務的種種軟體。

　　在軟體開發中，超敏捷要求基礎設施和自動化不僅與開發程式保持一致，而且還要對加速迴圈和改進整體質量產生實質性幫助。在開發/測試工作負荷具有猝發性和短暫性本質的大前提下，要想打造一套理想的完全部署在本地的實驗室，可以說在經濟上是不可行的。然而現在藉助將雲規範化的新技術，對大多數企業來說，與超敏捷開發和測試之間的距離正在被不斷縮短。

　　這裡給出的10項準則，它們將有助於推動開發/測試實驗室涅槃重生。儘管時至今日，依舊幾乎不可能實現在打造這個“夢寐以求的實驗室”的同時又不至於投入許多花費，然而藉助各種最新的技術，很容易構建這個理想的實驗室：它不止能夠提升軟體質量、加快投放市場的步伐，還能夠減少整體成本。

　　1.敏捷開發/測試具有猝發模式的特點，並且實際上要求無限的基礎設施資源池

　　典型的軟體開發和測試現在都得到了自動化處理，但是由於資源方面的制約因素，並不是所有的測試都能夠並行進行。對任何企業來說，讓開發/QA團隊等待測試結果，需要付出極其高昂的代價——這不僅僅是一種低效行為，還會使得企業在業務競爭中輸給更加敏捷的對手。在理想場景下，開發者應該無須等待，就能夠訪問資源池，而且該資源池在他的角度看來是無窮無盡的——不論是公有、私有還是混合雲，因此任意數量的測試都可以立即且並行地進行。

　　2.開發者應該享有基礎設施的自服務渠道

　　要想完全利用潛在的近乎無窮盡的資源，工程師需要能夠：通過預先定義的許可，以按需、自服務的方式訪問資源池，而不是等待IT為每個請求逐一配置資源並授權訪問。

　　3.使用產品複製品進行測試的能力

　　從Ravello針對開發/測試工程師、IT管理員、自動化工程師和DevOps進行的調查來看，多達75%的架構師和IT管理員都意識到了：建立開發/測試環境過於複雜且耗時，而且這些環境並不能代表產品。儘管每個人都能夠認識到對速度的要求，但同時我們也不要忘記，軟體質量是另一個同等重要的方面。特別是在非常靈動地環境中，要想確保最終結果始終具有高質量，測試產品的複製品固然頗具挑戰，但卻是至關重要的事情。例如，如果我們擁有一個本地VMware環境，並且想要在亞馬遜AWS雲服務上測試這些應用，那麼兩種型別的環境之間應該是完全無縫的。

　　4.基礎設施應該在應用層面進行自動化

　　基於單獨的快照和副本，手動複製複雜的多虛擬機器應用，是一件繁瑣且容易出錯的工作，而且當涉及到複雜的網路配置時更是如此。在理想情境中，應該能夠通過簡單的一次點選，就完整複製多虛擬機器應用及其網路。

　　5. 持續整合——從應用到基礎設施

　　通過持續整合，開發者在提交程式碼時，應該能夠擁有應用的多個例項（產品複製品），並且在同一時間裡執行一系列完整的整合測試。開發者需要即刻獲得反饋，以瞭解測試的功能在類生產環境（production like environment）中工作良好，或是出現了問題並需要修訂。作為支援持續整合的絕佳工具，Jenkins得到了廣泛運用。然而要想成功使用，需要將它與底層基礎設施設定緊密地整合，以用於無縫的端到端自動化——從程式碼到硬體。

　　6.身處各地的開發和測試團隊能夠便捷地協作

　　設想一下，一位QA找出了某個Bug，他不需要打斷或推遲其他正在進行的測試工作，就能夠邀請開發者檢查或除錯相同的應用例項——不論二者身在何方。這種快速訪問和分享將加速開發/測試迴圈，並提高團隊協作。

　　7. 重現Bug的能力

　　在複雜的多虛擬機器應用中，跨應用元素的依賴和互動，使得重現Bug是一件非常困難的事情。在理想的配置中，整個複雜應用可用被打包成一套環境，從而能夠簡單地重現Bug，例如識別出某個Bug時，就可以執行測試系統的一份複製品。

　　8. 快速製作原型

　　使用標準的預定義積木式部件（例如，標準的資料庫叢集）來快速製作應用原型，將顯著加快開發/測試迴圈的速度。然而，理想中的積木式部件，應該不僅僅是使用標準應用元件的全新或現成的例項，而是對實際應用中存在的相同元素進行復制，從而更加貼近生產環境。

　　9. 監控資源使用的能力

　　考慮到開發/測試實驗室在本質上來說非常不穩定——虛擬機器被頻繁的建立和銷燬——因此，要想確保資源有效利用和未使用生產能力的恢復，監控開發/測試資源使用情況的能力至關重要

　　10.成本效益

　　最後，但顯然很重要的一點是，提供所有這些能力，都應該以業務能夠承受的成本為前提條件。在之前提到的這份調查中，80%的開發團隊遇到了開發/測試基礎設施短缺的問題，而92%的開發團隊則擁有購買更多硬體裝置以用於開發/測試專案的需求——然而增大采購併不總是一個划算的方法。特別是對於突發性的工作負荷——例如開發/測試——幾乎不可能針對峰值容量預先設計好資料中心，因為那意味著在大部分時間裡，讓昂貴的基礎設施資源閒置。在完美的實驗室中，應該能夠很容易地管理開發/測試例項，我們只要在用到的時候“開啟”例項即可，而不是讓所有例項保持7*24執行——只需要為了消耗的資源按使用付費。

　　11.額外要點：極限測試

　　實驗室還應該具有這樣的能力：通過簡單API呼叫，來檢查網路失敗情景或是測試高可用性環境。這在概念上與Chaos Monkey有點類似，但是卻有著更廣泛的功能，並使得執行檢查失敗情景的複雜測試時，不再需要手動拉線或是停止Tomcat。

　　軟體正在“蠶食”這個世界，但是企業中開發和測試基礎設施的狀態，卻阻礙了企業開發者們真正擁抱敏捷的程式。DevOps的興起正是面對該差距的一種嘗試。上面介紹的這些準則，在彌合開發者和基礎設施管理員之間的鴻溝，以及為企業建立夢想中的實驗室方面，還有很長的路要走。

　　關於作者

　　Rami Tamir在管理多型別軟體開發方面，擁有長達十五年的經驗， 2011年，Tamir與他人一起建立了Ravello Systems並擔任CEO的職位。在創辦Ravello Systems前，Red Hat收購Qumranet（開發了KVM管理程式的公司，現在該技術已成為Linux中的標準虛擬化技術）時，Tamir作為Qumranet的聯合創始人和總裁出任了Red Hat的工程副總裁。再早些時候，Tamir與他人創辦了Pentacom並執掌軟體部分，並隨著被Cisco收購就任後者提供的高階祕鑰管理職位。

　　英文原文：The Perfect Dev/Test Lab: 10 Principles that make it Possible