DevOps--几种模式

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u014621467/article/details/82751773

目录

模式一

模式二

模式三


本文摘抄自:DevOps的概念与实践 

模式一

敏捷开发模式

 通常,在软件开发项目中,开发会用完所有计划的时间用于开发功能,这样会导致无法充分解决IT运维的问题,这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要原因。后果可能很严重,比如:不适当的定义和指定环境,无法重部署,代码和环境的不兼容等

按照敏捷的要求,在每个迭代结束后,我们就会发布能运行且可被部署的代码,通常时间为两周。我们将修改敏捷迭代周期策略,不仅仅只交付能运行且可被部署的代码,同时在每个迭代周期的早期,还必须准备好环境用于部署这些代码。建立一个自动化的环境创建流程,这种机制不仅仅只创建生产环境,也包含开发和QA环境。通过使环境早期即可用,开发和QA可以在统一稳定的环境中运行和测试代码,从而控制不同环境之间的差异。通过保持不同阶段尽可能小的差异,在生产部署之前,我们就能发现并修复代码和环境之间的互操作性问题。

理想情况下,部署机制是完全自动化的。

模式一:尽早让环境统一并可用,即将IT运维嵌入到开发中。

模式二

模式二的一个重要要素就是缩短和放大反馈回路,使得开发更贴近客户体验(包括IT运维和最终用户)

 模式二:将开发嵌入到运维中。

将开发嵌入到IT运维的问题升级链中,可以将他们放在三级支持中,甚至使开发对整个代码的部署成功负责。要么回滚,要么修复缺陷,直到服务恢复。

让开发看到他们的工作和变更带来的下游变化,激励开发以IT运维的视角来解决问题,从而达到一个全局的目标。

模式三

不够规范!

定义可重用且可跨多个项目的部署流程,敏捷方法里有一个很简单的解决方案:将部署的活动变成一个用户故事。

例如,为IT运维构建一个可重用的用户故事,叫做“部署到高可用环境”,这个用户故事定义了明确的构建环境的步骤、需要多长时间、需要哪些资源等。这些信息可以被项目经理用来集成部署内容到项目计划中去。

认识到有些特定的软件项目要求特别的环境,且不被IT运维官方支持,我们可以允许这些被生产允许的环境中的例外,但是被IT运维部门外面的人提供支持的。

环境标准化(可以减少生产差异、环境更一致、IT运维的支持和维护能力增加等),又能在允许的特殊情况下,提供业务需要的灵活性。

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试