《持续集成》一书的作者Paul M. Duvall 撰写了一篇案例研究,讲述了在公共医疗领域某大型组织如何在云中采用持续交付。该文讨论了他们在此过程中遇到的困难、使用的工具以及相应的解决方案。
该案例研究表明要实现一个基于云的、成本低、性能又好的开发软件方案不是没有可能。这会带来包括交付时间缩短、资源利用更充分以及(短暂)环境可重建等在内的诸多好处。而不足之处在于对网络延迟和基于云的开发平台的风险(如云故障)管理缺乏控制。
云托管应用已然成为当今的主流技术选择,而本案例研究则揭示了即将到来的新趋势即在云中也能够进行开发和测试。对于那些采用持续交付方式的组织来说,他们需要对开发、测试和运维环境进行统一管理,因此这一组合模式对这类组织显得尤为适用。
这类特定组织曾经尝试解决一些问题,其中包括较长的交付周期(部分要归咎于设置过程的繁文缛节)、缺乏对基础架构成本的直观反映(从而导致资源得不到充分利用)以及对环境的误配置。
我们来看看 Amazon Web 服务(AWS),这一平台为经过授权的小组成员(开发者、测试员和管理者等)提供按需(on-demand)一键式(one-click)EC2 实例。这些实例根据目标领域进行自动配置,因此可以确保任何环境都可以从头开始重建。与此同时,对这些虚拟实例加以监控(和阻止)为组织提供了所需的使用分析能力从而使其能够动态评估和利用基础架构成本。
创建一个可持续交付的流程(定制化 Jenkins )会进一步缩短开发及交付可靠软件给测试员的时间。完整的持续交付实现包括设置构建自动化和依赖管理自动化、持续集成、数据库更改管理、自动化测试、静态分析和远程部署支持。一个完整的在云上的开发基础架构也需要在 EC2 实例上安装和设置一些需求管理、测试管理和执行的工具。版本控制和问题跟踪可以选择 SaaS 方案( Jira Studio )。
那些需要确保其软件和 / 或服务满足一定安全和可用性级别的组织已经完成了对世界不同区域的冗余云资源的管理。同样的云代理服务可能会被用来管理多重云(multi-cloud)持续交付平台。特别是其聚集能力,可以解决由于在不同云中部署流程步骤而产生的互用性方面的问题。
评论