软件流程DevOps，版本管理工具Git，测试知识等

DevOps

1.软件危机背景：

落后的软件生产方式无法满足迅速增长的计算机软件需求，导致软件开发和维护过程中一系列的问题。于是诞生了软件工程的方法去解决软件危机。

2.软件工程的核心思想：

把其他行业和领域里的工程化经验借鉴过来，以系统性的、规范化的、可定量的工程化方法来开发和维护软件。包括相应的流程、工具、方法论等。

3.敏捷核心思想：

由于软件开发难以准确预测，工程化的思想和方法并不完全适用于软件开发，于是诞生了敏捷思想对软件工程进行纠偏。

敏捷软件开发宣言指出，个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。总之，右项有价值，但更偏于左项。

4.精益核心思想：

更关注流动效率而不是资源效率。不停地消除任何不增加价值的工作。

5.持续集成核心思想：

是一种软件开发实践，即团队成员经常集成他们的工作，每次集成通过自动化的构建（包括测试）来验证从而尽快检测出集成错误。例如一个软件开发6个月，然后集成测试2个月就一定不是持续集成。持续表示均匀、频繁；集成表示汇聚、测试。

6.持续交付核心思想：

是一种软件开发实践，令软件可以随时发布上线。为此需要持续地集成软件开发成果，构建可执行程序，并运行自动测试以发现问题，进而把可执行程序逐步推送到越来越像生产环境的各个测试环境中（并测试），以保证它最终可以在生产环境中运行。是持续集成的延伸（延伸到各类测试直到发布，中间就会牵扯到测试环境和生产环境如何管理、配置、部署，回滚，人工测还是自动化测等问题）。频繁程度小于持续集成。

7.DevOps起源和演化：

7.1.瀑布

是典型的预见性方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行，上一阶段的输出作为下一阶段的输入。大体分为需求分析、设计、编码、测试、维护几个阶段。缺点是只有在项目生命周期后期才能看到结果，尤其是不适应用户需求变化。

7.2.敏捷

由于软件开发难以准确预测，工程化的思想和方法并不完全适用于软件开发，于是诞生了敏捷思想对软件工程进行纠偏。

敏捷是强调轻量的过程方法论，强调拥抱变化而不是与之对抗。与客户亲密合作取代合同约定。多数都采用迭代/增量开发的过程模型。

敏捷软件开发宣言指出，个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。总之，右项有价值，但更偏于左项。

7.3.DevOps

软件交付模式发生变化是诞生背景。Dev（开发）团队关注把新功能实现并上线，Ops(运维包括测试)团队关注上线后运行的稳定性，两个团队需要协作。devops促进软件开发、技术运营和质量保障等部门间的沟通和协作。特点有：

• “大系统小做”，服务/微服务架构师快速创新的技术基础
• 小批量/小粒度频繁的发布和部署，平滑集中部署的风险
• 运营驱动开发，小步快跑，唯快不破，运营中持续开发，用开发构筑运营竞争力
• 自营+合营的运作模式，变“卖产品”为“卖服务”
• 打破研发和运营团队之间的界限。“自己开发，自己运营”
• 传统交付方式交付整系统测试整系统。devops模式交付以微服务为主，微服务独立发布。支持微服务独立开发、验证与上线。

8.devops三步工作法：

快速流动（持续交付流水线等）、快速反馈、持续学习与实验。

9.devops与软件技术的演进是相互促进的：

• 开发过程从：瀑布--敏捷--devops，
• 应用架构从：单体--分层--微服务，
• 部署与打包从：物理机--虚拟机--容器，
• 应用基础设施从：数据中心--托管服务--云

10.软件交付的效能度量指标

• 部署频率（越高越好）
• 变更前置时间（越小越好）
• 服务恢复时间（越快越好）
• 变更失败率（越低越好）

11.DevOps的追求目标：

• 效率要兼顾需求吞吐量和需求响应时长
• 质量不是越高越好，而是要适合业务
• 质量由问题出现量和问题修复时长共同决定
• 兼顾短期和长期

12.总结DevOps和CI/CD的定义：

• DevOps：Development & Operations，开发和运维。DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。
• CI：CONTINUOUS INTEGRATION，持续集成。指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。
• CD：CONTINUOUS DELIVERY，持续交付。侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。
• 持续部署：（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

版本控制工具Git

1.什么是版本控制：

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统，方便查看更改历史，备份以及恢复以前的版本，保证多人的协作不出问题。

2.版本控制的起源与历史：

• diff与patch是两个比较源码和补丁的工具，diff比较两个文件得出差异，patch是diff的反向操作，它通过一个文件和差异结果反推出另一个文件。
  • diff的用法：diff -u left.c right.c  
  • patch的用法：patch left.c diff.txt  、  patch -R right.c diff.txt
• RCS是最早期的本地版本控制工具
• CVS&SVN是集中式版本控制工具
• Git是分布式版本控制工具

3.集中式CVS&SVN与分布式git的差异

• 集中式工具记录差异，Git是记录快照。
• 集中式只有脆弱的中央库，Git有强壮的分布库。
• SVN不适合跨地域的协同开发，Git不适合Word等二进制文档的版本控制（解决方法：版本库按照目录拆分）

4.linux下安装git

4.1.包管理器方式安装：

• sudo aptitude install git、sudo aptitude install git-doc git-svn git-email gitk（Ubuntu、Debian的）
• yum install git、yum install git-svn git-email gitk （RHEL、Fedora、CentOS 等）

4.2.从源代码安装：

1. 访问Git的官方网站： http://git-scm.com/ 。下载Git源码包，例如：git-2.19.0.tar.gz。
2. 解压后进入目录，tar -jxvf git-2.19.0.tar.bz2、cd git-2.19.0、
3. 安装方法写在INSTALL文件当中，参照其中的指示完成安装。下面的命令将Git安装在 /usr/local/bin 中 make prefix=/usr/local all、sudo make prefix=/usr/local install
4. 安装Git文档（可选）make prefix=/usr/local doc info、sudo make prefix=/usr/local install-doc install-html install-info

自动补齐（bash-completion软件包提