目录
本文摘抄自：DevOps的概念与实践
模式一
敏捷开发模式
通常，在软件开发项目中，开发会用完所有计划的时间用于开发功能，这样会导致无法充分解决IT运维的问题，这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要原因。后果可能很严重，比如：不适当的定义和指定环境，无法重部署，代码和环境的不兼容等
按照敏捷的要求，在每个迭代结束后，我们就会发布能运行且可被部署的代码，通常时间为两周。我们将修改敏捷迭代周期策略，不仅仅只交付能运行且可被部署的代码，同时在每个迭代周期的早期，还必须准备好环境用于部署这些代码。建立一个自动化的环境创建流程，这种机制不仅仅只创建生产环境，也包含开发和QA环境。通过使环境早期即可用，开发和QA可以在统一稳定的环境中运行和测试代码，从而控制不同环境之间的差异。通过保持不同阶段尽可能小的差异，在生产部署之前，我们就能发现并修复代码和环境之间的互操作性问题。
理想情况下，部署机制是完全自动化的。
模式一：尽早让环境统一并可用，即将IT运维嵌入到开发中。
模式二
模式二的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验（包括IT运维和最终用户）
模式二：将开发嵌入到运维中。
将开发嵌入到IT运维的问题升级链中，可以将他们放在三级支持中，甚至使开发对整个代码的部署成功负责。要么回滚，要么修复缺陷，直到服务恢复。
让开发看到他们的工作和变更带来的下游变化，激励开发以IT运维的视角来解决问题，从而达到一个全局的目标。
模式三
不够规范！
定义可重用且可跨多个项目的部署流程，敏捷方法里有一个很简单的解决方案：将部署的活动变成一个用户故事。
例如，为IT运维构建一个可重用的用户故事，叫做“部署到高可用环境”，这个用户故事定义了明确的构建环境的步骤、需要多长时间、需要哪些资源等。这些信息可以被项目经理用来集成部署内容到项目计划中去。
认识到有些特定的软件项目要求特别的环境，且不被IT运维官方支持，我们可以允许这些被生产允许的环境中的例外，但是被IT运维部门外面的人提供支持的。
环境标准化（可以减少生产差异、环境更一致、IT运维的支持和维护能力增加等），又能在允许的特殊情况下，提供业务需要的灵活性。