【理论】软件开发流程扫盲：敏捷开发（XP、SCRUM）、DevOps（集成构建、CI/CD）

如何运���在工作环境进阶一个小level：当前公司采取的开发流程属于敏捷开发，基本一两周一个迭代，去新增一些小功能和解决一些bug。不过最高效的还是DevOps模式，学完相关技术，想想怎么运用在工作中

一、软件

与计算机系统操作有关的计算机程序、可能有的文件、文档及数据

二、软件开发流程的演变

（一）传统瀑布模型

1.瀑布模型特点

• 软件开发的各项活动严格按照线性方式进行
• 当前活动接受上一项活动的工作结果
• 当前活动的工作结果需要进行验证

  2.瀑布模型优缺点

  优点

  • 开发的各个阶段比较清晰
  • 强调早期计划及需求调查
  • 适合需求稳定的产品开发

    缺点

    • 由于开发模型是线性的，增加了开发的风险
    • 早期的错误可能要等到开发后期的阶段才能发现

      （二）敏捷开发模型（最快也得1周）

      1.XP - 极限编程（开发测试的要求很高，才能实施）

      （1）编程方法维度：简单设计、结对编程、测试驱动开发、重构

      简单设计：只要满足用户当下的需求，不需要太过高深完美的设计

      结对编程：两个人一起编程。同事A关注代码的细节，同事B关注整体的结构，且同事B对同事A进行代码的评审

      测试驱动开发：先写好测试用例代码，再编写程序代码，使程序代码在测试代码里测试通过

      重构：在“简单设计”上的优化。减少重复部分，增加可复用部分

      （2）小组实践维度：代码集体所有、编码标准、稳定高速的步伐、隐喻、持续集成

      代码集体所有：所有人都可以访问修改代码

      持续集成：“集成”的意思是指把多个人的代码合在一起。每次集成都需要进行一个自动化的构建来进行验证，其中包含自动化的测试（构建：把当前阶段的代码变成一个用户可使用的产品，如用户可安装的app文件）

      隐喻：以一个比喻的手法形象的描述需求，尽可能让团队的每个人都听懂。

      （3）交付和管理维度：小规模发布、计划游戏、完整的团队、现场客户

      小规模发布：一般1~3周（最常见的是2周）发布一个用户可以使用的版本

      计划游戏：计划现在要做哪些工作，之后要做哪些工作

      完整的团队、现场客户：开发和客户占据主要地位，测试主要通过自动化来实现

      2.SCRUM（发音：死磕rua母）

      SPRINT：冲刺，一个迭代的周期，一般为2~4周（2周最常见），期间会进行每日站会

      产品BACKLOG：以列表的形式展示项目所有需求的概要，并按照优先级排序

      SPRINT计划会议：计划实现哪些优先级最高的需求

      SPRINT BACKLOG：最后决定的这个迭代里要实现的需求

      潜在可交付产品增量：一个迭代完成了，会提交出一个完成了在这个迭代里需要完成的需求的产品，即包含了此次迭代的需求增量

      注：

      1.在每一次迭代周期结束后，还会有一个SPRINT评审会议，该会议展示此次迭代完成的功能

      2.在评审会议之后，在下一个SPRINT计划会议之前，还会再开一个SPRINT的回顾会议，对一整个迭代周期去进行复盘，哪些地方执行的好，哪些地方执行的不好，后面如何改进

      3.第1个迭代周期的测试阶段，可能会与第2个迭代周期的需求分析阶段重合

      3.敏捷模型总结

      • 增量迭代
      • 小步快跑（一般2周一个迭代）

        （三）DevOps开发模型（发音：戴ver哦噗死）

        开发、测试、运维需要紧密的合作，才能真正的做到DevOps

        1.DevOps 生命周期

        持续开发：开发持续编写功能代码→提交到仓库（Git、SVN）→构建，把代码打包到可执行文件（ant、maven）

        持续测试：使用一些自动化测试的工具（配合testng、Junit、unittest、pytest框架使用测试工具selenium、appium）对新功能进行测试，出最后的一个结果（测试成功，构建成功；测试失败，构建失败）

        持续集成：测试通过的新功能代码会和原先的代码进行一个合并，使用Jenkins进行一个持续集成的操作。“集成”的意思是指把多个人的代码合在一起。每次集成都需要进行一个自动化的构建来进行验证，其中包含自动化的测试（构建：把当前阶段的代码变成一个用户可使用的产品，如用户可安装的app文件）

        持续部署：测试通过的部署到服务器上（docker）让不同的环境一致

        持续监控：部署上线后，持续监控行为、性能（ELK Stack）

        2.DevOps 对发布的影响

        • 减少变更范围
        • 加强发布协调
        • 自动化

          3.CI/CD

          持续集成（Continuous integration，缩写为CI）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

          持续交付（Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

          4.CD 与 DevOps 的关系

          DevOps的范围更广，是软件交付过程所涉及的多个团队之间的合作，并且将软件交付的过程自动化。

          持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。

          DevOps可以是持续交付下的一个产物，持续交付的成果直接汇入 DevOps模型。