对于一个IT基础平台的研发运行来说开发模式非常重要，服务云的开发模式也是从实践中一点点积累和成长起来的，目前软件开发领域有两种开发模式，分别是瀑布模式和敏捷模式
1. 传统瀑布模式
瀑布模式是比较传统一种开发模式，特别是在2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常使用。现在在一些大项目或者是外包项目当中仍使用，模型如下图：
瀑布模型从计划到开发最后到上线运行，三个阶段非常明确，每个阶段顺序必须是从上到下，严格按照时间先后进行，每个阶段都必须有产出物然后才能进入到下一个阶段进行，每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注，这样看起来很不错，但在项目中实际运行问题很大，如：
* 瀑布只能往下流不能往上逆流，意味着不走回头路，如出现返工代价极大
* 各阶段极少有反馈，项目结束时才能发现问题，如果问题较大将无法上线运行
* 需求变更难，不适合需求不定的项目，但需求是随着用户体验及时变化的
* 开发周期长，大量时间编写文档，但文档与代码及时同步比较困难
我们打个比方：一个项目制定计划2周，需求分析4周，软件设计3周，程序编写5周，软件测试2周，共需要16周时间，也就是4个月
在第15周时测试人员发现了一个问题，反馈给程序编写人员，如果是程序bug的话程序员直接修改提交测试即可
如果不是bug而是设计的问题，程序员会反馈给软件设计人员进行重新设计后，再由程序员完成开发，交由测试人员测试，
如果设计人员发现不是设计的问题，而是需求不明确或需求不对时，再向上反馈......
这样的项目开发上线风险实在是太大了，因为瀑布强调分工，各自为战，所以有可能架构设计人员在等产品经理给需求文档，开发人员在等待架构设计文档，测试人员在等待开发成果，老板在等待产品交付。这里环环相扣，类似电流串联工作，一个环节出错，造成断电，导致交付延期，后果可能就是互相推诿和扯皮，严重的话可能会引发争吵，团队分崩离析
通过以上分析瀑布模式强调里程碑，重视文档，强调分工，避免变化，凡事喜欢规划和做计划，但是代价就是拖沓笨重，反应迟钝，所以对于旅客服务领域系统建设要求及时响应用户的新需求和个性化的服务来说，这种开发模式不适合
2. 敏捷迭代模式
诺基亚公司当年一定要保证手机至臻完美，觉得不会出错，没问题了才敢卖出去，当时的用户都是离线的觉得没有问题，但这样耽误了它的创新机会。现在的手机到了消费者手里可以实时在线升级，快速改进。如小米手机的操作系统每周五都要进行一次升级，各应用app版本迭代频率更快，有的一天升级好几次。
敏捷开发借助互联网浪潮开始流行起来，这也是2C的业务特点决定的，互联网产品不可能一步规划到位，一般都是核心功能优先，比如微信，先是实现聊天功能，然后才是漂朋友圈，支付，小程序，敏捷无疑更加贴近这种业务需求，如果纯用瀑布模式，估计黄花菜都凉了。
敏捷开发模型将一个软件项目分为多个周期进行开发，用一个周期如两周时间实现一个很简陋的功能，但必须是一个可运行的版本，马上与需求者进行沟通确认，再第二个版本里规划改进并加入新功能，产出可运行的版本，再沟通确认，这样一个一个迭代进行软件的滚动完善。
迭代快，开发周期短，通过不断迭代完善产品
快速尝试，避免过长时间的需求分析及调研，快速尝试
快速改进：在迭代周期过后根据客户反馈快速改进
面对面，写必要文档
沟通多，易发现问题
分工细，每天出成果
人员能力要求高，任务多，压力大
敏捷开发运行模式：
把项目拆分成用户故事是实施敏捷的基础，每一个需求都用讲故事的方式在业务场景下进行演示，故事讲完整了就说明这个需求是有效的，才能列入用户故事列表中，全体成员坐在一起开个计划会，评审这些故事确定哪些故事编入本次迭代的实现中，哪些往后放，最终形成迭代任务列表。
传统瀑布开发是半成品堆积而且缺乏快速反馈的过程，传统需求只考虑功能而很少考虑场景和用户体验。敏捷开发是基于用户故事的业务价值的持续交付过程。
实际瀑布和敏捷不是天然分割的，只是针对业务各有侧重，应该是你中有我，我中有你的混合体，既然各有利弊，那么中间的这个平衡点如何拿捏就非常重要，如何在前期设计的时候既能不过渡导致交付延迟，又能兼顾后续的演进和变化导致的修改可控，这需要技术负责人丰富的实战历练和审时度势的判断力
3. 服务云开发模式
服务云平台的开发模式以敏捷迭代为主，瀑布模式为补充，整个敏捷的过程使用阿里云的云效平台进行管理，目前集团没有自己的研发团队，主要靠外包人员完成开发工作，这样人员就很难以满足敏捷对开发人员全栈能力的要求，所以在开发过程中也要重视文档的同步落地以及人员的培养、质量的过程检查等瀑布模式的工具和方法
七、开发运维一体化
1. 传统运维
开发团队与运维团队是两个不同的部门
IT环境异构量大，日常巡检压力大
误操作可能导致无法挽回的灾难，技术能力要求高
2. DevOps开发运维一体化
什么是DevOps ?
DevOps是一套实践方法，在保证高质量的前提下，缩短系统变更从提交到部署至生产环境的时间。
为什么要用DevOps？
在业务日渐复杂的今天，一个需求的上线，经历的环节多且对人的协作提出不少要求。诸如开发与测试的矛盾，开发与运维的沟通。在敏捷开发，快速迭代，小步快步等理念盛行之下，沟通的摩擦成本已经相当之高，而DevOps的出现寄托了缓解此现象的初衷。总结要点是：
* 发布过程复杂，耗时耗力
* 解决开发与运维配合要求高
* 运维人员技能要求太多，可减少对运维能力项依赖
IAAS基础设施云化
云服务提供的一些能力（特别是快速弹性），在进行DevOps实践时提供了不少便利，主要有：
* 简单创建和切换（迁移）环境的能力。这让开发，测试和部署的过程简单了许多。
* 轻松创建虚拟机的能力。资源的管理和更新变得简单。
* 数据库的管理。业务连续性问题。
部署自动化
部署过程的每一个步骤都自动化，可以带来包括效能在内的显著的好处。你可以手工做这些事情，但是很耗时。二者的生产率差异真的很大。
对于习惯于开发和部署本地应用的组织来说，设置自动部署工具的确给软件开发引进了一个新的步骤，需要一个学习的过程，还要有相关的投入。但是见效很快，因为每进行一轮开发，你都可以快速地部署到云上然后进行测试过程，第一次把东西设好是个挑战，但这完全是值得的。
自动应用部署也改进了软件的总体质量。在整个生命周期（包括部署在内）都使用好的工具，能够把人的干预最小化；能够节省必须等待某人做某事的时间。一旦把人的干预去掉，质量就更加可预测，会变得更好
旅客服务云通过云效实现代码托管，从代码提交、集成、构建到测试环境、预发环境、线上环境部署发布验证的持续交付流水线，从质量和安全上把关
测试自动化
旅客服务云通过云效实现测试自动化
持续交付与持续集成
在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。
持续集成意味着一个在家用笔记本编写代码的开发人员（程序员A）和另一个在办公室编程的开发人员（程序员B）可以为同样的产品分别地编写软件，将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件，并且按照他们期望的方式来测试软件。
旅客服务云使用云效来做构建和集成。持续集成要求程序员A和程序员B能够自测代码。分别测试各自代码来保证它能够正常工作，这些测试通常被称为单元测试（Unit tests）。
代码集成以后，当所有的单元测试通过，程序员A和程序员B就得到了一个绿色构建（green build）。这表明他们已经成功地集成在一起，代码正按照测试预期地在工作。然而，尽管集成代码能够成功地一起工作了，它仍未为生产做好准备，因为它没有在类似生产的环境中测试和工作。
考虑到实践持续集成，程序员A和程序员B必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次，并且每天最少一次。
持续集成的好处是，集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前，集成发生在创建过程的结尾阶段，一次性完成，并且不知道要耗时多久。而现在持续集成，每天都融入到了工作方式当中。
程序员A和程序员B。持续交付意味着每次程序员A或程序员B修改、整合和构建代码时，也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境，一个测试环境，一个准生产环境，但是这些阶段会根据不同的团队、产品和组织而变化。
在不同的环境下，程序员A和程序员B写的代码被分别进行测试。当代码部署到生产环境它就开始了工作，这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式，程序员A和程序员B将会从每个环境中测试并得到新的反馈，如果有失败，他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。
监控可视化
服务云使用 EDAS 控制台实时监控应用中资源和服务的状态及时发现问题，并通过日志和诊断组件快速定位。
开发平台：[https://signin.aliyun.com/1037220410576239/login.htm](https://signin.aliyun.com/1037220410576239/login.htm)
