敏捷开发
敏捷是用于描述软件开发方法的术语，强调增量交付、团队协作、持续规划和持续学习。"敏捷"一词源于2001年《敏捷宣言》。宣言旨在确立指导软件开发更优方法的原则。其核心是宣布代表敏捷运动基础的4项价值观：
响应变化 胜过 遵循计划
依据以上四条价值观，衍生出来更具体的十二大原则，作为对敏捷宣言更具实操性的解释，其具体原则内容如下：
1) 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2) 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3) 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4) 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5) 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6) 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7) 可以工作的软件是进度的主要度量标准。
8) 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9) 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10) 简单——尽可能减少工作量的艺术至关重要。
11) 最好的架构、需求和设计都源自自我组织的团队。
12) 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
敏捷开发是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷开发是用于描述迭代软件开发的术语。敏捷开发通常与传统或瀑布开发形成对比，在传统或瀑布开发中，大型项目是按照该计划进行规划和执行的。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。迭代软件开发缩短了软件开发生命周期。
敏捷开发团队以较小的增量执行整个软件开发生命周期，通常称为冲刺（sprint）。冲刺通常有1-4周长。每次冲刺交付产品级代码都需要敏捷的开发团队来应对加速的步伐。所有编码、测试和质量验证都必须在每个冲刺阶段完成。各团队间应密切协作，否则可能会导致失败甚至惨败。
图1：敏捷开发流程示意图
3. 尽量避免技术缺陷
敏捷是一种寻找软件开发方法的态度。敏捷方法中没有一种方法适用于所有情况，而"敏捷"一词已经代表与宣言中的价值陈述一致的各种敏捷方法与最佳实践。
敏捷方法是一个囊括了各种框架和方法的涵盖性术语，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。敏捷方法（通常称为敏捷框架）是软件开发生命周期阶段（规划、执行和交付）的综合方法。它规定了一套在明确的指导和原则下完成工作的方法。
敏捷方法主要包括SCRUM方法、DSDM 方法、水晶方法、特性驱动方法和 SCRUMBAN 等。例如Scrum是最常见的敏捷框架。持续集成（Continuous Integration，CI）是常见的敏捷工程实践方法。
需要说明的是，敏捷方法与最佳实践并不承诺解决每一个问题，但他们确实承诺建立一个文化和环境，通过协作，不断的规划和学习，并快速迭代交付高质量的软件，最终满足客户需求。
Scrum 是团队用于管理其工作的框架，将敏捷原则作为一套具体的工件、实践和角色，通常用于敏捷软件开发。具体来说，Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。Scrum起源于软件开发项目，Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法，适用于任何复杂的或是创新性的项目。如Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及日常生活中更广泛的产品开发领域。
Scrum整个开发流程(见图2) 由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将提交潜在可交付的产品增量。
图2 Scrum流程图
5个价值：承诺 – 愿意对目标做出承诺、专注– 把你的心思和能力都用到你承诺的工作上去、开放– Scrum 把项目中的一切开放给每个人看、尊重– 每个人都有他独特的背景和经验、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
DevOps 是开发 (Dev) 和运营 (Ops) 的复合词，是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法[9]。
以下几方面因素可能促使一个组织引入DevOps：
1、使用敏捷或其他软件开发过程与方法
2、业务负责人要求加快产品交付的速率
3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
4、数据中心自动化技术和配置管理工具的普及
5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时，DevOps也已经稳健地在业务思维方式中占有一席之地，并将扮演主要角色。在应用驱动、云连接、移动化的大环境下，对于很多公司来说DevOps是助力业务增值战略的第一步。
紧跟行业趋势、进行新的技术变革往往会带来发展的阵痛，DevOps也同样要经历这一过程。中国及全球各地的企业正在认识到DevOps可以助力软件开发速度加快，软件应用质量提升，更重要的是与业务目标更完美地结合。[9]。
健康的 DevOps 文化的一个标志是团队间能够协作，首要的便是可见性。开发和 IT 运营等不同团队必须能够相互分享 DevOps 流程、优先级和关注点。这些团队还必须能够共同规划工作，并统一与业务相关的成功目标和衡量标准。
当团队统一时，他们拥有所有权并参与其他生命周期阶段，而不仅仅是他们的角色对应的阶段。例如，开发人员不仅要对开发阶段的创新和质量负责，还要对他们的改变在运营阶段带来的性能和稳定性负责。同时，IT 操作员一定要在规划和开发阶段中考虑治理、安全性和符合性。
DevOps 团队通过短周期发布软件保持敏捷。因为进度是渐进式的，缩短发布周期可以让计划和风险管理更容易，同时也减少了对系统稳定性的影响。缩短发布周期还可以让组织适应和应对不断变化的客户需求和竞争压力。
高绩效的 DevOps 团队形成了一种成长思维。他们快速失败，然后将经验教训融入到他们的流程中，不断改进，提高客户满意度，加速创新和适应市场。DevOps 是一个旅程，所以总有成长的空间。
DevOps 影响应用程序生命周期的规划、开发、交付和运营阶段。每个阶段都依赖于其他阶段，并且这些阶段并非特定于角色。在真正的 DevOps 文化中，每个角色在某种程度上说都涉及各个阶段如图 4。
图 4 DevOps 和应用程序生命周期
持续监控
其中一些做法有助于加速、自动化和改进特定阶段。有的跨越几个阶段，帮助团队创建提高生产效率的无缝进程。
无论是纵向集成还是横向集成，DevOps都需要通过工具链与持续集成、交付、反馈与优化进行端到端整合。如华为的软件开发云服务, 基于二十几年的研发实践，融合DevOps理念方法，为企业提供一站式的云上开发工具平台。华为软件开发云提供项目管理、配置管理、代码检查、编译构建、测试、部署、发布等端到端地覆盖全软件生命周期的相关服务。类似的DevOps 工具数不胜数，常见的DevOps 生态圈工具如图 5。
DevOps 和 Agile 都是用于生产产品、进行发布或发行的现代软件开发框架。DevOps 是一种文化，促进软件开发和维护中所有角色之间的协作。Agile 是一种开发方法，在需求不断变化的常见现实中保持工作效率和促进发布。DevOps 和 Agile 并不是相互排斥的，而是经常搭配使用。
持续集成
集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
大师Martin Fowler对持续集成是这样定义的:
持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少假定。
减少重复的过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及反馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多的投入到动脑筋的、更高价值的事情上。
持续集成可以让您在任何时间发布可以部署的软件。从外界来看，这是持续集成最明显的好处，我们可以对改进软件品质和减少风险说起来滔滔不绝，但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。不采用持续集成的情况下，这些问题有可能到交付前的集成测试的时候才发现，有可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致项目失败。
持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。通常，项目成员通过手工收集这些信息，增加了负担，也很耗时。持续集成可以带来两点积极效果：
(1)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。
(2)注意到趋势：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息。
持续集成可以建立开发团队对开发产品的信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。
保证快速构建
模拟生产环境的自动测试
每个人都可以很容易的获取最新可执行的应用程序
每个人都清楚正在发生的状况
自动化的部署
所有的开发人员需要在本地机器上做本地构建，然后再提交到版本控制库中，从而确保他们的变更不会导致持续集成失败。
开发人员每天至少向版本控制库中提交一次代码。
开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
每次构建都要100%通过。
每次构建都可以生成可发布的产品。
修复失败的构建是优先级最高的事情。
测试是未来，未来是测试。
持续集成（Continuous integration，简称CI）是软件的开发和发布标准流程中最重要的部分。作为一种开发实践，在CI中可以通过自动化等手段高频率地去获取产品反馈并响应反馈的过程。简单来说，就是持续不断地（一天多次）将代码合并（集成）到主干源码仓库，让产品可以快速迭代，同时保持高质量。
持续集成强调对于开发人员的每个提交，立刻进行构建、扫描、（单元）测试。根据结果，我们可以确定新代码和原有代码能否正确地集成在一起。如一个完整的CI系统应该包含3个基本模块：
一个可以自动构建的过程，自动编译代码，可以自动分发，部署和测试。
一个代码仓库，例如Git。
一个持续集成的服务器。
如图 3是典型的持续集成流程图。
图3持续集成流程图正如图3持续集成流程所示，通用的持续集成（CI）流程主要包括：
签出代码：
从源码管理系统里签出或者克隆最新的代码到本地开发环境
提交（commit）：
基于主干分支创建一个新的功能分支，并在此分支编写代码，并向仓库提交代码
测试（第1轮）：
代码仓库对commit操作配置了钩子（hook）， 每一次提交代码都会触发测试。
单元测试（针对函数或模块的测试）和功能测试（集成测试）将会被执行、根据需要设置是否执行端对端测试。
一般来说，这些测试也会被打包到代码里。
构建（build）：
通过测试（第1轮）后，将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等。
实现一个CI流程的唯一必要条件便是得有一个自动构建系统。
源代码一般是自包含构建的，即CI流程所需的构建脚本是放在源码仓库里的。
测试（第2轮）：
以自动化为主的全面测试，包括单元测试和集成测试，必要时做端对端测试，确保新版本的每一个更新点都必须测试到。
合并：
通过测试（第2轮）后，将代码更新集成到主干。
回滚：
如果当前版本发生问题，就回滚到上一个版本的构建结果
一般来说，CI服务器会配置成在遇到故障时发送邮件相关人员，可以快速知晓故障并且尽快采取更正措施。
当需要代码变更并集成时，开发者会从基础代码库复制以进行作业，其他开发者提交代码的变更至来源代码库，并透过副本的方式取代来源代码库的代码。不只变更目前的代码库，新的代码也可以新增成为程序库、其它共享资源与潜在冲突。
当分支代码开发者进行主线重新集成时，当分支代码保持在取出状态时间越长，就愈容易遭遇集成多重冲突的风险以及集成失败。因为他们拿到的是副本，所以当开发者将代码提交到代码库时，首先必须更新代码以反映他们在代码库中的更改。代码库包含的更改越多，开发人员在提交自己的更改前必须运行的基础工作就越多。
最终，该程序库也许变成非常不同于开发者的目标代码，他们进入有时候被称为合并地狱或集成地狱的阶段，这时候开发者所花费的集成时间，将超过最初代码开发的时间。
持续集成涉及预先集成与预先与经常性的集成，借此来避免掉入集成地狱的陷阱，实践的目标是减少重工、减少成本与时间。
持续集成补充的实践是在提交代码之前，每个开发人员必须运行一个完整的构建并通过所有的单元测试、集成测试。当持续集成服务器侦测到代码有新的提交时，必须经常性与自动化的进行此类单元测试或集成测试任务。代码每次集成到主干之前，必须通过自动化测试，以便快速发现和定位错误。值得注意的是，持续集成并不能消除错误，而是让它们非常容易发现和改正。
阅读原文，关注作者知乎！
