1 软件开发流程--发展过程
# 传统的软件开发流程
软件开发 软件测试 软件运维
规划 代码 构建 测试 发布 部署 维护
Plan Code Build Test Releas Deloy Operate
# 软件生命周期模型
# 1.瀑布模型 (瀑布式开发) Waterfall 属于理想化状态的开发 单体架构
需求 --->设计 --->开发 --->测试 --->部署
简而言之：就是等一个阶段所有工作完成之后，再进入下一个阶段
# 2.敏捷模型 (敏捷开发) Agile Development 分布式架构
是一种能应对快速变化需求的软件开发能力
简而言之：将整个项目的开发，拆分成小的模块，开发一个 就测试一个
# 两者对比：
敏捷开发 大幅提升了软件开发的效率和版本更新的速度
可以帮助更快地发现问题，产品更快地交付到用户手中
同时，用户有新的需求变动时，能快速的响应处理
# 3.DevOps (自动化开发部署) 微服务架构
2 DevOps概念
# 背景
上述两者模型，提升效果仅限于开发测试环节 与运维无关
# 开发和运维的重心不同
开发重建设 升级迭代
运维重维护 稳定运行
# 定义
DevOps 是一组过程、方法与系统的统称，
用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps 来自于 Development 和 Operations 的组合
突出重视软件开发人员和运维人员的沟通合作
通过自动化流程来使得软件构建、测试、发布，更加快捷、频繁和可靠
DevOps 可以用一个公式表达：
文化观念的改变 + 自动化工具 = 不断适应快速变化的市场
# 强调：
DevOps 是一个框架，是一种方法论
并不是一套工具，包括一系列的基本原则和实践。
其核心价值在于以下两点：
更快速地交付, 响应市场的变化
更多地关注业务的改进与提升
3 CI/CD
3.1 持续集成 CI
# 集成
指的是程序员在其本地计算机上开发的代码（包括更新或添加新特性）集成到代码库中
# 持续集成 Continuous integration （CI）
随时随地将代码合并，通常每个成员每天至少集成一次
每次集成，系统就会通过自动构建应用(包括编译，发布，自动化测试)
并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改
# 持续集成的好处主要有两个:
1.快速发现错误
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
2.防止分支大幅偏离主干
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成
# 持续集成的目的
就是让产品可以快速迭代，同时还能保持高质量
核心措施是代码集成到主干之前，必须通过自动化测试
只要有一个测试用例失败，就不能集成
3.2 持续交付 CD
# 持续交付 Continuous delivery（CD）
持续交付 是在持续集成的基础上，
将集成后的代码部署到更贴近真实运行环境的「类生产环境」中（production-like environments）
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）
都涉及测试自动化和代码发布自动化
在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中
# 强调
持续交付可以看做是，持续集成的下一步
不管软件怎么更新，软件是可以随时随地可以交付的
3.3 持续部署 CD
# 持续部署 Continuous deployment（CD）
持续部署则是在持续交付的基础上，自动化把交付好的代码部署到生产环境的过程
持续部署的目标是，代码在任何时候都是可以部署的，可以进入生产阶段。
持续部署的前提是，能自动完成测试、构建、部署等步骤
3.4 CI、CD的一般流程
根据持续集成的设计，代码从提交到生产，整个过程有以下几步
# 提交
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)
# 测试（第一轮）
代码仓库对commit操作配置好钩子(hook)，只要提交代码或者合并进主干，就会跑自动化测试
# 构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了
交付后，就先进行构建(build)，再进入第二轮测试
# 构建指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等
# 常用构建工具如下: jeknins、Travis、codeship等
# 测试（第二轮）
构建完成，就要进行第二轮的测试
如果第一轮已经涵盖了所有测试内容，可以省略第二轮，当然，构建步骤也要移到第一轮测试前面
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试
所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑
# 部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）
将此版本的所有文件打包（tar filename.tar *）存档，发到生产服务器
生产服务器将打包文件，解包成本地文件，再将运行路径的符号链接(symlink)指向该目录，
然后重新启动应用，进行部署
# 部署工具有：Ansible、SaltStack等
# 回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果
最简单的做法就是修改一下符号链接，指向上一个版本的目录
4 DevOps落地
4.1 自动化流程
# 落实DevOps的指导思想
高效的协作和沟通
自动化流程和工具
迅速敏捷的开发
持续交付和部署
不断学习和创新
# 实现自动化流程
1.提交
工程师将代码在本地测试后，提交到版本控制系统 如：Git代码仓库中
2.构建
持续整合系统(如:Jenkins CI) 在检测到版本控制系统更新时，便自动从Git代码仓库里拉取最新的代码，进行编译、构建
3.单元测试
Jenkins完成编译构建后，会自动执行指定的单元测试代码
4.部署到测试环境
在完成单元测试后，Jenkins可以将应用程序部署到与生产环境相近的测试环境中，进行测试
5.预生产环境测试 # 有些公司没有这个预生产环境 测试环境直接到生产环境
在预生产测试环境里，可以进行一些最后的自动化测试
eg：使用Appium自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。
6.部署到生产环境
通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里
# 灰度更新 (红蓝部署)：
先更新部分用户的软件，等到他们使用没有问题后，再逐渐的将访问流量从旧版本切换到新版本
如果在流量转移的过程中遇到了任何问题，可以随时回滚，保证整个系统可以持续提供服务
4.2 DevOps技术栈工具
标注 '*' 为常使用的
# 项目管理(PM) 软件
Jira # 收费 贵 适合1000人以上 国内无服务团队、无服务器
禅道 * # 收费 高性价比 国内唯一开源版 原厂服务
# 代码仓库管理(SCM)
GitHub
GitLab * # 开源 自己搭建GitLab平台
# 构建工具 自动化构建脚本：自动把代码编译成可执行文件 下面都是Java语言打包
Ant
Gradle
maven *
# 持续集成(CI)工具：
Jenkins * # 基于Java开发的持续集成工具，
结合上两个，配置一套流水线
自动把代码从远程仓库部署到测试环境，部署到生产环境
# 虚拟机与容器化
VMware
VirtualBox
Docker *
# 容器编排：Kubernetes K8s
# 自动化测试
Appium # 针对移动端app测试
Selenium # 针对网页端网页测试
Mock 测试 # 模拟测试 含单元测试、接口测试等
JMeter * # 性能压力测试
# 自动化运维工具/配置管理工具 批量执行1inux命令
Ansible (python编写) : 批量管理主机 是调用ssh连接 无客户端 # 主机很多，性能差
saltstack (python编写): 批量管理主机 是采用C/S架构 有客户端 # 适合主机很多的情况
# 监控管理工具
系统监控：
zabbix (php编写)
Prometheus (go编写) * # 对容器支持度比较高
日志分析系统：ELK
# 日志采集解析工具Logstash、日志的存储和检索Elasticsearch、分析可视化平台Kibana 三部分组成。
########## 其他工具
# 服务注册与发现： 针对微服务架构中
Zookeeper、etcd、Consul（注册中心）
# 性能监控
APPDynamics、new relic、Splunk
# 预警
自己写钉钉或邮件通知
