敏捷開(kāi)發(fā)
1.1 什么是敏捷?
敏捷是用于描述軟件開(kāi)發(fā)方法的術(shù)語(yǔ)，強(qiáng)調(diào)增量交付、團(tuán)隊(duì)協(xié)作、持續(xù)規(guī)劃和持續(xù)學(xué)習(xí)。"敏捷"一詞源于2001年《敏捷宣言》。宣言旨在確立指導(dǎo)軟件開(kāi)發(fā)更優(yōu)方法的原則。其核心是宣布代表敏捷運(yùn)動(dòng)基礎(chǔ)的4項(xiàng)價(jià)值觀：
- 個(gè)體和交互 勝過(guò) 過(guò)程和工具
- 可以工作的軟件 勝過(guò) 面面俱到的文檔
- 客戶合作 勝過(guò) 合同談判
-
響應(yīng)變化 勝過(guò) 遵循計(jì)劃
依據(jù)以上四條價(jià)值觀，衍生出來(lái)更具體的十二大原則，作為對(duì)敏捷宣言更具實(shí)操性的解釋，其具體原則內(nèi)容如下：
1) 最重要的是通過(guò)盡早和不斷交付有價(jià)值的軟件滿足客戶需要。
2) 我們歡迎需求的變化，即使在開(kāi)發(fā)后期。敏捷過(guò)程能夠駕馭變化，保持客戶的競(jìng)爭(zhēng)優(yōu)勢(shì)。
3) 經(jīng)常交付可以工作的軟件，從幾星期到幾個(gè)月，時(shí)間尺度越短越好。
4) 業(yè)務(wù)人員和開(kāi)發(fā)者應(yīng)該在整個(gè)項(xiàng)目過(guò)程中始終朝夕在一起工作。
5) 圍繞斗志高昂的人進(jìn)行軟件開(kāi)發(fā)，給開(kāi)發(fā)者提供適宜的環(huán)境，滿足他們的需要，并相信他們能夠完成任務(wù)。
6) 在開(kāi)發(fā)小組中最有效率也最有效果的信息傳達(dá)方式是面對(duì)面的交談。
7) 可以工作的軟件是進(jìn)度的主要度量標(biāo)準(zhǔn)。
8) 敏捷過(guò)程提倡可持續(xù)開(kāi)發(fā)。出資人、開(kāi)發(fā)人員和用戶應(yīng)該總是維持不變的節(jié)奏。
9) 對(duì)卓越技術(shù)與良好設(shè)計(jì)的不斷追求將有助于提高敏捷性。
10) 簡(jiǎn)單——盡可能減少工作量的藝術(shù)至關(guān)重要。
11) 最好的架構(gòu)、需求和設(shè)計(jì)都源自自我組織的團(tuán)隊(duì)。
12) 每隔一定時(shí)間，團(tuán)隊(duì)都要總結(jié)如何更有效率，然后相應(yīng)地調(diào)整自己的行為。
1.2 敏捷開(kāi)發(fā)概念與特點(diǎn)
敏捷開(kāi)發(fā)是一種從1990年代開(kāi)始逐漸引起廣泛關(guān)注的新型軟件開(kāi)發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開(kāi)發(fā)能力。它們的具體名稱、理念、過(guò)程、術(shù)語(yǔ)都不盡相同，相對(duì)于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對(duì)面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫(xiě)和團(tuán)隊(duì)組織方法，也更注重軟件開(kāi)發(fā)中人的作用。
敏捷開(kāi)發(fā)是用于描述迭代軟件開(kāi)發(fā)的術(shù)語(yǔ)。敏捷開(kāi)發(fā)通常與傳統(tǒng)或瀑布開(kāi)發(fā)形成對(duì)比，在傳統(tǒng)或瀑布開(kāi)發(fā)中，大型項(xiàng)目是按照該計(jì)劃進(jìn)行規(guī)劃和執(zhí)行的。
敏捷開(kāi)發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開(kāi)發(fā)。在敏捷開(kāi)發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備可視、可集成和可運(yùn)行使用的特征。換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)。迭代軟件開(kāi)發(fā)縮短了軟件開(kāi)發(fā)生命周期。
1.3 敏捷開(kāi)發(fā)流程
敏捷開(kāi)發(fā)團(tuán)隊(duì)以較小的增量執(zhí)行整個(gè)軟件開(kāi)發(fā)生命周期，通常稱為沖刺（sprint）。沖刺通常有1-4周長(zhǎng)。每次沖刺交付產(chǎn)品級(jí)代碼都需要敏捷的開(kāi)發(fā)團(tuán)隊(duì)來(lái)應(yīng)對(duì)加速的步伐。所有編碼、測(cè)試和質(zhì)量驗(yàn)證都必須在每個(gè)沖刺階段完成。各團(tuán)隊(duì)間應(yīng)密切協(xié)作，否則可能會(huì)導(dǎo)致失敗甚至慘敗。
圖1：敏捷開(kāi)發(fā)流程示意圖
敏捷開(kāi)發(fā)團(tuán)隊(duì)幾個(gè)關(guān)鍵的成功因素：
1. 細(xì)化需求列表
2. 早期并高頻集成
3. 盡量避免技術(shù)缺陷
1.4 敏捷方法與最佳實(shí)踐
敏捷是一種尋找軟件開(kāi)發(fā)方法的態(tài)度。敏捷方法中沒(méi)有一種方法適用于所有情況，而"敏捷"一詞已經(jīng)代表與宣言中的價(jià)值陳述一致的各種敏捷方法與最佳實(shí)踐。
敏捷方法是一個(gè)囊括了各種框架和方法的涵蓋性術(shù)語(yǔ)，它指的是符合《敏捷宣言》價(jià)值觀和原則的任何方法、技術(shù)、框架、手段或?qū)嵺`。敏捷方法（通常稱為敏捷框架）是軟件開(kāi)發(fā)生命周期階段（規(guī)劃、執(zhí)行和交付）的綜合方法。它規(guī)定了一套在明確的指導(dǎo)和原則下完成工作的方法。
敏捷方法主要包括SCRUM方法、DSDM 方法、水晶方法、特性驅(qū)動(dòng)方法和 SCRUMBAN 等。例如Scrum是最常見(jiàn)的敏捷框架。持續(xù)集成（Continuous Integration，CI）是常見(jiàn)的敏捷工程實(shí)踐方法。
需要說(shuō)明的是，敏捷方法與最佳實(shí)踐并不承諾解決每一個(gè)問(wèn)題，但他們確實(shí)承諾建立一個(gè)文化和環(huán)境，通過(guò)協(xié)作，不斷的規(guī)劃和學(xué)習(xí)，并快速迭代交付高質(zhì)量的軟件，最終滿足客戶需求。
2.
SCRUM方法
2.1 SCRUM綜述
Scrum 是團(tuán)隊(duì)用于管理其工作的框架，將敏捷原則作為一套具體的工件、實(shí)踐和角色，通常用于敏捷軟件開(kāi)發(fā)。具體來(lái)說(shuō)，Scrum 是用于開(kāi)發(fā)、交付和持續(xù)支持復(fù)雜產(chǎn)品的一個(gè)框架，是一個(gè)增量的、迭代的開(kāi)發(fā)過(guò)程。Scrum起源于軟件開(kāi)發(fā)項(xiàng)目，Scrum包括了一系列實(shí)踐和預(yù)定義角色的過(guò)程骨架。Scrum中的主要角色包括同項(xiàng)目經(jīng)理類似的Scrum主管角色負(fù)責(zé)維護(hù)過(guò)程和任務(wù)，產(chǎn)品負(fù)責(zé)人代表利益所有者，開(kāi)發(fā)團(tuán)隊(duì)包括了所有開(kāi)發(fā)人員。雖然Scrum是為管理軟件開(kāi)發(fā)項(xiàng)目而開(kāi)發(fā)的，它同樣可以用于運(yùn)行軟件維護(hù)團(tuán)隊(duì)，或者作為計(jì)劃管理方法，適用于任何復(fù)雜的或是創(chuàng)新性的項(xiàng)目。如Scrum 目前已被用于開(kāi)發(fā)軟件、硬件、嵌入式軟件、交互功能網(wǎng)絡(luò)、自動(dòng)駕駛、學(xué)校、政府、市場(chǎng)、管理組織運(yùn)營(yíng)，以及日常生活中更廣泛的產(chǎn)品開(kāi)發(fā)領(lǐng)域。
2.2 SCRUM流程
Scrum整個(gè)開(kāi)發(fā)流程(見(jiàn)圖2) 由若干個(gè)短的迭代周期組成，一個(gè)短的迭代周期稱為一個(gè)Sprint，每個(gè)Sprint的建議長(zhǎng)度是一至四周。在Scrum中，使用產(chǎn)品Backlog來(lái)管理產(chǎn)品的需求，產(chǎn)品backlog是一個(gè)按照商業(yè)價(jià)值排序的需求列表，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊(duì)總是先開(kāi)發(fā)對(duì)客戶具有較高價(jià)值的需求。在Sprint中，Scrum團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最高優(yōu)先級(jí)的需求進(jìn)行開(kāi)發(fā)。挑選的需求在Sprint計(jì)劃會(huì)議上經(jīng)過(guò)討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog。在每個(gè)迭代結(jié)束時(shí)，Scrum團(tuán)隊(duì)將提交潛在可交付的產(chǎn)品增量。
圖2 Scrum流程圖
2.3 SCRUM框架
Scrum框架包括3個(gè)角色、3個(gè)工件、5個(gè)事件、5個(gè)價(jià)值：3個(gè)角色：產(chǎn)品負(fù)責(zé)人（Product Owner）、Scrum Master、開(kāi)發(fā)團(tuán)隊(duì)3個(gè)工件：產(chǎn)品Backlog（Product Backlog）、SprintBacklog、產(chǎn)品增量（Increment）5個(gè)事件：Sprint（Sprint本身是一個(gè)事件，包括了如下4個(gè)事件）、Sprint計(jì)劃會(huì)議（Sprint Planning Meeting）、每日站會(huì)（Daily Scrum Meeting）、Sprint評(píng)審會(huì)議（Sprint Review Meeting）、Sprint回顧會(huì)議（Sprint Retrospective Meeting）5個(gè)價(jià)值：承諾 – 愿意對(duì)目標(biāo)做出承諾、專注– 把你的心思和能力都用到你承諾的工作上去、開(kāi)放– Scrum 把項(xiàng)目中的一切開(kāi)放給每個(gè)人看、尊重– 每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)、勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重
3.
DevOps
3.1 DevOps 定義
DevOps 是開(kāi)發(fā) (Dev) 和運(yùn)營(yíng) (Ops) 的復(fù)合詞，是一組過(guò)程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開(kāi)發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門(mén)之間的溝通、協(xié)作與整合。
3.2 DevOps 發(fā)展背景
傳統(tǒng)的軟件組織將開(kāi)發(fā)、IT運(yùn)營(yíng)和質(zhì)量保障設(shè)為各自分離的部門(mén)。在這種環(huán)境下如何采用新的開(kāi)發(fā)方法（例如敏捷軟件開(kāi)發(fā)），這是一個(gè)重要的課題：按照從前的工作方式，開(kāi)發(fā)和部署不需要IT支持或者QA深入的、跨部門(mén)的支持，而卻需要極其緊密的多部門(mén)協(xié)作。然而DevOps考慮的還不止是軟件部署。它是一套針對(duì)這幾個(gè)部門(mén)間溝通與協(xié)作問(wèn)題的流程和方法[9]。
以下幾方面因素可能促使一個(gè)組織引入DevOps：
1、使用敏捷或其他軟件開(kāi)發(fā)過(guò)程與方法
2、業(yè)務(wù)負(fù)責(zé)人要求加快產(chǎn)品交付的速率
3、虛擬化和云計(jì)算基礎(chǔ)設(shè)施（可能來(lái)自內(nèi)部或外部供應(yīng)商）日益普遍
4、數(shù)據(jù)中心自動(dòng)化技術(shù)和配置管理工具的普及
5、有一種觀點(diǎn)認(rèn)為，占主導(dǎo)地位的“傳統(tǒng)”美國(guó)式管理風(fēng)格（“斯隆模型 vs 豐田模型”）會(huì)導(dǎo)致“煙囪式自動(dòng)化”，從而造成開(kāi)發(fā)與運(yùn)營(yíng)之間的鴻溝，因此需要DevOps能力來(lái)克服由此引發(fā)的問(wèn)題。
DevOps經(jīng)常被描述為“開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)之間更具協(xié)作性、更高效的關(guān)系”。由于團(tuán)隊(duì)間協(xié)作關(guān)系的改善，整個(gè)組織的效率因此得到提升，伴隨頻繁變化而來(lái)的生產(chǎn)環(huán)境的風(fēng)險(xiǎn)也能得到降低。
在云計(jì)算、大數(shù)據(jù)等技術(shù)顛覆性趨勢(shì)繼續(xù)在應(yīng)用經(jīng)濟(jì)下發(fā)揮作用的同時(shí)，DevOps也已經(jīng)穩(wěn)健地在業(yè)務(wù)思維方式中占有一席之地，并將扮演主要角色。在應(yīng)用驅(qū)動(dòng)、云連接、移動(dòng)化的大環(huán)境下，對(duì)于很多公司來(lái)說(shuō)DevOps是助力業(yè)務(wù)增值戰(zhàn)略的第一步。
緊跟行業(yè)趨勢(shì)、進(jìn)行新的技術(shù)變革往往會(huì)帶來(lái)發(fā)展的陣痛，DevOps也同樣要經(jīng)歷這一過(guò)程。中國(guó)及全球各地的企業(yè)正在認(rèn)識(shí)到DevOps可以助力軟件開(kāi)發(fā)速度加快，軟件應(yīng)用質(zhì)量提升，更重要的是與業(yè)務(wù)目標(biāo)更完美地結(jié)合。
3.3 DevOps 文化
1) 協(xié)作、可見(jiàn)性和一致性
健康的 DevOps 文化的一個(gè)標(biāo)志是團(tuán)隊(duì)間能夠協(xié)作，首要的便是可見(jiàn)性。開(kāi)發(fā)和 IT 運(yùn)營(yíng)等不同團(tuán)隊(duì)必須能夠相互分享 DevOps 流程、優(yōu)先級(jí)和關(guān)注點(diǎn)。這些團(tuán)隊(duì)還必須能夠共同規(guī)劃工作，并統(tǒng)一與業(yè)務(wù)相關(guān)的成功目標(biāo)和衡量標(biāo)準(zhǔn)。
2) 范圍和責(zé)任的轉(zhuǎn)變
當(dāng)團(tuán)隊(duì)統(tǒng)一時(shí)，他們擁有所有權(quán)并參與其他生命周期階段，而不僅僅是他們的角色對(duì)應(yīng)的階段。例如，開(kāi)發(fā)人員不僅要對(duì)開(kāi)發(fā)階段的創(chuàng)新和質(zhì)量負(fù)責(zé)，還要對(duì)他們的改變?cè)谶\(yùn)營(yíng)階段帶來(lái)的性能和穩(wěn)定性負(fù)責(zé)。同時(shí)，IT 操作員一定要在規(guī)劃和開(kāi)發(fā)階段中考慮治理、安全性和符合性。
3) 縮短發(fā)布周期
DevOps 團(tuán)隊(duì)通過(guò)短周期發(fā)布軟件保持敏捷。因?yàn)檫M(jìn)度是漸進(jìn)式的，縮短發(fā)布周期可以讓計(jì)劃和風(fēng)險(xiǎn)管理更容易，同時(shí)也減少了對(duì)系統(tǒng)穩(wěn)定性的影響?？s短發(fā)布周期還可以讓組織適應(yīng)和應(yīng)對(duì)不斷變化的客戶需求和競(jìng)爭(zhēng)壓力。
4) 持續(xù)學(xué)習(xí)
高績(jī)效的 DevOps 團(tuán)隊(duì)形成了一種成長(zhǎng)思維。他們快速失敗，然后將經(jīng)驗(yàn)教訓(xùn)融入到他們的流程中，不斷改進(jìn)，提高客戶滿意度，加速創(chuàng)新和適應(yīng)市場(chǎng)。DevOps 是一個(gè)旅程，所以總有成長(zhǎng)的空間。
3.4 DevOps 和應(yīng)用程序生命周期
DevOps 影響應(yīng)用程序生命周期的規(guī)劃、開(kāi)發(fā)、交付和運(yùn)營(yíng)階段。每個(gè)階段都依賴于其他階段，并且這些階段并非特定于角色。在真正的 DevOps 文化中，每個(gè)角色在某種程度上說(shuō)都涉及各個(gè)階段如圖 4。
圖 4 DevOps 和應(yīng)用程序生命周期
3.5 DevOps 做法
除了形成 DevOps 文化之外，團(tuán)隊(duì)還通過(guò)在整個(gè)應(yīng)用程序生命周期中實(shí)施特定做法，以充分利用 DevOps。- 持續(xù)集成和持續(xù)交付 (CI/CD)
- 版本控制
- 敏捷軟件開(kāi)發(fā)
- 基礎(chǔ)結(jié)構(gòu)即代碼
- 配置管理
-
持續(xù)監(jiān)控
其中一些做法有助于加速、自動(dòng)化和改進(jìn)特定階段。有的跨越幾個(gè)階段，幫助團(tuán)隊(duì)創(chuàng)建提高生產(chǎn)效率的無(wú)縫進(jìn)程。
3.6 DevOps 工具
無(wú)論是縱向集成還是橫向集成，DevOps都需要通過(guò)工具鏈與持續(xù)集成、交付、反饋與優(yōu)化進(jìn)行端到端整合。如華為的軟件開(kāi)發(fā)云服務(wù), 基于二十幾年的研發(fā)實(shí)踐，融合DevOps理念方法，為企業(yè)提供一站式的云上開(kāi)發(fā)工具平臺(tái)。華為軟件開(kāi)發(fā)云提供項(xiàng)目管理、配置管理、代碼檢查、編譯構(gòu)建、測(cè)試、部署、發(fā)布等端到端地覆蓋全軟件生命周期的相關(guān)服務(wù)。類似的DevOps 工具數(shù)不勝數(shù)，常見(jiàn)的DevOps 生態(tài)圈工具如圖 5。
3.7 DevOps 與Agile 的關(guān)聯(lián)
DevOps 和 Agile 都是用于生產(chǎn)產(chǎn)品、進(jìn)行發(fā)布或發(fā)行的現(xiàn)代軟件開(kāi)發(fā)框架。DevOps 是一種文化，促進(jìn)軟件開(kāi)發(fā)和維護(hù)中所有角色之間的協(xié)作。Agile 是一種開(kāi)發(fā)方法，在需求不斷變化的常見(jiàn)現(xiàn)實(shí)中保持工作效率和促進(jìn)發(fā)布。DevOps 和 Agile 并不是相互排斥的，而是經(jīng)常搭配使用。
4.
持續(xù)集成
4.1 持續(xù)集成背景
集成軟件的過(guò)程不是新問(wèn)題，如果項(xiàng)目開(kāi)發(fā)的規(guī)模比較小，比如一個(gè)人的項(xiàng)目，如果它對(duì)外部系統(tǒng)的依賴很小，那么軟件集成不是問(wèn)題，但是隨著軟件項(xiàng)目復(fù)雜度的增加（即使增加一個(gè)人），就會(huì)對(duì)集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項(xiàng)目在早期發(fā)現(xiàn)項(xiàng)目風(fēng)險(xiǎn)和質(zhì)量問(wèn)題，如果到后期才發(fā)現(xiàn)這些問(wèn)題，解決問(wèn)題代價(jià)很大，很有可能導(dǎo)致項(xiàng)目延期或者項(xiàng)目失敗。
4.2 持續(xù)集成定義
大師Martin Fowler對(duì)持續(xù)集成是這樣定義的:
持續(xù)集成是一種軟件開(kāi)發(fā)實(shí)踐，即團(tuán)隊(duì)開(kāi)發(fā)成員經(jīng)常集成它們的工作，通常每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過(guò)自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測(cè)試)來(lái)驗(yàn)證，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過(guò)程可以大大減少集成的問(wèn)題，讓團(tuán)隊(duì)能夠更快的開(kāi)發(fā)內(nèi)聚的軟件。
4.3 持續(xù)集成的價(jià)值
-
減少風(fēng)險(xiǎn)
一天中進(jìn)行多次的集成，并做了相應(yīng)的測(cè)試，這樣有利于檢查缺陷，了解軟件的健康狀況，減少假定。
-
減少重復(fù)過(guò)程
減少重復(fù)的過(guò)程可以節(jié)省時(shí)間、費(fèi)用和工作量。說(shuō)起來(lái)簡(jiǎn)單，做起來(lái)難。這些浪費(fèi)時(shí)間的重復(fù)勞動(dòng)可能在我們的項(xiàng)目活動(dòng)的任何一個(gè)環(huán)節(jié)發(fā)生，包括代碼編譯、數(shù)據(jù)庫(kù)集成、測(cè)試、審查、部署及反饋。通過(guò)自動(dòng)化的持續(xù)集成可以將這些重復(fù)的動(dòng)作都變成自動(dòng)化的，無(wú)需太多人工干預(yù)，讓人們的時(shí)間更多的投入到動(dòng)腦筋的、更高價(jià)值的事情上。
-
任何時(shí)間、任何地點(diǎn)生成可部署的軟件
持續(xù)集成可以讓您在任何時(shí)間發(fā)布可以部署的軟件。從外界來(lái)看，這是持續(xù)集成最明顯的好處，我們可以對(duì)改進(jìn)軟件品質(zhì)和減少風(fēng)險(xiǎn)說(shuō)起來(lái)滔滔不絕，但對(duì)于客戶來(lái)說(shuō)，可以部署的軟件產(chǎn)品是最實(shí)際的資產(chǎn)。利用持續(xù)集成，您可以經(jīng)常對(duì)源代碼進(jìn)行一些小改動(dòng)，并將這些改動(dòng)和其他的代碼進(jìn)行集成。如果出現(xiàn)問(wèn)題，項(xiàng)目成員馬上就會(huì)被通知到，問(wèn)題會(huì)第一時(shí)間被修復(fù)。不采用持續(xù)集成的情況下，這些問(wèn)題有可能到交付前的集成測(cè)試的時(shí)候才發(fā)現(xiàn)，有可能會(huì)導(dǎo)致延遲發(fā)布產(chǎn)品，而在急于修復(fù)這些缺陷的時(shí)候又有可能引入新的缺陷，最終可能導(dǎo)致項(xiàng)目失敗。
-
增強(qiáng)項(xiàng)目的可見(jiàn)性
持續(xù)集成讓我們能夠注意到趨勢(shì)并進(jìn)行有效的決策。如果沒(méi)有真實(shí)或最新的數(shù)據(jù)提供支持，項(xiàng)目就會(huì)遇到麻煩，每個(gè)人都會(huì)提出他最好的猜測(cè)。通常，項(xiàng)目成員通過(guò)手工收集這些信息，增加了負(fù)擔(dān)，也很耗時(shí)。持續(xù)集成可以帶來(lái)兩點(diǎn)積極效果：
(1)有效決策：持續(xù)集成系統(tǒng)為項(xiàng)目構(gòu)建狀態(tài)和品質(zhì)指標(biāo)提供了及時(shí)的信息，有些持續(xù)集成系統(tǒng)可以報(bào)告功能完成度和缺陷率。
(2)注意到趨勢(shì)：由于經(jīng)常集成，我們可以看到一些趨勢(shì)，如構(gòu)建成功或失敗、總體品質(zhì)以及其它的項(xiàng)目信息。
建立團(tuán)隊(duì)對(duì)開(kāi)發(fā)產(chǎn)品的信心
持續(xù)集成可以建立開(kāi)發(fā)團(tuán)隊(duì)對(duì)開(kāi)發(fā)產(chǎn)品的信心，因?yàn)樗麄兦宄闹烂恳淮螛?gòu)建的結(jié)果，他們知道他們對(duì)軟件的改動(dòng)造成了哪些影響，結(jié)果怎么樣。
4.4 持續(xù)集成的要點(diǎn)
- 統(tǒng)一的代碼庫(kù)
- 自動(dòng)構(gòu)建
- 自動(dòng)測(cè)試
- 每個(gè)人每天都要向代碼庫(kù)主干提交代碼
- 每次代碼遞交后都會(huì)在持續(xù)集成服務(wù)器上觸發(fā)一次構(gòu)建
-
保證快速構(gòu)建
-
模擬生產(chǎn)環(huán)境的自動(dòng)測(cè)試
-
每個(gè)人都可以很容易的獲取最新可執(zhí)行的應(yīng)用程序
-
每個(gè)人都清楚正在發(fā)生的狀況
-
自動(dòng)化的部署
4.5 持續(xù)集成的原則
-
所有的開(kāi)發(fā)人員需要在本地機(jī)器上做本地構(gòu)建，然后再提交到版本控制庫(kù)中，從而確保他們的變更不會(huì)導(dǎo)致持續(xù)集成失敗。
-
開(kāi)發(fā)人員每天至少向版本控制庫(kù)中提交一次代碼。
-
開(kāi)發(fā)人員每天至少需要從版本控制庫(kù)中更新一次代碼到本地機(jī)器。
-
需要有專門(mén)的集成服務(wù)器來(lái)執(zhí)行集成構(gòu)建,每天要執(zhí)行多次構(gòu)建。
-
每次構(gòu)建都要100%通過(guò)。
-
每次構(gòu)建都可以生成可發(fā)布的產(chǎn)品。
-
修復(fù)失敗的構(gòu)建是優(yōu)先級(jí)最高的事情。
-
測(cè)試是未來(lái)，未來(lái)是測(cè)試。
4.6 持續(xù)集成的工作流程
持續(xù)集成（Continuous integration，簡(jiǎn)稱CI）是軟件的開(kāi)發(fā)和發(fā)布標(biāo)準(zhǔn)流程中最重要的部分。作為一種開(kāi)發(fā)實(shí)踐，在CI中可以通過(guò)自動(dòng)化等手段高頻率地去獲取產(chǎn)品反饋并響應(yīng)反饋的過(guò)程。簡(jiǎn)單來(lái)說(shuō)，就是持續(xù)不斷地（一天多次）將代碼合并（集成）到主干源碼倉(cāng)庫(kù)，讓產(chǎn)品可以快速迭代，同時(shí)保持高質(zhì)量。
持續(xù)集成強(qiáng)調(diào)對(duì)于開(kāi)發(fā)人員的每個(gè)提交，立刻進(jìn)行構(gòu)建、掃描、（單元）測(cè)試。根據(jù)結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。如一個(gè)完整的CI系統(tǒng)應(yīng)該包含3個(gè)基本模塊：
一個(gè)可以自動(dòng)構(gòu)建的過(guò)程，自動(dòng)編譯代碼，可以自動(dòng)分發(fā)，部署和測(cè)試。
一個(gè)代碼倉(cāng)庫(kù)，例如Git。
一個(gè)持續(xù)集成的服務(wù)器。
如圖 3是典型的持續(xù)集成流程圖。
圖3持續(xù)集成流程圖
正如圖3持續(xù)集成流程所示，通用的持續(xù)集成（CI）流程主要包括：
-
簽出代碼：
從源碼管理系統(tǒng)里簽出或者克隆最新的代碼到本地開(kāi)發(fā)環(huán)境
-
提交（commit）：
基于主干分支創(chuàng)建一個(gè)新的功能分支，并在此分支編寫(xiě)代碼，并向倉(cāng)庫(kù)提交代碼
-
測(cè)試（第1輪）：代碼倉(cāng)庫(kù)對(duì)commit操作配置了鉤子（hook）， 每一次提交代碼都會(huì)觸發(fā)測(cè)試。單元測(cè)試（針對(duì)函數(shù)或模塊的測(cè)試）和功能測(cè)試（集成測(cè)試）將會(huì)被執(zhí)行、根據(jù)需要設(shè)置是否執(zhí)行端對(duì)端測(cè)試。一般來(lái)說(shuō)，這些測(cè)試也會(huì)被打包到代碼里。
-
構(gòu)建（build）：通過(guò)測(cè)試（第1輪）后，將源碼轉(zhuǎn)換為可以運(yùn)行的實(shí)際代碼，比如安裝依賴，配置各種資源等。
-
測(cè)試（第2輪）：以自動(dòng)化為主的全面測(cè)試，包括單元測(cè)試和集成測(cè)試，必要時(shí)做端對(duì)端測(cè)試，確保新版本的每一個(gè)更新點(diǎn)都必須測(cè)試到。
-
合并：通過(guò)測(cè)試（第2輪）后，將代碼更新集成到主干。
-
回滾：如果當(dāng)前版本發(fā)生問(wèn)題，就回滾到上一個(gè)版本的構(gòu)建結(jié)果一般來(lái)說(shuō)，CI服務(wù)器會(huì)配置成在遇到故障時(shí)發(fā)送郵件相關(guān)人員，可以快速知曉故障并且盡快采取更正措施。
4.7 持續(xù)集成注意事項(xiàng)
當(dāng)需要代碼變更并集成時(shí)，開(kāi)發(fā)者會(huì)從基礎(chǔ)代碼庫(kù)復(fù)制以進(jìn)行作業(yè)，其他開(kāi)發(fā)者提交代碼的變更至來(lái)源代碼庫(kù)，并透過(guò)副本的方式取代來(lái)源代碼庫(kù)的代碼。不只變更目前的代碼庫(kù)，新的代碼也可以新增成為程序庫(kù)、其它共享資源與潛在沖突。
當(dāng)分支代碼開(kāi)發(fā)者進(jìn)行主線重新集成時(shí)，當(dāng)分支代碼保持在取出狀態(tài)時(shí)間越長(zhǎng)，就愈容易遭遇集成多重沖突的風(fēng)險(xiǎn)以及集成失敗。因?yàn)樗麄兡玫降氖歉北?，所以?dāng)開(kāi)發(fā)者將代碼提交到代碼庫(kù)時(shí)，首先必須更新代碼以反映他們?cè)诖a庫(kù)中的更改。代碼庫(kù)包含的更改越多，開(kāi)發(fā)人員在提交自己的更改前必須運(yùn)行的基礎(chǔ)工作就越多。
最終，該程序庫(kù)也許變成非常不同于開(kāi)發(fā)者的目標(biāo)代碼，他們進(jìn)入有時(shí)候被稱為合并地獄或集成地獄的階段，這時(shí)候開(kāi)發(fā)者所花費(fèi)的集成時(shí)間，將超過(guò)最初代碼開(kāi)發(fā)的時(shí)間。
持續(xù)集成涉及預(yù)先集成與預(yù)先與經(jīng)常性的集成，借此來(lái)避免掉入集成地獄的陷阱，實(shí)踐的目標(biāo)是減少重工、減少成本與時(shí)間。
持續(xù)集成補(bǔ)充的實(shí)踐是在提交代碼之前，每個(gè)開(kāi)發(fā)人員必須運(yùn)行一個(gè)完整的構(gòu)建并通過(guò)所有的單元測(cè)試、集成測(cè)試。當(dāng)持續(xù)集成服務(wù)器偵測(cè)到代碼有新的提交時(shí)，必須經(jīng)常性與自動(dòng)化的進(jìn)行此類單元測(cè)試或集成測(cè)試任務(wù)。代碼每次集成到主干之前，必須通過(guò)自動(dòng)化測(cè)試，以便快速發(fā)現(xiàn)和定位錯(cuò)誤。值得注意的是，持續(xù)集成并不能消除錯(cuò)誤，而是讓它們非常容易發(fā)現(xiàn)和改正。
轉(zhuǎn)載汽車電子相關(guān)文章
轉(zhuǎn)自汽車電子與軟件
