当前位置:新闻中心行业动态 → 正文

Klaverblad保险公司的持续交付

责任编辑:editor004 作者:Ben Linders |来源:企业网D1Net  2016-10-17 12:16:51 本文摘自:INFOQ

Klaverblad的首席信息官Kim Van Wilgen认为,持续交付应被视为敏捷项目,因为它可以将部署自动化。你必须加快小步骤,通过小的交付和快速解决问题来赢得信任。她在SwanseaCon 2016大会上就持续交付进行了发言。InfoQ通过问答、摘要和文章全面报道此次会议。

klaverblad公司是一家位于荷兰的中型规模保险公司。这家公司最初使用的中央处理机和编程是用Cobol完成。随着时间推移软件变得越来越难以修改,无法满足业务需求。于是,公司决定一切从头开始,在新领域重新启动。

Van Wilgen说:由于全新开发一套IT系统工程量浩大,因此必须要以正确的方式进行。但受公司规模的限制,我们只能用较小的团队来实现。她继续说道,这需要创新软件开发的方式。他们决定采用敏捷、DevOps、持续交付和微服务为基础的软件开发方式。

klaverblad决定应用敏捷技术是因为他们想快速地为他们的客户创造价值,并尽早获得关于实际使用经验的真实反馈。他们想要每日部署。然而,手动交付容易出错,很难做到每日部署。分别部署超过200项微服务,必须依赖自动化。你不能手动检查200个部分,Van Wilgen说。这就是为什么我们需要持续交付和DevOps,Van Wilgen解释到。

Van Wilgen说,有很好的理由去努力达成持续交付。当你交付的越多,你的测试就可以变得越轻松;生产中的快速反馈能帮助你马上发现和解决问题。持续交付也让快速恢复成为可能,如果发生意外,你能将损失限制到最小程度。你能做更小的改变,使之更容易实现。而且你不需要软件用户提需求,因为IT技术的变化小而直观。这也激发了团队的工作动力,因为他们知道用户很快就会使用他们开发的软件。最后,通过测试和质量指标的全面自动化以及最佳实践,软件的质量会得到提高。

Van Wilgen解释说,要变得敏捷,Klaverblad的文化必须随之改变。这种变化可以通过引入新的做法来实现,而工具又会推动这些做法。他们决定开始为他们的开发人员和测试人员提供新的工具,但结果并不像预期的那样。测试结果不完整,几乎没有任何分支,监测和日志记录也不足。他们需要不同的方法。

Van Wilgen建议如果开始了持续交付,你就应该把它看做自动化部署的敏捷项目。写一个待做事情的备忘录,一步步的提高能力,优先次序,确定最少量的可行产品,并设置每个阶段,及在相应阶段提交一部分成果。

Klaverblad采用持续交付成熟度模型来管理他们的持续交付过程:

这种成熟度模型在你的公司采用持续交付时,为你提供需要考虑的关键框架和观点。

持续交付成熟度模型包括采用特定的工具、原则、方法和实践。我们把它们分为五大类别:文化、组织与设计、架构与构建、部署与测试、验证与信息,还可以加上报告。上面的分类方法遵循自然成熟度过程,按这样的过程去规划持续交付,将会为你可持续发展的快速转型奠定坚实的基础。

作为首席信息官,Van Wilgen是持续交付项目产品负责人。她决定需要做什么。整个公司各个团队都有人为这个这个项目工作;这是团队的努力,Van Wilgen说。

持续交付是协作,是一起工作。你必须大量学习知识以实现持续交付,所以要确保你有时间做这些事。Van Wilgen说明了他们如何把公司建设成为学习型公司:他们把团队变为DevOps团队,并提供指导,人们可以从行会、黑客马拉松和知识活动中互相学习。

Van Wilgen说持续部署和微服务验收后立即部署是可行的,但是如果你需要延期微服务的交付,事情就变得比较困难。比如当一个功能被拒绝,或如果你由于产品营销原因想推迟时,这种事情就会发生。一些微服务的更改将要交付,而其他微服务的更改的交付要被延迟。在这种情况下,你正在交付的产物是不同于已在你的建立的发布管道的不同阶段完成了测试的东西。

你不能测试所有版本的微服务可能的组合,这有太多了。Van Wilgen解释了他们目前的做法:当功能做好,你可以直接交付的时候即时交付,对可能需要晚点交付的事项做一个功能分支或切换。这样你会发现原来大部分功能都可以立即交付;Van Wilgen解释了他们如何“挑选”需要不同解决方案的功能和接下来决定如何为它们做集成测试。

你们公司准备好持续交付了吗?Van Wilgen认为,大部分公司都没有;他们想要但并没有对此进行思考。他们期待当出错时有一揽子回退解决方案。他们希望看到手动用户验收测试。他们还是想要用户提出需求、提供文档并沟通需要做的改动。这就是每日交付放缓的主要原因。因此你需要管理这些利益相关者的需求。你要能解释你不需要回退计划:通过持续交付,当出错时你可以马上做出新的交付,以此来解决问题,Van Wilgen说。另外,你必须告诉他们,做小更改时,不需要用户来提出需求。

你必须要加快速度,小步快跑,通过小的交付和快速解决问题来赢得信任,Van Wilgen说。强调持续交付成为重中之重。展示快速成果,强调快速交付到生产环境所能带来的价值。

如果没有质量把控,你不能做持续交付,Van Wilgen说。Klaverblad做代码审查、单元测试、回归测试、集成测试,以及自动和手动的用户验收测试。他们优先做测试,并决定先做什么,后做什么。发现主要错误的测试先进行,并进行一些烟雾测试以快速找到回归错误。这些小的测试将快速为开发者提供反馈。当这些测试都通过之后,那么在随后的步骤中,将进行更广泛深入的测试以充分检测更改。Van Wilgen表示,产品所有者和测试人员一起工作,输入和批准自动用户验收测试。

持续交付关键在于技术和人,Van Wilgen说。IT和企业应该共同努力,考虑项目里不同功能的优先级和一致性提交。

查看英文原文:Continuous Delivery at Klaverblad Insurance

关键字:WilgenKlaverblad

本文摘自:INFOQ

x Klaverblad保险公司的持续交付 扫一扫
分享本文到朋友圈
当前位置:新闻中心行业动态 → 正文

Klaverblad保险公司的持续交付

责任编辑:editor004 作者:Ben Linders |来源:企业网D1Net  2016-10-17 12:16:51 本文摘自:INFOQ

Klaverblad的首席信息官Kim Van Wilgen认为,持续交付应被视为敏捷项目,因为它可以将部署自动化。你必须加快小步骤,通过小的交付和快速解决问题来赢得信任。她在SwanseaCon 2016大会上就持续交付进行了发言。InfoQ通过问答、摘要和文章全面报道此次会议。

klaverblad公司是一家位于荷兰的中型规模保险公司。这家公司最初使用的中央处理机和编程是用Cobol完成。随着时间推移软件变得越来越难以修改,无法满足业务需求。于是,公司决定一切从头开始,在新领域重新启动。

Van Wilgen说:由于全新开发一套IT系统工程量浩大,因此必须要以正确的方式进行。但受公司规模的限制,我们只能用较小的团队来实现。她继续说道,这需要创新软件开发的方式。他们决定采用敏捷、DevOps、持续交付和微服务为基础的软件开发方式。

klaverblad决定应用敏捷技术是因为他们想快速地为他们的客户创造价值,并尽早获得关于实际使用经验的真实反馈。他们想要每日部署。然而,手动交付容易出错,很难做到每日部署。分别部署超过200项微服务,必须依赖自动化。你不能手动检查200个部分,Van Wilgen说。这就是为什么我们需要持续交付和DevOps,Van Wilgen解释到。

Van Wilgen说,有很好的理由去努力达成持续交付。当你交付的越多,你的测试就可以变得越轻松;生产中的快速反馈能帮助你马上发现和解决问题。持续交付也让快速恢复成为可能,如果发生意外,你能将损失限制到最小程度。你能做更小的改变,使之更容易实现。而且你不需要软件用户提需求,因为IT技术的变化小而直观。这也激发了团队的工作动力,因为他们知道用户很快就会使用他们开发的软件。最后,通过测试和质量指标的全面自动化以及最佳实践,软件的质量会得到提高。

Van Wilgen解释说,要变得敏捷,Klaverblad的文化必须随之改变。这种变化可以通过引入新的做法来实现,而工具又会推动这些做法。他们决定开始为他们的开发人员和测试人员提供新的工具,但结果并不像预期的那样。测试结果不完整,几乎没有任何分支,监测和日志记录也不足。他们需要不同的方法。

Van Wilgen建议如果开始了持续交付,你就应该把它看做自动化部署的敏捷项目。写一个待做事情的备忘录,一步步的提高能力,优先次序,确定最少量的可行产品,并设置每个阶段,及在相应阶段提交一部分成果。

Klaverblad采用持续交付成熟度模型来管理他们的持续交付过程:

这种成熟度模型在你的公司采用持续交付时,为你提供需要考虑的关键框架和观点。

持续交付成熟度模型包括采用特定的工具、原则、方法和实践。我们把它们分为五大类别:文化、组织与设计、架构与构建、部署与测试、验证与信息,还可以加上报告。上面的分类方法遵循自然成熟度过程,按这样的过程去规划持续交付,将会为你可持续发展的快速转型奠定坚实的基础。

作为首席信息官,Van Wilgen是持续交付项目产品负责人。她决定需要做什么。整个公司各个团队都有人为这个这个项目工作;这是团队的努力,Van Wilgen说。

持续交付是协作,是一起工作。你必须大量学习知识以实现持续交付,所以要确保你有时间做这些事。Van Wilgen说明了他们如何把公司建设成为学习型公司:他们把团队变为DevOps团队,并提供指导,人们可以从行会、黑客马拉松和知识活动中互相学习。

Van Wilgen说持续部署和微服务验收后立即部署是可行的,但是如果你需要延期微服务的交付,事情就变得比较困难。比如当一个功能被拒绝,或如果你由于产品营销原因想推迟时,这种事情就会发生。一些微服务的更改将要交付,而其他微服务的更改的交付要被延迟。在这种情况下,你正在交付的产物是不同于已在你的建立的发布管道的不同阶段完成了测试的东西。

你不能测试所有版本的微服务可能的组合,这有太多了。Van Wilgen解释了他们目前的做法:当功能做好,你可以直接交付的时候即时交付,对可能需要晚点交付的事项做一个功能分支或切换。这样你会发现原来大部分功能都可以立即交付;Van Wilgen解释了他们如何“挑选”需要不同解决方案的功能和接下来决定如何为它们做集成测试。

你们公司准备好持续交付了吗?Van Wilgen认为,大部分公司都没有;他们想要但并没有对此进行思考。他们期待当出错时有一揽子回退解决方案。他们希望看到手动用户验收测试。他们还是想要用户提出需求、提供文档并沟通需要做的改动。这就是每日交付放缓的主要原因。因此你需要管理这些利益相关者的需求。你要能解释你不需要回退计划:通过持续交付,当出错时你可以马上做出新的交付,以此来解决问题,Van Wilgen说。另外,你必须告诉他们,做小更改时,不需要用户来提出需求。

你必须要加快速度,小步快跑,通过小的交付和快速解决问题来赢得信任,Van Wilgen说。强调持续交付成为重中之重。展示快速成果,强调快速交付到生产环境所能带来的价值。

如果没有质量把控,你不能做持续交付,Van Wilgen说。Klaverblad做代码审查、单元测试、回归测试、集成测试,以及自动和手动的用户验收测试。他们优先做测试,并决定先做什么,后做什么。发现主要错误的测试先进行,并进行一些烟雾测试以快速找到回归错误。这些小的测试将快速为开发者提供反馈。当这些测试都通过之后,那么在随后的步骤中,将进行更广泛深入的测试以充分检测更改。Van Wilgen表示,产品所有者和测试人员一起工作,输入和批准自动用户验收测试。

持续交付关键在于技术和人,Van Wilgen说。IT和企业应该共同努力,考虑项目里不同功能的优先级和一致性提交。

查看英文原文:Continuous Delivery at Klaverblad Insurance

关键字:WilgenKlaverblad

本文摘自:INFOQ

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^