现在的开发方式—-敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
为什么要使用敏捷开发?
作为程序员,写的程序如果功能没有问题,但是因为产品的迭代,市场的需求,导致你的模块不能上线发布 那么花的时间及精力都是浪费的;我们该如何快速,低风险、持续的交付有价值的软件。我们需要及时获得市场的反馈,获得用户的反馈,才能开发出带有价值的程序
说出来才知道对不对；知道不对才能改进；改进才能成长
一个程序 需要从集成 -> 部署 -> 交付
- 集成是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
- 部署是代码尽快向可运行的开发/测试节交付，以便尽早测试；
- 交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。
如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。
而所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。
这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。
举个例子，你家装修厨房，其中一项是铺地砖，边角地砖要切割大小。如果一次全切割完再铺上去，发现尺寸有误的话浪费和返工时间就大了，不如切一块铺一块。这就是持续集成。 装修厨房有很多部分，每个部分都有检测手段，如地砖铺完了要测试漏水与否，线路铺完了要通电测试电路通顺，水管装好了也要测试冷水热水。如果全部装完了再测，出现问题可能会互相影响，比如电路不行可能要把地砖给挖开……。那么每完成一部分就测试，这是持续部署。 全部装修完了，你去验收，发现地砖颜色不合意，水池太小，灶台位置不对，返工吗？所以不如没完成一部分，你就去用一下试用验收，这就是持续交付。
补充：从敏捷思想中提出的这三个观点，还强调一件事：通过技术手段自动化这三个工作。加快交付速度。
- 持续集成
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
- 持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
- 持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
即代码的零库存管理，是精益生产的精~精~精~精髓。
- 代码越早push出去，用户能越早用到，快就是商业价值；
- 用户越早用到就越早反馈，团队越早得到反馈，好坏都是有价值的输入；
- 用户不反馈，说明我们做了用户不想要的东西（通过用例跟踪）或者marketing没做好，能帮助产品市场人员调整策略；
- 代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个release的复杂度和风险越高；
- 代码库存越多，workflow的包袱越重，管理成本越大，说敏捷越可笑。
流水不腐，户枢不蠹。
持续集成、持续部署、持续交付、持续发布。
我个人感觉 敏捷开发只不过是这个词的概括吧
就是在 任何时候，对外都能提供可以分发、安装、使用的新版本 这要求： 1、系统的总体框架、主干 成熟、稳定、简洁 2、更新、发布、安装、运行、重置 简单方便 3、任何改进、改动都在独立分支进行，并能快速合并回主版本 4、重新生成发布包 能随时、自动、快速进行
