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