敏捷开发，持续集成/交付/部署, DevOps总结
文章目录
- 敏捷开发入门教程
-
- 一、迭代开发
- 二、增量开发
- 三、敏捷开发的好处
-
- 3.1 早期交付
- 3.2 降低风险
- 四、如何进行每一次迭代
- 五、敏捷开发的价值观
- 六、十二条原则
- 七、参考链接
- 持续集成/交付/部署
-
- 一、概念
- 二、持续交付
- 三、持续部署
- 四、流程
-
- 4.1 提交
- 4.2 测试（第一轮）
- 4.3 构建
- 4.4 测试（第二轮）
- 4.5 部署
- 4.6 回滚
- 五、参考链接
- DevOps 入门指南
-
- 什么是DevOps
- Devops 的好处与价值
- Devops与持续集成
- DevOps 的技术栈与工具链
- DevOps 最佳实践
- DevOps = Culture + Tools
- 敏捷，持续集成/持续交付, DevOps 三者的区别
敏捷开发入门教程
已剪辑自: https://www.ruanyifeng.com/blog/2019/03/agile-development.html
敏捷开发（agile development）是非常流行的软件开发方法。据统计，2018年90%的软件开发采用敏捷开发。
但是，到底什么是敏捷开发，能说清的人却不多。本文尝试用简洁易懂的语言，解释敏捷开发。
一、迭代开发
敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。
那么什么是"迭代开发"呢？迭代的英文是 iterative，直译为"重复"，迭代开发其实就是"重复开发"。
对于大型软件项目，传统的开发方式是采用一个大周期（比如一年）进行开发，整个过程就是一次"大开发"；迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤。
举例来说，SpaceX 公司想造一个大推力火箭，将人类送到火星。但是，它不是一开始就造大火箭，而是先造一个最简陋的小火箭 Falcon 1。结果，第一次发射就爆炸了，直到第四次发射，才成功进入轨道。然后，开发了中型火箭 Falcon 9，九年中发射了70次。最后，才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发，它可能直到现在还无法上天。
**迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。**开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
二、增量开发
迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代，哪个任务在这个迭代，哪个任务在下个迭代？这时，一般采用"增量开发"（incremental development）划分迭代。
所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。
举例来说，房产公司开发一个10栋楼的小区。如果采用增量开发的模式，该公司第一个迭代就是交付一号楼，第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基，第二个迭代建好每栋楼的骨架，第三个迭代架设屋顶…
增量开发加上迭代开发，才算真正的敏捷开发。
三、敏捷开发的好处
3.1 早期交付
敏捷开发的第一个好处，就是早期交付，从而大大降低成本。
还是以上一节的房产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。
敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。
3.2 降低风险
敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。
请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？
对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。
由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。
四、如何进行每一次迭代
虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。
具体来说，每次迭代都必须依次完成以下五个步骤。
- 需求分析（requirements analysis）
- 设计（design）
- 编码（coding）
- 测试（testing）
- 部署和评估（deployment / evaluation）
每个迭代大约持续2~6周。
五、敏捷开发的价值观
《敏捷软件开发宣言》里面提到四个价值观。
- 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
- 软件能够运行，优于详尽的文档。
- 跟客户的密切协作，优于合同和谈判。
- 能够响应变化，优于遵循计划。
六、十二条原则
该宣言还提出十二条敏捷开发的原则。
- 通过早期和持续交付有价值的软件，实现客户满意度。
- 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
- 不断交付可用的软件，周期通常是几周，越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作。
- 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
- 面对面交谈是最好的沟通方式。
- 可用性是衡量进度的主要指标。
- 提倡可持续的开发，保持稳定的进展速度。
- 不断关注技术是否优秀，设计是否良好。
- 简单性至关重要，尽最大可能减少不必要的工作。
- 最好的架构、要求和设计，来自团队内部自发的认识。
- 团队要定期反思如何更有效，并相应地进行调整。
七、参考链接
- Iterative development: the secret to great product launches, Pavlo Zinchenko
- Agile software development, Wikipedia
持续集成/交付/部署
已剪辑自: https://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）。
本文简要介绍持续集成的概念和做法。
一、概念
持续集成指的是，频繁地（一天多次）将代码集成到主干。
它的好处主要有两个。
**（1）快速发现错误。**每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
**（2）防止分支大幅偏离主干。**如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
**持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。**它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。”
与持续集成相关的，还有两个概念，分别是持续交付和持续部署。
二、持续交付
**持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。**如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
三、持续部署
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aXMr0sEe-1667828303193)(https://www.ruanyifeng.com/blogimg/asset/2015/bg2015092302.jpg)]
（图片来源）
四、流程
根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
4.1 提交
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。
4.2 测试（第一轮）
代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
测试有好几种。
- 单元测试：针对函数或模块的测试
- 集成测试：针对整体产品的某个功能的测试，又称功能测试
- 端对端测试：从用户界面直达数据库的全链路测试
第一轮至少要跑单元测试。
4.3 构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具如下。
Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。
4.4 测试（第二轮）
构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
4.5 部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
4.6 回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
五、参考链接
- Gergely Nemeth, Continuous Deployment of Node.js Applications
- Codeship, Continuous Integration Essentials
DevOps 入门指南
已剪辑自: https://zhuanlan.zhihu.com/p/22638204
当我们谈到 DevOps 时，可能讨论的是：流程和管理，运维和自动化，架构和服务，以及文化和组织等等概念。那么，到底什么是"DevOps"呢？
什么是DevOps
随着软件发布迭代的频率越来越高，传统的「瀑布型」（开发—测试—发布）模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
关于 DevOps 是什么，DevOps 的合著者 John Willis 写了一个非常好的帖子，在这里.
Devops 的好处与价值
在2016 DevOps 新趋势调查报告显示，74% 的公司在尝试接受 DevOps，那么 Devops 有哪些好处与价值呢？
- 代码的提交直接触发：消除等待时间，快速反馈
- 每个变化对应一个交付管道：使问题定位和调试变得简单
- 全开发流程高效自动化：稳定，快速，交付结果可预测
- 持续进行自动化回归测试：提升交付质量
- 设施共享并按需提供：资源利用最大化
以上可以看出，DevOps 的好处更多基于在于持续部署与交付，这是对于业务与产品而言。而 DevOps 始于接受 DevOps 文化与技术方法论，它是部门间沟通协作的一组流程和方法，有助于改善公司组织文化、提高员工的参与感。
Devops与持续集成
DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。
纵观各个 DevOps 实践公司的技术资料，最全面最经典的是 flickr 的10+ deploys per day最佳实践提到的 DevOps Tools 的技术关键点:
1.Automated infrastructure（自动化，系统之间的集成）
2.shared version control（SVN共享源码）
3.one step build and deploy（持续构建和部署）
4.feature flags（主干开发）
5.Shared metrics
6.IRC and IM robots（信息整合）
以上的技术要点由持续集成/部署一线贯穿，主干开发是进行持续集成的前提，自动化以及代码周边集中管理是实施持续集成的必要条件。毫无疑问，DevOps 是持续集成思想的延伸，持续集成/部署是 DevOps 的技术核心，在没有自动化测试、持续集成/部署之下，DevOps就是空中楼阁。
我们做了一款 Hosted 持续集成产品—— flow.ci ，它融入了 workflow 机制的持续集成（CI）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程，帮助你们塑造一个更优秀智能的 DevOps 环境。
DevOps 的技术栈与工具链
Everything is Code，DevOps 也同样要通过技术工具链完成持续集成、持续交付、用户反馈和系统优化的整合。Elasticbox 整理了 60+ 开源工具与分类，其中包括版本控制&协作开发工具、自动化构建和测试工具、持续集成&交付工具、部署工具、维护工具、监控，警告&分析工具等等，
补充了一些国内的服务，可以让你更好的执行实施 DevOps 工作流。
- 版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
- 自动化构建和测试:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
- 持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
- 容器平台: Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
- 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
- 微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
- 服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
- 日志管理：Logstash、CollectD、StatsD
- 监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
顺便再跟大家分享一个 DevOps BookMarks，这里面涉及了DevOps方方面面的工具和内容，有兴趣的同学可以前去学习。
DevOps 最佳实践
自 2009 年提出 DevOps 的概念起，很多公司都开始实施 DevOps，国外比较著名的有Amazon 、Google、Facebook等，国内著名的有百度、华为、阿里等。Amazon 是 DevOps 最佳实践的最有说服力的代表之一。这是 Amazon 在 Why We Need DevOps 一个月的 DevOps 快照：
11.6 seconds: 平均部署时长 (工作日)
1,079: 一小时的最大部署量
10,000: 主机平均并发接收部署量
30,000: 主机最高并发接收部署量
从早期的大型 SOA (Service Oriented Architecture)到 DevOps 文化的形成，Amazon 的每个工程师都可以完全独立地编写代码，测试代码，版本管理，部署上线，服务监测等任务。这套内部强大的 DevOps 文化最终形成核聚变， Amazon 一跃成为世界级别的云服务领导者 —— Amazon Web Services (AWS)。
除了 Amazon 外还有一些国内外的 DevOps 实践公司，一起来看看。
- flickr
最全面最经典的是 flickr 的10+ deploys per day，简直是 DevOps 教科书般的存在。
- 百度
百度技术团队是如何利用DevOps，来看看解密百度持续交付方法与实践。
- Netflix
解密Netflix 技术团队在整个 DevOps 过程中使用的部署工具和服务.
How We Build Code at Netflix.
- Etsy
2009年，Etsy建立自己的工具来更好更快地部署发布，「Etsy 如何应用 DevOps」值得一读。
2009年，LinkedIn 团队就开始使用自动化部署工具，用于管理在1000+节点环境下发布上千个应用/服务的复杂性。这是 LinkedIn 自己造的轮子 >>Deployment and Monitoring Automation with glu.
- Airbnb
Airbnb 作为第三方平台公司，需要迅速发布多个小型部署。关于 Airbnb 的数据和基础设施，可以参考这个slides。
- Starbucks
星巴克的 DevOps 计划>> Starbucks Announces #DevOpsTogether.
- http://Ancestry.com
http://Ancestry.com 是 DevOps 运动的早期采用者，是 Continuous Delivery 和 DevOps 运动的先锋。想了解更多关于他们的过程、迁移和 DevOps 文化，不妨查看一下他们的系列文章DevOps – Tech Roots。
DevOps = Culture + Tools
如果想整个业务部署 DevOps，不但需要软性要求即从上而下的培养 DevOps 文化自上而下地进行探索，也有硬性工具链要求，才能获得更高质量的软件交付。
最后，不论你是技术Leader，还是一名Dev、QA 或 Ops，实现全面的 DevOps 非常理想化也十分有挑战，希望这份 DevOps 初学者指南是一个好的开始:)
敏捷，持续集成/持续交付, DevOps 三者的区别
已剪辑自: https://zhuanlan.zhihu.com/p/106477550
原文地址：https://www.synopsys.com/blogs/software-security/agile-cicd-devops-difference/
原文作者：John Steven
翻译君：CODING 戴维奥普斯
以下这篇译文清晰明了地揭示了敏捷（Agile），持续集成/持续交付（CI/CD）和 DevOps 三者之间的区别和联系。它们尽管有所不同，但是彼此支持，相互联系。敏捷专注于开发过程，CI/CD 专注于实践，DevOps 专注于文化。
3种不同的开发工具可用于建立练习
您无法只用一个工具盖高楼大厦，您也不能一口气进行开发实践。敏捷，DevOps 和 CI/CD 是三个截然不同的工具，每一个工具本身都很重要。当开发团队将这三个功能用于其预期目的时，结果将具有变革性。
敏捷开发
敏捷专注于消除流程障碍，并使关键的利益相关者（如开发人员和客户）能够在加快交付速度方面进行更紧密的协作。敏捷强调了变革的持续性，并承认作为软件生产者，我们并不总是在一开始就了解在整体生命周期中，成功构思、开发和交付高质量软件所需的一切需求和资源。
因此，尽管在过去的二十年中敏捷的意义有所不同，但其基本原则仍然保持不变：消除赋予个人权力的流程障碍，迅速开发可运行的软件，与客户密切协作以及积极应对（而不是抵制）变化。
CI/CD
持续集成（CI）是一种软件工程实践，团队成员以越来越高的频率集成他们的工作。通过长久的 CI 实践，团队至少每天甚至每小时进行集成，以此接近“连续”程度的集成。
从历史上看，集成一直是一项昂贵的工程活动。因此，为避免项目遭受重创，CI 强调了驱动构建和测试的自动化工具。 CI 实现之后，构建和集成工作就会减少，团队也可以尽快检测到集成错误。
持续交付（CD）用于打包和部署 CI 要构建和测试的项目。实践 CD 的团队可以构建，配置和打包软件，并编排其部署方式，以便可以随时以软件定义的方式（低成本，高度自动化）将其发布到生产环境中。
由于软件更改更频繁地投入生产，高功能化的 CI/CD 实践直接促进了敏捷开发。因此，客户有更多机会体验产品变化并提供反馈。
DevOps 文化
DevOps 专注于敏捷开发过程中文化和角色的局限性。 DevOps 的目的是解决组织中过度专业化和不同部门人员沟通不畅导致的一些痛点，例如对生产问题无法快速甚至有效响应。DevOps 组织通过对每个团队进行彼此技能的交叉培训来打破运维和开发之间的障碍。这种方法提高了每个人欣赏和参与彼此任务的能力，并促进了更高质量的协作和更频繁的交流。
什么是 DevOps 中的 CI/CD？它们与敏捷有什么关系？
CI/CD，敏捷和 DevOps 与现实生活中的发展有何关系？工程团队通常从 CI 开始实践。 DevOps 可以帮助组织了解在整体生命周期甚至更长时间内软件所必需的配置，打包和编排–从而创建更有价值的持续交付实践。反过来，DevOps 中 CI/CD 的实践又增强了敏捷开发。
结论
区分敏捷，DevOps 和 CI/CD 最快速简便的方法：
敏捷专注于在加速交付的同时突出变化的过程。
CI/CD 专注于软件生命周期内强调自动化的工具。
DevOps 专注于强调响应能力的文化角色。