当谈及云ALM项目时，许多大公司都不是从零开始的。这些公司现在几乎都有一些应用生命周期管理实践。这是一件好事，因为同时迁移到云并采用新的ALM工作很难。如果你打算更换ALM工具，那么在把应用迁移到云中之前你最好做一些事情。这能帮助确保这些工具和ALM实践能与内部IT实践更好的合作。

　　本文中，概述了在把ALM迁移到云中涉及到的一些事情，以及识别了在此过程中需要当心的一些陷阱。

　　确保你所选择的云平台与你的ALM工具兼容

　　计划一个ALM云策略的第一步是，识别当前用来管理应用的工具，然后，创建他们的功能来管理候选云平台。了解你当前的ALM工具是否支持每一个云平台，把这一条放到考虑之中很重要；如果他们不支持，那么你就需要云定制管理接口或选择新的工具了。谨记，ALM可能既需要编制/配置工具也需要应用程序集成工具，而且两者都必须经过验证，验证与候选云平台的适用性。

　　租赁或单独应用？

　　一旦你解决了平台和工具兼容问题，那么云ALM第一生产力的第二步就是，确定云平台是否支持独立的沙盒，无论是“租赁”的还是单独的应用。每个版本的应用程序都被认为是一个不同的用户/应用程序，而且有它自己的沙盒。在你的云ALM策略中将会出现的陷阱，很有可能是与数据库和工作流集成相关的问题。你必须确保测试的沙盒不能访问生产数据库和工作流。这对于本地ALM工具来说是事实，同样也适用于基于云的。但允许云中的访问将会出额外的问题，因为测试沙盒可能被利用作为攻击一个生产系统的一个路径来。当然也存在风险，测试沙盒可能会泄漏用户或其它隐私数据。如果这些泄漏发生，那么罪魁祸首很有可能是一个应用集成问题，问题中生产数据库或应用程序编程接口（API）被列为是测试沙盒的资源。许多情况下，这是由于脚本或信息工具参数错误造成的，因此测试这些工具很关键。大多数据用户报告最好结果是在早期ALM阶段（例如，开发、或变更为单元测试）呈现的沙盒。只有在早期的的测试被证明完全合格后，用户才会进入到下一阶段。注意，云应用程序实例的处理可能不同于内部资源，并且确保这些差异反映在集成工具上。

　　在云ALM计划中要考虑的另一个区域是，测试云相关的流程本身。云管理接口无疑要是ALM测试的一部分。该测试可能会想验证ALM工具在管理API中操作是否适当一样简单。但是，不要忘记测试一些特殊功能，如“滚动实例”——云应用程序随着时间区域变化适应多个地理位置。

　　走入云，再走回来？

　　因为大部分云应用只在云中做短暂的停留，所以有些公司希望能在云和内部IT资源之间来回切换。在某些情况下，目标是设计并测试一个有序的流程，以便在发生故障或业务环境改变时，公司可以从云中退回来。另一些公司希望云可以作为内部IT的备份或溢出资源。

　　把云作为备份或溢出资源使用会造成更多的ALM云计划问题。问题是内部应用程序和云版本都需要“成对的”的沙盒，ALM周期的每一阶段都要有一对。应用的故障恢复或工作负载共享流程在沙盒的每一对中都必须进行测试，特别要注意，不要不小心触碰到每一对的交叉边界。通常，故障恢复和工作负载共享是基于用户提供的前端交换机，这些系统必须采用数据库和事务之间某种形式的同步，保持云和内部资源的更新。所有的这些流程都必须在沙盒对中集成，来确保ALM的完整性。

　　最后一个问题是，ALM中云的“即服务”模型的重要性。由于基础设施即服务（IaaS）平台上的应用程序是基于非标准化,和作为一个结果，因此流程管理和集成也不是标准化的。这意味着有相当大的一部工作需要集成ALM工具和流程，通过IaaS而且不是PaaS或SaaS。管理应用集成更难，它是云计算的关键需求，当每一个应用可以使用不同的定位资源和组织的方法时。有了PaaS，编排和集成流程趋于标准化了，在跨平台时。有了SaaS，只有高水平的集成是必要的。在考虑一个云平台时，要记住这几点。也要记住，长远看来大部分