|
|
|
|
移动端

开发团队实现持续交付的三类最佳实践

引言:企业转变为自动化持续交付的流水线(pipeline)是一个充满挑战的过程。本文向您介绍实施持续交付流水线的一些最佳实践。

作者:陈峻编译来源:51CTO|2018-04-24 09:00

人工智能+区块链的发展趋势及应用调研报告


【51CTO.com快译】将您的开发团队转变为持续交付模式是一项比较艰巨工作。正如自动化持续交付过程本身那样,您应该分阶段进行,而不要一次性更改所有的方面。同时您要有回滚方案,以备各种突发问题的出现。虽然此过程极具挑战性,但一旦成功实现,则会使您能够更快地响应客户的各种需求,并能使您的产品最终在市场上更具竞争力。

自动化的好处

自动化的诸多好处包括:

  • 将上市的时间从按周计算和按月计算,缩短为按天或小时计算。
  • 更少的软件错误意味着降低了市场的风险。
  • 更少的时间花费在运维上,也减少了软件开发的成本。
  • 更强大的开发团队。

一旦成功构建了自动化的pipeline,那么在将整个开发环境进行切换之前,您就可以使用此处所罗列的一些最佳实践来微调自己的pipeline。

我们在此将最佳实践分为三大类:

  1. 软件架构 – 各种服务和产品的整体架构,为您构建pipeline的模式和团队与之交互的方式定下基调。
  2. 自动化模式 - 自动化和各种测试的策略。
  3. 公司文化 - 团队组织、透明度和责任。

1.软件架构

采用微服务 

为了实现真正的敏捷和自动化pipeline,我们建议您将产品构建为各种微服务。

如果您对为何需要微服务还存有疑问的话,请参阅:《什么是微服务?》,和《从AWS角度介绍微服务》

除非您是从头开始创建一个应用程序,否则重新构建整个应用程序将是一项非常艰巨的任务。如果您手头已有现成的系统,那么最好是逐步地切换到微服务之中。例如,您可以采用由Martin Fowler开发strangler模式。该模式保证了将单一的体系结构提升至微服务的过程中,您仍可使用并存的现有业务系统。

在这种模式下,您的关键任务系统不但能够得以维持,并且新的架构也会围绕着它被构建出来。随着时间的推移,旧系统会逐渐地被新架构所取代,而非一次性全部转换过去。

2.自动化模式

实施GitOps

为了优化平均恢复时间(MTTR,Mean Time to Recovery),您应该实施GitOps。

GitOps的运行依靠将Git(译者注:Git是一个开源的分布式版本控制系统)作为声明式基础架构和应用程序的“数据源(source of truth)”。当对于Git的更改发生时,自动化交付的pipeline会将变更部署到您的基础架构之中。

您的基础架构和应用程序代码不仅具有了数据源,而且在发生灾难时,您的开发团队还能够从Git中快速地恢复基础架构,从而将MTTR从小时级别降低到分钟级别。

有关GitOps的更多信息,请参阅《用拉式请求的各种操作》《GitOps:Kubernetes实现高速持续集成与持续交付(CI/CD)》

注重安全的自动化

在与大型团队协作和将各种自动化pipeline连到Kubernetes的时候,您需要重点考虑自己集群里的各种安全凭证。为了能将更新部署到群集之中,您必须将证书保存在某处。在理想情况下,这些证书应该保存在集群的内部。但是如果需要被放在外面的话,它们至少应该被保存在诸如Vault这样的库中。

推/拉式模式

由于您的持续集成能从持续交付中分离出来,因此拉式自动化pipeline提供了更好的安全性。如今大多数CI/CD工具都使用的是推送模式。基于推式意味着代码从CI系统开始经过pipeline,然后需要通过一系列编码脚本,或手动使用'kubectl'将变更推送到Kubernetes群集之中。总体而言,如果不小心使用的话,CI反而会成为您系统的一个入口。

像Weave Cloud的拉模式就依赖于两个关键的组件:一个是用于监控镜像注册表的部署性自动化器(Deploy Automator),另一个是位于群集之中,以维护其状态的部署性同步器(Deploy Synchronizer)。

由于Weave Cloud部署针对的是如下方面,因此拉式方法更为安全:

  • 基于角色访问控制(RBAC)的相关策略与安全性,仅执行Kubernetes所允许的操作。信任关系由群集所共享,并非被单独地掌握。
  • 本地绑定所有Kubernetes对象,并获悉操作是否已完成或需要重试。

不必每次都从头开始重建镜像

在通过pipeline去运行各种更新时,为了节省宝贵的时间,您不必每次都去重建镜像。您只需一次性构建容器的镜像,然后通过每个测试序列/环境将其“推广”出去。如果您使用的是GitOps,那么就可以在Git中对各种声明性配置文件进行更改,或者直接使用Weave Cloud部署的各种操作。

对发布进行解耦部署

在将产品发布给客户之前,请添加一个部署的阶段,以进行冒烟测试,甚至是一些更多类型的测试,如:蓝绿部署、金丝雀测试、或A/B测试。

值得注意的是:我们应当在概念上理解“部署”与“发布”之间的区别。部署是指软件已经通过了测试并被安装到了特定环境之中;而发布则是将这些更改最终真实地落实并推送到最终用户的手中。

衡量pipeline的成功

请建立并跟踪pipeline里的那些关键性的指标。您可以将开始自动化之前的情况和之后的结果做比较,主要包括如下方面:

  • 部署频率 - 每天完成的部署数量。
  • 变更的交付周期 - 部署一次变更所需要的交付时间。
  • 平均恢复时间(MTTR) - 在灾难发生时,恢复应用所需要的时间。
  • 变更失败率 - 以正常运行时间的百分比来表示宕机的时间。

3.持续交付的企业文化

创建一种开放且不抱怨的文化

请围绕着自动化过程增加企业透明度。通过允许开发人员犯错,从而激励他们勇于解决和纠正各种过程中所产生的偏差。一旦自动化被建立起来,开发人员需要对pipeline拥有完全的所有权,以便在测试失败发生时,代码变更能够被及时地进行回滚。

每个人都为构建承担责任

在完全的自动化pipeline模式下,任何人都应该能够去诊断并解决构建中出现的问题。这不仅能够产生更多自创的软件开发流程,还会促进整个组织内产生更好的团队协作。

最后的建议

众所周知,易于出错的手动式部署往往会增加软件发布的风险和成本,同时也会降低公司在其业务领域的竞争力。因此,虽然实施自动化的持续交付pipeline会是一项艰巨的任务,但它最终将被证明是企业值得付出的“阵痛”。

原文标题:Best Practices for Continuous Delivery ,作者:Anita Buehrle 

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

  1. 现代前端开发路线图:从零开始,一步步成为前端工程师
  2. 开发者福利:TensorFlow 中文社区论坛测试版正式上线
  3. Java 开发人员必知必会的 20 种常用类库和 API
  4. 微软发布Windows Template Studio 2.0 帮开发者更轻松创建应用
  5. 程序员也追风口:区块链开发范式
【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

C#高级编程(第4版)

C#经典名著!2006年最受读者喜爱的十大技术开发类图书!也是Wrox红皮书中最畅销的品种之一,从第一版开始就名满天下;其第3版被中华读书报...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊