當談及云ALM項目時，許多大公司都不是從零開始的。這些公司現(xiàn)在幾乎都有一些應用生命周期管理實踐。這是一件好事，因為同時遷移到云并采用新的ALM工作很難。如果你打算更換ALM工具，那么在把應用遷移到云中之前你最好做一些事情。這能幫助確保這些工具和ALM實踐能與內部IT實踐更好的合作。

本文中，概述了在把ALM遷移到云中涉及到的一些事情，以及識別了在此過程中需要當心的一些陷阱。

確保你所選擇的云平臺與你的ALM工具兼容

計劃一個ALM云策略的第一步是，識別當前用來管理應用的工具，然后，創(chuàng)建他們的功能來管理候選云平臺。了解你當前的ALM工具是否支持每一個云平臺，把這一條放到考慮之中很重要;如果他們不支持，那么你就需要云定制管理接口或選擇新的工具了。謹記，ALM可能既需要編制/配置工具也需要應用程序集成工具，而且兩者都必須經過驗證，驗證與候選云平臺的適用性。

租賃或單獨應用?

一旦你解決了平臺和工具兼容問題，那么云ALM第一生產力的第二步就是，確定云平臺是否支持獨立的沙盒，無論是“租賃”的還是單獨的應用。每個版本的應用程序都被認為是一個不同的用戶/應用程序，而且有它自己的沙盒。在你的云ALM策略中將會出現(xiàn)的陷阱，很有可能是與數據庫和工作流集成相關的問題。你必須確保測試的沙盒不能訪問生產數據庫和工作流。這對于本地ALM工具來說是事實，同樣也適用于基于云的。但允許云中的訪問將會出額外的問題，因為測試沙盒可能被利用作為攻擊一個生產系統(tǒng)的一個路徑來。當然也存在風險，測試沙盒可能會泄漏用戶或其它隱私數據。如果這些泄漏發(fā)生，那么罪魁禍首很有可能是一個應用集成問題，問題中生產數據庫或應用程序編程接口(API)被列為是測試沙盒的資源。許多情況下，這是由于腳本或信息工具參數錯誤造成的，因此測試這些工具很關鍵。大多數據用戶報告最好結果是在早期ALM階段(例如，開發(fā)、或變更為單元測試)呈現(xiàn)的沙盒。只有在早期的的測試被證明完全合格后，用戶才會進入到下一階段。注意，云應用程序實例的處理可能不同于內部資源，并且確保這些差異反映在集成工具上。

在云ALM計劃中要考慮的另一個區(qū)域是，測試云相關的流程本身。云管理接口無疑要是ALM測試的一部分。該測試可能會想驗證ALM工具在管理API中操作是否適當一樣簡單。但是，不要忘記測試一些特殊功能，如“滾動實例”——云應用程序隨著時間區(qū)域變化適應多個地理位置。

走入云，再走回來?

因為大部分云應用只在云中做短暫的停留，所以有些公司希望能在云和內部IT資源之間來回切換。在某些情況下，目標是設計并測試一個有序的流程，以便在發(fā)生故障或業(yè)務環(huán)境改變時，公司可以從云中退回來。另一些公司希望云可以作為內部IT的備份或溢出資源。

把云作為備份或溢出資源使用會造成更多的ALM云計劃問題。問題是內部應用程序和云版本都需要“成對的”的沙盒，ALM周期的每一階段都要有一對。應用的故障恢復或工作負載共享流程在沙盒的每一對中都必須進行測試，特別要注意，不要不小心觸碰到每一對的交叉邊界。通常，故障恢復和工作負載共享是基于用戶提供的前端交換機，這些系統(tǒng)必須采用數據庫和事務之間某種形式的同步，保持云和內部資源的更新。所有的這些流程都必須在沙盒對中集成，來確保ALM的完整性。

最后一個問題是，ALM中云的“即服務”模型的重要性。由于基礎設施即服務(IaaS)平臺上的應用程序是基于非標準化,和作為一個結果，因此流程管理和集成也不是標準化的。這意味著有相當大的一部工作需要集成ALM工具和流程，通過IaaS而且不是PaaS或SaaS。管理應用集成更難，它是云計算的關鍵需求，當每一個應用可以使用不同的定位資源和組織的方法時。有了PaaS，編排和集成流程趨于標準化了，在跨平臺時。有了SaaS，只有高水平的集成是必要的。在考慮一個云平臺時，要記住這幾點。