10大準則令完美的開發/測試實驗室成為可能
英文原文：The Perfect Dev/Test Lab: 10 Principles that make it Possible
你是否擁有一些實現超敏捷軟件開發所必備的特質？創業公司 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 收購就任后者提供的高級秘鑰管理職位。
<span id="shareA4" class="fl"> </span>