任务背景

公司的集群架构已越来越robust(健壮), 但应用服务器上的代码升级和新产品的发布效率不高，甚至有代码发布到生产服务器后BUG太多，客户反应强烈的情况出现。

公司的产品项目从需求分析,设计,研发,代码测试到发布上线的流程有问题，开发者开发的代码提交后有BUG没有反馈，运维也没有在测试环境下做有效地压力测试, 都是导致问题的原因。

所以我们需要运用devops(开发与运维工作流有效结合)思路，通过CICD(持续集成 持续交付)来实现自动化的集成与交付工作。

CI/CD（Continuous Integration/Continuous Deployment）是一种软件开发实践，旨在通过自动化的方式频繁地构建、测试和发布软件。CI/CD 可以显著提高软件交付的速度和质量，使团队能够更快地响应市场变化和用户需求。

• CI（Continuous Integration，持续集成）：持续集成是一种开发实践，要求开发者频繁地将代码集成到主分支，并且每次集成都伴随着自动化的构建和测试。这种方法可以快速发现集成问题，确保代码库的稳定性。

• CD（Continuous Deployment/Continuous Delivery，持续交付/持续部署）：持续交付是在持续集成的基础上，将通过测试的代码自动发布到生产环境或用户环境。持续部署是持续交付的下一步，指的是代码在通过所有测试后自动部署到生产环境，几乎不需要人为干预。

任务要求

1, 使用git提交代码到仓库

2, 实现自动代码发布系统

任务拆解

1, 了解DevOps的发展历程与思想

2, 学会git版本控制

3, 会使用github公有仓库与gitlab私有仓库

4, 了解CICD

5, 使用jenkins实现自动发布

学习目标

• 了解DevOps的发展历程
• 了解版本控制
• 掌握git的安装
• 掌握git的基本使用

DevOps的发展历程

DevOps是一种实现Dev(开发)与Ops(运维)工作流有效联合的思想。

那么，我们为什么要了解什么是DevOps呢？因为我们下面所讲的课程内容最终的目的就是为了体现开发与运维有效结合方法，越是高级应用，越接近我们DevOps思想所阐述的做事方法。

首先我们先来了解一下软件开发层面从软件开发出现时起至今，都经历了些什么？

原始开发时代

时代特色：软件程序员（单一物种）能做到一专多能，是多面小能手。

软件程序员的公司那时还被称作实验室，程序员那时被叫做科学家。

为了开发出一套优秀的软件，程序员们必须深入了解他们需要的应用相关的所有问题。

他们必须清楚知道这个软件应用在什么场合，这个软件是必须在什么系统上运行。

本质上说，程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持。

随着技术发展，人类需要软件程序员在软件开发方面具备更快的速度、更全面的功能，以便获取更多的用户等

而软件程序员对自身的要求是一专多能，多面小能手，这样就制约了在软件开发方面的开发速度及添加更多功能的可能性。

当然人类不会允许这种情况出现的，如果因为一个软件程序员开发速度跟不上，那么就要想办法进行优化，把软件程序员的工作进行细化、分配。在分配的过程中，就逐渐衍生出了类软件程序员的新物种，例如：软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等。

随时新物种的诞生，被各物种划分的领域门头林立，各自为王，很少进行交流互动，只有在迫不得已的时刻才会进行沟通。

由于新物种之间的分隔，导致客户的项目开发过程中出现的问题一拖再拖，无法进行有效解决，更无法在交付日期进行准时交付，让客户付出了昂贵的开发代价，甚至项目以失败告终。

面对这种混乱的情况，有人想到了一种开发模式：瀑布开发。

瀑布开发时代

时代特色：各物种一专、多人瀑布流式协作

这是一个非常了不起的创意，因为它利用了不同团队的开发者们只在必须的时候才进行沟通的这个事实。当一个团队完成了他们的工作的时候，它就会和下游的团队进行交流并把任务进行往下传，如此一级接一级的传递下去，永不回首。

Analyse 分析 产品经理/项目经理/架构师

Design 设计 项目经理/ 架构师

Code 开发 高级程序员（主程） 开发人员 实习生

Test 测试 测试工程师（背锅侠）

Deploy 部署 部署工程师

Fix/Maintain 加固/维护

这种方式在一段时间内发挥了效用，但很快，一如既往，客户又开始提出更多的诉求。他们希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，甚至在很晚的时候还提出改需求这种丧心病狂的事情来。结果就是如大家有目共睹的事实一样，软件项目非常容易失败这个说法已经作为一个行业标准被人们所接受。

数据表明超过50%的项目最终都是以失败告终的。更可悲的是，在当时看来，人们对这种情况是束手无策。

值得庆幸的是，每一个时代总会有那么几个思想开放的英雄如漆黑中的萤火虫般冒出来。他们知道这些不同团队的开发者们必须要找到一个可以协同工作、进行交流、并且能够弹性的向客户保证对方将会拿到最优的解决方案的方式。这就是敏捷开发。

适合于比较成型的业务模型，适合于工业设计、制造行业都可以。

敏捷开发时代

时代特色：物种一专、多人有效沟通、 协作、 拥抱变化

最早可以追溯到1957年，伟大的约翰·冯·诺依曼和同行们的努力。但是我们最终却是等到2001年才收获到革命的果实，当时行业的十多个精英创造出了如今闻名世界的“敏捷宣言”。

敏捷宣言十二条原则：

1. 首要任务是通过尽早地、持续地、交付可评价的软件来使客户满意

2. 乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。

3. 频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。

4. 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

5. 围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。

6. 与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是：面对面的交谈。

7. 可使用的软件是进度的主要衡量指标。

8. 敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。

9. 为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。

10. 简洁，做工作量减法。

11. 最好的架构、需求和设计都源自自我组织的团队。

12. 团队应该定期反思如何能变得更有战斗力。

敏捷宣言好处

敏捷宣言是各物种间迈出各自领域很重要的第一步。这是在以往各物种很长的时间里隔阂后，第一次将不同的关键项目关系人连接在了一起。人们开始互相交流，进行基本的碰头会议，并开始不断的交流意见和看法。他们开始意识到他们是有着很多比想象中还多的共同点，客户也开始成为他们中的一员，而不再是像以往一样只是往项目砸钱然后开始求神拜佛祈求一切顺利如愿。

敏捷意味着开放和拥抱(需求)改变。但是，如果改变过多的话，人们就很难专注到最终的目标和交付上来。

此时精益软件开发就开始破土而出了。

精益开发时代

时代特色：精益求精

软件开发行业向软件之外的行业进行学习，目的是为了进一步减少项目风险，实现快速交付。

精益开发思想是从丰田汽车生产系统借鉴而来的，把他们的精益生产经验应用到软件开发上面。

精益7原则：

1. 杜绝浪费

   通过杜绝浪费，达到发挥资源的效率。

2. 内建质量

   质量把关,提升客户对产品整体质量良好感受。

3. 增强学习能力

   通过轮岗方式使得员工取得多种工作技能。

4. 延迟决策（尽量延迟决策）

   以不变，应万变；根据事实而非假设来做决策。

5. 快速发布

   越早获得客户反馈，越早安排开发事项；越短开发周期，越快从市场获取实时信息，为应变市场变化获取时间。

6. 授权与尊重

   让团队成员知道工作全貌；团队领导者要有支持和帮助，克服困难，维持团队合作默契。

7. 系统思考

鼓励人与人之间沟通，促进探讨如何生产最好的产品和服务，从而避免局部性思考带来的整合时出现相依性的问题。

将这些放到敏捷开发上去的话，精益原则就能让人们在从精神上关注做正确的事情，同时还能够让整个开发流程拥有足够的弹性。

一旦敏捷和精益软件开发被软件开发团队采纳，那么下一步就是把这一套原则应用到IT团队上来。把IT也纳入到整体战略上，这就是我们前面给前面给大家提到的DevOps思想。

DevOps

软件开发团队成员一般会包括项目经理，系统架构师、前端开发者，后端开发者，测试工程师，网络工程师，运维工程师等。软件先由后端开发者，前端开发者进行开发，当软件开发完成，需要部署时，软件会通过自动化手段达到系统架构师，运维工程师等这些运维人员的手上，由运维人员进行部署、发布即可。

如何让软件在开发、测试、运维及最终发布之间进行有效的流动，这就是DevOps所要关注的重点。

DevOps是整个IT架构实施中使用敏捷开发及精益原则的结果，利用精益原则可以使用开发与运维无缝结合。

DevOps是一种文化，一种理念，是一种把开发（Dev）、测试（Test）、运维（Ops）及最终发布（CR）工作流进行联合的思想。

利用DevOps思想工作的三种方式及实践方法

第一种：系统思考

强调全局优化，而非局部改进。 大到部门职能划分（例如研发部和运维部门），小到个人（开发和系统工程师）。

这种方式将关注点放在整个业务价值流上。换句话说，整个团队应该关注在从需求被定义到开发，再到运维这个过程，直到价值被以服务的形式交付给最终用户。

将这种方式带到实践中的产出便是永远不要将已知的缺陷传递到下游工作，永远不要为了局部优化影响了整体价值流交付，总是为了增加价值流动努力，永远追求对架构的深刻理解。

实践方法

• 所有环境和代码使用同一个仓库，将软件包纳入版本管理

• 团队共同决定发布流程

• 保持 DEV、TEST、PRODUCTION 环境的一致性

• 自动化回归测试

• 小步提交，每日部署；而不是一次部署大量变更

• 更快、更频繁发布

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

第二种：放大反馈环

创建从开发过程下游至上游的反馈环。几乎所有的流程改进都是为了从时间上缩短和从覆盖面上放大反馈循环，从而可以不断地进行必要的改正。

产出是关注到价值流中所有涉及到的用户，包括价值流内部和外部的，缩短和放大反馈回路，并且可以随时定位到需要改进的地方。

实践方法

• 代码审查及配置变更检查

• 有纪律的自动化测试，使许多同时的小型敏捷团队能够有效地工作

• 尽早设置监控预警

• 修复 bug 为团队最高优先级

• 团队成员之间高度互相信任

• 团队之间保持沟通和良好合作

第三种：持续实验和学习的文化

提倡持续做试验，承担风险、从失败中学习；通过反复实践来达到精通。

我们需要实验和冒着失败的风险，及时不断地尝试将我们置于一个危险的境地，我们要通过反复试错来掌握使我们远离危险的技能。

实践方法

• 对服务器正在承载的业务进行故障模拟，把人工错误引入系统中，加强系统的健壮性

• 生产中部署一台服务器用于进行故障训练，以便练习服务器经常处于失效状态下的故障恢复能力。

DevOps清单

团队有没有按照DevOps的思想去工作，可以按以下清单进行对照即可

• 开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。
• 从一个团队流到另一个团队的工作都能够得到高质量的验证
• 工作没有堆积，所有的瓶颈都已经被处理好。
• 开发团队没有占用运维团队的时间，因为部署和维护都是处于同一个时间段。
• 开发团队不会在周五下午5点后把代码交付进行部署，剩下运维团队周末加班加点部署
• 开发环境标准化，运维人员可以很容易將之扩展并进行部署
• 开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。
• 每个团队之间的通信线路都很明确
• 所有的团队成员都有时间去为改善系统进行试验和实践
• 常规性的引入(或者模拟)缺陷到系统中来并得到处理。每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为日常工作的一部分，且处理方式是已知的

版本控制概念⭐⭐⭐⭐⭐

什么是版本?

答: centos6.9,centos7.3,centos7.5这些属于操作系统的版本。

nginx-1.10,nginx1.14这些属于软件的版本。

一个配置文件或一个代码文件被多次修改,也会有对应的版本。

<major>.<minor>.<micro>

版本格式中的三位分别表示：

• 主版本(major)升级，表示API不兼容，或者架构调整。

• 次版本(minor)升级，表示增加了新功能，或者大的优化。

• 小版本(micro)升级，表示修复问题，或者小的优化。

1. Alpha版本

* Alpha版本是软件的初始开发阶段版本。

* 通常只供内部测试使用，可能包含较多的缺陷和不完善的功能。

* 此阶段的目的是进行系统性的测试和评估，以发现并修复存在的问题。

2. Beta版本

* Beta版本是软件开发过程中的一个测试阶段版本。

* 该版本相较于Alpha版本有了明显的改进，但仍然可能存在一些缺陷需要测试发现。

* Beta版本会邀请一定规模的外部用户参与测试，收集用户反馈以进一步改进软件。

3. Release版本

* Release版本是软件的最终发布版本。

* 此版本意味着软件已经通过了一系列的测试和修正，功能完善且稳定。

* 该版本会面向广大用户公开下载和使用，通常不会再有重大的功能改动，主要是进行一些小bug的修复和性能优化。

什么是版本控制?

版本控制软件提供完备的版本管理功能，用于存储、追踪目录（文件夹）和文件的修改历史，是软件开发者的必备工具，是软件公司的基础设施。版本控制软件的最高目标，是支持软件公司的配置管理活动，追踪多个版本的开发和维护活动，及时发布软件。

常见的版本控制系统及比较

cvs,svn,git都是版本控制系统

腾讯 tapd, 百度 icafe, 阿里 云效等也是一站式的版本控制。

cvs和svn都是==集中式==版本控制系统,而git是==分布式==版本控制系统。

总结

• 集中式版本控制系统必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，呵呵。分布式版本控制系统可以不连网工作, 因为版本库就在你自己的电脑上。

• 集中式版本控制系统如果中央服务器挂了,就完蛋了。分布式版本控制系统可以没有中央服务器，每个人的电脑上都是一个完整的版本库，可靠性高。分布式版本控制系统也可以有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。