對于一個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)
