1.理论基础

本篇是基于公司内部的一次DevOps分享，PPT是自己准备的一些内容。


目前主流的开发模型相信大家都清楚，这边简单介绍一下：


•　瀑布开发模型：生命周期很长，一般会完整的走如下流程：需求调研->详细设计->编码->测试->部署->运维，且下一环节需要等上一环节完成后才可以继续进行，往往需求阶段和测试阶段会占据很长时间，且需求调研结束后很少再做修改，因此，在一个长周期的开发完成之后反馈给客户，往往会进行一次较大的修改和调整，后期修改成本及其大。


•　敏捷开发模型：这种开发模式以一种不断迭代的方式缩短开发周期，把一个整体大的需求分成若干小的需求，进行迭代开发，并将产品反馈给客户的时间缩短，不断从客户得到反馈，并且不断修改直至客户满意，这种方式大大缩短了客户和开发测试之间的距离，把修改的成本缩短到一个小需求的生命周期，节省了修改成本。但是并没有解决开发和运维之间的协同合作，因此，DevOps应运而生。


•　DevOps模式：该模式强调一个运维和开发不断沟通的能力环，在开发阶段我们沿袭敏捷的开发模式，在运维阶段，我们强调自动化的运维，并不断讲已经上线的产品中的问题反馈给开发，以进行问题修复。


我们可以看到，对于一个软件的生命周期，基本流程都类似，只是在各个阶段我们做了不同的优化，而且这种优化也是经历过考验的可以实施的最佳实践。

1.1 软件工程模型演变





2.什么是DevOps




那么什么是DevOps呢？有人认为DevOps是运维+开发，有人认为是自动化，也有人认为是Ias，当然，这些认识都是有其道理，也是DevOps中不可或缺的一部分，但大多都是盲人摸象，没有对DevOps有个整体的认识，对于DevOps的认识，


请转至第一章：[  /writer#/notebooks/34722020/notes/42259195]深入剖析DevOps系列（1）[/url]

1.2 谁应该关心DevOps？



3.Develop和Operation的历史问题


开发和运维人员素来就被一种叫做部门墙的隐形之墙所隔离，这种问题由来已久，


原因1：开发和运维的目标不一致，开发的目的是不断的增加新功能，不断完善需求，不断发布新版本，总之对于开发来说，唯一不变的就是变化，但是，对于运维来说，首要的问题是要求稳，因为一切问题的来源都是变化。


原因2：两个角色所在的部门考核标准不一样，对于开发来说，新开发一个需求考核就递增一点，是个累加的过程；而对于运维来说，即使将发布工作做的极致，起点也只是0，因为，这本来就是运维应该做的，一旦出了问题，便会从0开始递减，是个递减的过程。

1.2.1DevOps 是一角色



4.DevOps要解决的问题



DevOps首要解决的问题就是Develop和Operation间的这堵部门墙，一种模式就是借鉴敏捷开发的模型，将运维人员纳入到整个团队，之于团队的定义，就是有着共同目标的一群人


亚马逊有一种模式，叫做2 pizza team，用2个pizza就能搞定的Team定义为DevOps Team，当然，这个是一种抽象，目前最佳实践的DevOps team比例为1:4:1:1,即一个需求，4个开发，一个测试，一个运维，当然，可以根据不同公司的不同需求做一些调整。

1.2.2 DevOps 是一种工作方式





5.DevOps遇到的强力阻碍




对于现在很多公司来说，存在很明显的责任推脱问题，相互推诿，相互指责，屡见不鲜，对于DevOps乃至整个公司来说来说，这不是一种好的工作状态，所以DevOps强调信任，沟通，相互学习和责任共担。开发，测试和运维之间的各种活动都需要把其他人作为关键干系人，做到测试和运维了解需求，开发和运维了解测试，测试和运维了解开发等等，当然，了解并不是让开发去做测试的事情，或者运维去做开发的事情，我们强调的，是沟通和相互了解~

1.2.3 Devops是一种组织文化

1.2.4 DevOps 是一组技术/实践

1.2.4 DevOps 是一组技术/实践(1)

1.2.4 DevOps 是一组技术/实践(2)

1.2.4 DevOps 是一组技术/实践(3)

1.2.4 DevOps 是一组技术/实践(小结)

1.2.5 小结： 什么是 Devops

2.1DevOps in Cloud（AWS）

2.1.1DevOps in Cloud in AWS

2.1.1DevOps in Cloud in AWS

2.2AWS 持续集成（CI）模型

2.2.1CI – Code Commit

2.2.2CI – Code Build

2.2.3CI – Code Pipeline

2.3AWS持续集成（CD）模型

2.3.1CD – Elastic Beanstalk

2.3.2CD – OpsWorks

2.3.3CD – Cloud Formation

2.3.4CD - CodeDeploy

2.3.5CD – 小结

2.5Sample Pipeline in DevOps

1.理论基础

本篇是基于公司内部的一次DevOps分享，PPT是自己准备的一些内容。


目前主流的开发模型相信大家都清楚，这边简单介绍一下：


•　瀑布开发模型：生命周期很长，一般会完整的走如下流程：需求调研->详细设计->编码->测试->部署->运维，且下一环节需要等上一环节完成后才可以继续进行，往往需求阶段和测试阶段会占据很长时间，且需求调研结束后很少再做修改，因此，在一个长周期的开发完成之后反馈给客户，往往会进行一次较大的修改和调整，后期修改成本及其大。


•　敏捷开发模型：这种开发模式以一种不断迭代的方式缩短开发周期，把一个整体大的需求分成若干小的需求，进行迭代开发，并将产品反馈给客户的时间缩短，不断从客户得到反馈，并且不断修改直至客户满意，这种方式大大缩短了客户和开发测试之间的距离，把修改的成本缩短到一个小需求的生命周期，节省了修改成本。但是并没有解决开发和运维之间的协同合作，因此，DevOps应运而生。


•　DevOps模式：该模式强调一个运维和开发不断沟通的能力环，在开发阶段我们沿袭敏捷的开发模式，在运维阶段，我们强调自动化的运维，并不断讲已经上线的产品中的问题反馈给开发，以进行问题修复。


我们可以看到，对于一个软件的生命周期，基本流程都类似，只是在各个阶段我们做了不同的优化，而且这种优化也是经历过考验的可以实施的最佳实践。

1.1 软件工程模型演变





2.什么是DevOps




那么什么是DevOps呢？有人认为DevOps是运维+开发，有人认为是自动化，也有人认为是Ias，当然，这些认识都是有其道理，也是DevOps中不可或缺的一部分，但大多都是盲人摸象，没有对DevOps有个整体的认识，对于DevOps的认识，


请转至第一章：[  /writer#/notebooks/34722020/notes/42259195]深入剖析DevOps系列（1）[/url]

1.2 谁应该关心DevOps？



3.Develop和Operation的历史问题


开发和运维人员素来就被一种叫做部门墙的隐形之墙所隔离，这种问题由来已久，


原因1：开发和运维的目标不一致，开发的目的是不断的增加新功能，不断完善需求，不断发布新版本，总之对于开发来说，唯一不变的就是变化，但是，对于运维来说，首要的问题是要求稳，因为一切问题的来源都是变化。


原因2：两个角色所在的部门考核标准不一样，对于开发来说，新开发一个需求考核就递增一点，是个累加的过程；而对于运维来说，即使将发布工作做的极致，起点也只是0，因为，这本来就是运维应该做的，一旦出了问题，便会从0开始递减，是个递减的过程。

1.2.1DevOps 是一角色



4.DevOps要解决的问题



DevOps首要解决的问题就是Develop和Operation间的这堵部门墙，一种模式就是借鉴敏捷开发的模型，将运维人员纳入到整个团队，之于团队的定义，就是有着共同目标的一群人


亚马逊有一种模式，叫做2 pizza team，用2个pizza就能搞定的Team定义为DevOps Team，当然，这个是一种抽象，目前最佳实践的DevOps team比例为1:4:1:1,即一个需求，4个开发，一个测试，一个运维，当然，可以根据不同公司的不同需求做一些调整。

1.2.2 DevOps 是一种工作方式





5.DevOps遇到的强力阻碍




对于现在很多公司来说，存在很明显的责任推脱问题，相互推诿，相互指责，屡见不鲜，对于DevOps乃至整个公司来说来说，这不是一种好的工作状态，所以DevOps强调信任，沟通，相互学习和责任共担。开发，测试和运维之间的各种活动都需要把其他人作为关键干系人，做到测试和运维了解需求，开发和运维了解测试，测试和运维了解开发等等，当然，了解并不是让开发去做测试的事情，或者运维去做开发的事情，我们强调的，是沟通和相互了解~

1.2.3 Devops是一种组织文化

1.2.4 DevOps 是一组技术/实践

1.2.4 DevOps 是一组技术/实践(1)

1.2.4 DevOps 是一组技术/实践(2)

1.2.4 DevOps 是一组技术/实践(3)

1.2.4 DevOps 是一组技术/实践(小结)

1.2.5 小结： 什么是 Devops

2.1DevOps in Cloud（AWS）

2.1.1DevOps in Cloud in AWS

2.1.1DevOps in Cloud in AWS

2.2AWS 持续集成（CI）模型

2.2.1CI – Code Commit

2.2.2CI – Code Build

2.2.3CI – Code Pipeline

2.3AWS持续集成（CD）模型

2.3.1CD – Elastic Beanstalk

2.3.2CD – OpsWorks

2.3.3CD – Cloud Formation

2.3.4CD - CodeDeploy

2.3.5CD – 小结

2.5Sample Pipeline in DevOps