敏捷開(kāi)發

1.1 什(shén)麽是(shì)敏捷?

       敏捷是(sh₽<£ì)用(yòng)于描述軟件(jiàn)開(kāi)發​€方法的(de)術(shù)語，強調增量交付、團隊協作(zuò)÷♥δ、持續規劃和(hé)持續學習(xí)。"敏捷"一(yī)詞源于2001年(n<$$≠ián)《敏捷宣言》。宣言旨在确立指導軟件(jiàn)開(kāi)發更優方法的(de)原♦λσ&則。其核心是(shì)宣布代表敏捷運動基礎的(de)4項價值觀：

• 個(gè)體(tǐ)和(hé)交互 勝過 過程和( ¥φhé)工(gōng)具
• 可(kě)以工(gōng)作(zuò)的(de)軟件(jiàn) 勝過 面面俱到$σ(dào)的(de)文(wén)檔
• 客戶合作(zuò) 勝過 合同談判

• 響應變化(huà) 勝過 遵循計(jì)劃

     ≥‌♥≤ 依據以上(shàng)四條價值觀，衍生(shēng)出來(lái)更具體(♠™γtǐ)的(de)十二大(dà)原則，作(zuò)為(wèi)¥σ→×對(duì)敏捷宣言更具實操性的(de)解釋，其具體(tǐ)原則內(nèi)£≥容如(rú)下(xià)：

      1) 最重要(yào)的(de)是(shì>α)通(tōng)過盡早和(hé)不(bù)斷交付有(yǒu)價值的(de)軟件(jiàn)÷$滿足客戶需要(yào)。

      2) 我們歡迎需求的(de)←≠☆變化(huà)，即使在開(kāi)發後期。敏捷過程能(néπ‌₹€ng)夠駕馭變化(huà)，保持客戶的(de)競争優≈♦★勢。

      3) 經常交付可(kě)以工(gōng)作(zuΩ $£ò)的(de)軟件(jiàn)，從(cóng)幾星•±​​期到(dào)幾個(gè)月(yuè)，時(shí)間(jiān)尺度越短(du★→ǎn)越好(hǎo)。

      4) 業($✔✘‌yè)務人(rén)員(yuán)和(hé)開(kāi)發者應該在整個(gè)項目過★♥ φ程中始終朝夕在一(yī)起工(gōng)作(zuò)。

      5) 圍繞鬥志(zhì)高(gāoπ∞)昂的(de)人(rén)進行(xíng)軟件(jiàn)開(kāi÷☆  )發，給開(kāi)發者提供适宜的(de)環境，滿足他(tā)們δ✔×的(de)需要(yào)，并相(xiàng)信他(tā)們能(néng"₽←)夠完成任務。

      6) 在開(k←₽āi)發小(xiǎo)組中最有(yǒu)效率也(yě)最有(yǒu)效果的(de)信息傳達方式是®£₽(shì)面對(duì)面的(de)交談。

      7) 可(kě)以工(gōng)作(zuò)的(de)軟φφ件(jiàn)是(shì)進度的(de)主要(yào™φ®)度量标準。

      8≈✘) 敏捷過程提倡可(kě)持續開(kāi)發。出資人(rén₽‌)、開(kāi)發人(rén)員(yuán)和(hé)用★ε(yòng)戶應該總是(shì)維持不(bù)變的(d€π §e)節奏。

      9) 對(duì)卓越∞λ✔技(jì)術(shù)與良好(hǎo)設計(jì)的(de)不(b☆> ù)斷追求将有(yǒu)助于提高(gāo) $±敏捷性。

    10) 簡單——盡可(kěβ"π♠)能(néng)減少(shǎo)工(gōng)作(zuò)量的(de)藝術(shù)至關™÷重要(yào)。

    11) 最好(hǎo)的(de)架構、需求和(hé)設計(jì)≈₽​♥都(dōu)源自(zì)自(zì)我組織的(de)團隊。

    12) 每隔一(yī)定時(shí)間(jiān)，≥ ↑±團隊都(dōu)要(yào)總結如(rú)何更有(yǒu)效率，然後相(xiàng)應地(dì)₹'調整自(zì)己的(de)行(xíng)為(wèi)↕÷π↑。

1.2 敏捷開(kāi)發概念與'β≠特點

      敏捷開(kāi)發是(sh₩​≤ì)一(yī)種從(cóng)1990年(ππ≤nián)代開(kāi)始逐漸引起廣泛關注的(de)新型軟件(jiàn)開(kāi)發方法，是→λ<(shì)一(yī)種應對(duì)快(kuà™∏i)速變化(huà)的(de)需求的(de)一(yī)種軟件(jiàn)開φ¥εβ(kāi)發能(néng)力。它們的(de)±£具體(tǐ)名稱、理(lǐ)念、過程、術(shù)語都(dōu)不(bù)盡相(xià← ‍>ng)同，相(xiàng)對(duì)于“非敏捷”，更強調程序員(yuá•₽n)團隊與業(yè)務專家(jiā)之間(jiān​±​λ)的(de)緊密協作(zuò)、面對(duì)面的(de)溝通(tōng)、頻(pín)繁φ>交付新的(de)軟件(jiàn)版本、緊湊而自(zì)我組織型的(de)團隊、能(néng)夠很♣™(hěn)好(hǎo)地(dì)适應需求變化(huà)的(de)代碼編寫和(hé)團隊組織方法↑$→≥，也(yě)更注重軟件(jiàn)開(kāi)發中人(rén)的(©×<↑de)作(zuò)用(yòng)。

敏捷開(kāi)發是(shì)用(yòng)于描述叠代軟件(jiγ÷àn)開(kāi)發的(de)術(shù)語。敏捷開(kāi)發通(tōng)常與傳統或瀑布β₩開(kāi)發形成對(duì)比，在傳統或瀑布開(kāi)發中，大(dà)型項目是₽©♦(shì)按照(zhào)該計(jì)劃進行(xíng)規劃和(hé)執行(xíng)的(d₽₩₽∑e)。

      敏捷開(kāi)發以用(≈₽yòng)戶的(de)需求進化(huà)為(wèi)核↑♥₽心，采用(yòng)叠代、循序漸進的(de)方法進行(xíng)軟件(jiàn)開(₽→÷±kāi)發。在敏捷開(kāi)發中，軟件(jiàn)項目在構建初期被切分(fēn)成多(d∑"uō)個(gè)子(zǐ)項目，各個(gè)γ•子(zǐ)項目的(de)成果都(dōu)經過測試，具備可( ↑kě)視(shì)、可(kě)集成和(hé)可(kě)運行(xíng)使用(y£α<òng)的(de)特征。換言之，就(jiù)是(shì)把一(yīφ™φ€)個(gè)大(dà)項目分(fēn)為(wèi)多≠δ(duō)個(gè)相(xiàng)互聯系，但(dàn)也(yě)可(kě)獨立運行(xíng)的↕♦÷≤(de)小(xiǎo)項目，并分(fēn)别完成，在此過程中軟件($φjiàn)一(yī)直處于可(kě)使用(yòng)狀态。叠αβ®代軟件(jiàn)開(kāi)發縮短(duǎn)了>♥(le)軟件(jiàn)開(kāi)發生(shēng)命周期。

1.3 敏捷開(kāi)發流程

      λ♣敏捷開(kāi)發團隊以較小(xiǎo)的(de)增量執行(xíng)整個(gè)軟件(jiàn‌&λ)開(kāi)發生(shēng)命周期，通(tōng)常稱為→≠δ (wèi)沖刺（sprint）。沖刺通(tōng)常有(yǒu)1-4周長(γ®cháng)。每次沖刺交付産品級代碼都(dōu)需>✔↔要(yào)敏捷的(de)開(kāi)發團隊來(lái)應對(duì)加速的(de)步伐。所有(y™<↓™ǒu)編碼、測試和(hé)質量驗證都(dōu)必須≠€在每個(gè)沖刺階段完成。各團隊間(jiān)應密切協作(zuò)，否則可(kě)能(néng★>≥✘)會(huì)導緻失敗甚至慘敗。

圖1：敏捷開(kāi)發流程示意圖

      敏捷開(kāi)發團隊幾個(g∑Ω è)關鍵的(de)成功因素：

      1. 細化(huà)需求列表

      2. 早期并高(gāo)頻(pí‌✔λ★n)集成

      3. 盡♥♣量避免技(jì)術(shù)缺陷

1.4 敏捷方法與最佳實踐

       敏捷是•≠™(shì)一(yī)種尋找軟件(jiàn)開(k β  āi)發方法的(de)态度。敏捷方法中沒有(yǒu)≠≤一(yī)種方法适用(yòng)于所有(yǒu)情況，而"敏捷™δ"一(yī)詞已經代表與宣言中的(de)價值陳述'•一(yī)緻的(de)各種敏捷方法與最佳實踐。

       敏捷方法是(₽☆λλshì)一(yī)個(gè)囊括了(le)₩★↓各種框架和(hé)方法的(de)涵蓋性術(shù)語，它指的(de)是(shì)符合《敏捷宣©β言》價值觀和(hé)原則的(de)任何方法、↕φ技(jì)術(shù)、框架、手段或實踐。敏捷方法（通(tōng)常稱為(wèi)敏↓ε捷框架）是(shì)軟件(jiàn)開(kāi)發生(shēngε<φ)命周期階段（規劃、執行(xíng)和(hé)交付）¶‍≠的(de)綜合方法。它規定了(le)一(yī)套在明(mí±γng)确的(de)指導和(hé)原則下(xià)完成工(gōng)作(zuò)的(de)方法♠™↑。

      敏捷→®♦₩方法主要(yào)包括SCRUM方法、DSDM 方法、水(shuǐ)晶方法、特性₽ ₽ε驅動方法和(hé) SCRUMBAN 等。例如(rú)Scrum是(shì)最常見(j♦±&εiàn)的(de)敏捷框架。持續集成（Continu<γ£ous Integration，CI）是(shì)常見(jiàn"‍¥‍)的(de)敏捷工(gōng)程實踐方法。

需要(yào)說(shuō)明(míng)的(de)是(shì)，敏捷方法與最佳實踐并不(bù÷φ↑)承諾解決每一(yī)個(gè)問(wèn)題，但(dàn)他(tā)們确↔<±∞實承諾建立一(yī)個(gè)文(wén)化(huà)和(hé>"∞ )環境，通(tōng)過協作(zuò)，不(bù)斷的(de)規劃和(×±•★hé)學習(xí)，并快(kuài)速叠代交付高(gāo₩÷ ™)質量的(de)軟件(jiàn)，最終滿足客戶需求。

2. 

SCRUM方法

2.1 SCRUM綜述

      &nbsλ$p;Scrum 是(shì)團隊用(yòng)于管理(lǐ)其工(gōng)作(zuò)的(de₽∞)框架，将敏捷原則作(zuò)為(wèi)一(yī)套具體(λπ↓♦tǐ)的(de)工(gōng)件(jiàn)、實踐和(hé±πε)角色，通(tōng)常用(yòng)于敏捷軟件(jiàn)開(kāi)發。σγβ•具體(tǐ)來(lái)說(shuō)，S™↓crum 是(shì)用(yòng)于開(kāi)發、交付和(hé)持續$ 支持複雜(zá)産品的(de)一(yī)個(gè)框架，是(shì)一(yī)個β‍ (gè)增量的(de)、叠代的(de)開(kāi)發過程$★。Scrum起源于軟件(jiàn)開(kāi™÷§)發項目，Scrum包括了(le)一(yī)系列實踐和(hé)✔α預定義角色的(de)過程骨架。Scrum中的(β✘£de)主要(yào)角色包括同項目經理(lǐ)類似的(de)Scrum主管角§★色負責維護過程和(hé)任務，産品負責人(✘πrén)代表利益所有(yǒu)者，開(kāi)發團隊包括了(le)所有(yǒu∏♥±)開(kāi)發人(rén)員(yuán)。雖然Scrum是(shì)為(w ≤èi)管理(lǐ)軟件(jiàn)開(kāi)發項目而開(kāi)發的(☆βde)，它同樣可(kě)以用(yòng)于運行(xíngα★Ω)軟件(jiàn)維護團隊，或者作(zuò)為(wèi)計(jì)劃管理(lǐ)方法，适用(yònφ♣♣≈g)于任何複雜(zá)的(de)或是(shì)創新性的(de)項目。如(rú)Scru® m 目前已被用(yòng)于開(kāi)發軟•>&件(jiàn)、硬件(jiàn)、嵌入式軟件(jiàn)↔✘¶♣、交互功能(néng)網絡、自(zì)動駕駛、學校(xiào)、政府、≈→π₽市(shì)場(chǎng)、管理(lǐ)組織運營，以及日(rì)常生(shēng)活中更廣泛的($≠±de)産品開(kāi)發領域。

2.2 SCRUM流程

       Sc♣αrum整個(gè)開(kāi)發流程(見(jiàn)圖2) 由若幹個(  gè)短(duǎn)的(de)叠代周期組成，一(yī)個(gè)短(®®₹​duǎn)的(de)叠代周期稱為(wèi)一(yī)個(gè)Sprint，每個(gè)Spr≤☆σint的(de)建議(yì)長(cháng)度是(shì)一(yī)至四周。在Scr÷♦€€um中，使用(yòng)産品Backlog來(lπ∑ái)管理(lǐ)産品的(de)需求，産品backlog是(shì)一(yī)個(gè)↓₩♥γ按照(zhào)商業(yè)價值排序的(de)需求列表，列表條目的(de)體(tǐ)現(xi©¶πàn)形式通(tōng)常為(wèi)用(yòng)戶故事(shì)。Scrum團隊總是(shì<♣₩≈)先開(kāi)發對(duì)客戶具有(yǒu)較高(gāo)價" 值的(de)需求。在Sprint中，Scrum團隊從(cóng)産品Backlog中挑→ $選最高(gāo)優先級的(de)需求進行(xíng)開(kāi)發。挑選的(de)需求在S→£print計(jì)劃會(huì)議(yì)上(shàng)₽↓↕®經過討(tǎo)論、分(fēn)析和(hé)估算(suàn)得(d₩≤&©e)到(dào)相(xiàng)應的(de)任務列表，我們稱它為&π§±(wèi)Sprint backlog。σγ☆γ在每個(gè)叠代結束時(shí)，Scrum團隊将提交潛在可•<(kě)交付的(de)産品增量。

圖2 Scrum流程圖

2.3 SCRUM框架

      Scrum框架包括3個(gè)角色、3個(gβσπ∞è)工(gōng)件(jiàn)、5個(gèΩ♠)事(shì)件(jiàn)、5個(gè)價值：3個(gè)角色：産品負責人(rén)（Product Owner）、Scrum Master、®₹開(kāi)發團隊3個(gè)工(gōng)件(jiàn)：産品Backlog（Product Backlog）、Sprint₽©Backlog、産品增量（Increment）5個(gè)事(shì)件(jiàn)：Sprint（Sprint本身(shēn)是(shì)一(yī)個(gè↔‍)事(shì)件(jiàn)，包括了(le)如(rú)下(xià)4個(gè)事±∏γ↑(shì)件(jiàn)）、Sprint計(jì)劃會α♠ (huì)議(yì)（Sprint Planning ©¶Meeting）、每日(rì)站(zhàn)會(huì)（Daily Scrum Meeting）β‍、Sprint評審會(huì)議(yì)（Sprint Review Meeti↑₩ng）、Sprint回顧會(huì)議(yì)（Sprint R≈≠↕>etrospective Meeting）

       ✔σ↓♠;5個(gè)價值：承諾 – 願意對(duì)目标做(zuò)出承諾&π、專注– 把你(nǐ)的(de)心思和(hé)能(néng)力都(dōu)用(yònΩ₩ ™g)到(dào)你(nǐ)承諾的(de)工(gōng)作(↕≠✔πzuò)上(shàng)去(qù)、開(kāi)放(fàng)– Scrum 把項目中的(de)一"≥(yī)切開(kāi)放(fàng)給每 §∑€個(gè)人(rén)看(kàn)、尊重– 每個(gè)人(rén)都≠₹ ×(dōu)有(yǒu)他(tā)獨特的(de)背景和Ω×​(hé)經驗、勇氣– 有(yǒu)勇氣做(zuò)出承諾，履行(xíng)承諾，接受别人(r♣≥<én)的(de)尊重

3.

DevOps

3.1 DevOps 定義

      DevOps 是(¥☆✘λshì)開(kāi)發 (Dev) 和(hé)運營 (Ops) 的(de)≤‌>複合詞，是(shì)一(yī)組過程、方法與系統的(de)統稱，用(yòng)于促進開(kā₽¶i)發（應用(yòng)程序/軟件(jiàn)π★Ωα工(gōng)程）、技(jì)術(shù)運營和(h±∞®é)質量保障（QA）部門(mén)之間(jiān)的(de)溝通(tō♦♦ng)、協作(zuò)與整合。

3.2 DevOps 發展背景

      傳統的(de)軟件(jiàn)組織将開(kāi)發、IT♥π£∑運營和(hé)質量保障設為(wèi)各自(zì)分(fēn)離(lí)✔σ♠的(de)部門(mén)。在這(zhè)種環境下(xià)如(rú)何采₹↑©用(yòng)新的(de)開(kāi)發方法（例如(rú)敏捷軟件(jiàn)開(kāi®↔÷)發），這(zhè)是(shì)一(yī)個(gè)重要(™'yào)的(de)課題：按照(zhào)從(cóng)前的(de)工(gōng)作(zuò)方ε​≠式，開(kāi)發和(hé)部署不(bù)需要(yào)IT支持✘•★或者QA深入的(de)、跨部門(mén)的(de)支持，而卻需要(¥ε€yào)極其緊密的(de)多(duō)部門(mén)協作(♦✔‍zuò)。然而DevOps考慮的(de)還¶÷(hái)不(bù)止是(shì)軟件(jiàn)部署。它是(s∑✔hì)一(yī)套針對(duì)這(zhè)幾個(gè)部門(mén)間(jiān)↓δΩ溝通(tōng)與協作(zuò)問(wèn)題的(de)流程和(hé)方法[9]。 β¶

      以下(xià)幾方面₽↕ 因素可(kě)能(néng)促使一(yī)個(gè)組織引入DevO↓×ps：

      1、使用(yòng)敏捷或其他(tā)軟件(♦€•jiàn)開(kāi)發過程與方法

      $φ  2、業(yè)務負責人(rén)要(yào)求加快(kuài)産品交付的(de)速率

      3、虛拟化(huà)和(hé)雲計(λ jì)算(suàn)基礎設施（可(kě)能(néng)來(lái)自(zì)內(→€§nèi)部或外(wài)部供應商）日(rì)益普遍

      4、數(shù)≠✔₹據中心自(zì)動化(huà)技(jì)術(shù)和(hé)配置管理(lǐ)工(gōn‍λφ♠g)具的(de)普及

      5、有(yǒu)一($∏<yī)種觀點認為(wèi)，占主導地(dì)位的(de)“傳統”美(měi)國(g♥₽€uó)式管理(lǐ)風(fēng)格（“斯隆模型 γ≥±vs 豐田模型”）會(huì)導緻“煙(yān)囪式自"φ$(zì)動化(huà)”，從(cóng)而造成開(kāi)發與運營之間(jiā↕βα♣n)的(de)鴻溝，因此需要(yào)DevOps能(néng)力來(lái∞<)克服由此引發的(de)問(wèn)題。

      DevOps經常被∑ε₹☆描述為(wèi)“開(kāi)發團隊與運營團隊★λ¶之間(jiān)更具協作(zuò)性、更高(gāo±♠™Ω)效的(de)關系”。由于團隊間(jiān)協作(zuò)關系δβ&的(de)改善，整個(gè)組織的(de)效率因此得(de)到(dào)提升←β←，伴随頻(pín)繁變化(huà)而來(lái)的(de)生(shēng)産環境的(de)風©×(fēng)險也(yě)能(néng)得(de)到(dào)降低​σ↑(dī)。

      在雲計(jì)算(suàn)、大(dà)數($₽shù)據等技(jì)術(shù)颠覆性趨勢繼續在應用(yòng)經≤≠←α濟下(xià)發揮作(zuò)用(yòng)的(de)同φεα™時(shí)，DevOps也(yě)已經穩健地(dì)在¥‍業(yè)務思維方式中占有(yǒu)一(yī)↔€席之地(dì)，并将扮演主要(yào)角色。在應用(σ¥βyòng)驅動、雲連接、移動化(huà)的(de)大(dà)環境下(xià)，對(du→$♣©ì)于很(hěn)多(duō)公司來(lái)說(shuō)¥ DevOps是(shì)助力業(yè)務增值♥&戰略的(de)第一(yī)步。

      緊跟行(xíng $)業(yè)趨勢、進行(xíng)新的(de)技(jì)術(shù)變革往往會(hu®♠ì)帶來(lái)發展的(de)陣痛，DevOps也(yě)同樣要(>←₹yào)經曆這(zhè)一(yī)過程。中國(guó)及全球各地(dì)的(de)企業(yè)正在♥®認識到(dào)DevOps可(kě)以助力軟件(π♥↔×jiàn)開(kāi)發速度加快(kuài)，軟件(jiàn)應用(yòng)質量提升，更重£&☆©要(yào)的(de)是(shì)與業(yè)務目标更§¶完美(měi)地(dì)結合。

3.3 DevOps 文(wén)化(h‍≤uà)

       1) 協作ε§♣★(zuò)、可(kě)見(jiàn)性和(hé)一(yī)緻性

       健康的(de) DevOps 文(wén)¶​化(huà)的(de)一(yī)個(gè)标志(zhì)是(shì)團隊間(jiān)能(néng  <↑)夠協作(zuò)，首要(yào)的(de)便是(shì)可(kě)見(jiàn→₹‌)性。開(kāi)發和(hé) IT 運營等不(b •✘×ù)同團隊必須能(néng)夠相(xiàng)互分(fēn)享 DevOps 流程'α∏∏、優先級和(hé)關注點。這(zhè)些(xiē)團隊還(h ≥ái)必須能(néng)夠共同規劃工(gōng)作(zuò)，并統一 ₽✘ε(yī)與業(yè)務相(xiàng)關的(de)成功目标和(hé)衡量标準。

       2♠♣) 範圍和(hé)責任的(de)轉變

       當團隊統☆✘ 一(yī)時(shí)，他(tā)們擁有(yǒ★☆λu)所有(yǒu)權并參與其他(tā)生 ¶(shēng)命周期階段，而不(bù)僅僅是₹₹✘(shì)他(tā)們的(de)角色對(du©•₩₽ì)應的(de)階段。例如(rú)，開(kāi)發人(rén)員(yuán)不(bù)僅要(yào±<☆)對(duì)開(kāi)發階段的(de)創新和(hé)質量負責，還(hái)要(yào)對(d≈©∏↑uì)他(tā)們的(de)改變在運營階段帶來(lái)的(de)性能(néng)和(£ ↓$hé)穩定性負責。同時(shí)，IT 操作(zuò)員(yuán)一(yī♠••β)定要(yào)在規劃和(hé)開(kāi)發階段中考慮治理(lǐ)、安全性和(✘φhé)符合性。

       3) 縮短(duǎn)發布周期

       DevOps 團隊通(tōng)過​≥短(duǎn)周期發布軟件(jiàn)保持敏捷。因為(wèi)進度是β>(shì)漸進式的(de)，縮短(duǎn)發布周期可(kě)以讓計(jì)劃和(hé)風(σ>≥§fēng)險管理(lǐ)更容易，同時(shí)也(yě)減少(shǎo)了λ↕&(le)對(duì)系統穩定性的(de)影(yǐng)響。縮短(duǎn)發布周≤≠≠期還(hái)可(kě)以讓組織适應和(hé)應對(duì)不(bπ↔ù)斷變化(huà)的(de)客戶需求和(hé)競争壓力。

       4) 持續學習(xí)

      ★→ 高(gāo)績效的(de) DevOps 團₹ 隊形成了(le)一(yī)種成長(cháng)思維。≠←他(tā)們快(kuài)速失敗，然後将經驗教訓融入到(dào)✔✘↓他(tā)們的(de)流程中，不(bù)​≠斷改進，提高(gāo)客戶滿意度，加速創新和(hé)₹÷‌π适應市(shì)場(chǎng)。DevOps 是(shì)一(yī)個(gè)旅程，​±所以總有(yǒu)成長(cháng)的(d®♣e)空(kōng)間(jiān)。

3.4 DevOps 和(hé)應用(yòng)Ω​>∑程序生(shēng)命周期

      DevOps 影(yǐng)響應用(yòng)程序σ'生(shēng)命周期的(de)規劃、開(kāi)發、交付和(hé)運營階段。每個(gè)階∞∏ε段都(dōu)依賴于其他(tā)階段，并且這(zhè)些(xiē)階段‍φ‍并非特定于角色。在真正的(de) DevOps 文(wén)化(huà)♦≈中，每個(gè)角色在某種程度上(shàng)說(shuō)都(dōu)涉及♣↕各個(gè)階段如(rú)圖 4。

圖 4 DevOps 和(hé)應用(yòng)程序生(↓•shēng)命周期

3.5 DevOps 做(zuò)法

      除了( ☆γ♣le)形成 DevOps 文(wén)化(huà) ☆•之外(wài)，團隊還(hái)通(tōng)過在整個(gè)應用(yò↔≤σφng)程序生(shēng)命周期中實施特定做(←γ✔zuò)法，以充分(fēn)利用(yòng) DevOps。

1. 持續集成和(hé)持續交付 (CI/CD)
2. 版本控制(zhì)
3. 敏捷軟件(jiàn)開(kāi)發
4. 基礎結構即代碼
5. 配置管理(lǐ)

6. 持續監控

      其中一(yī)些(xiē)做(zuò)法有±λ(yǒu)助于加速、自(zì)動化(huà)和(hé)改進特定階段。有(yǒu)的(de)↑‍¥跨越幾個(gè)階段，幫助團隊創建提高(gā¥≥o)生(shēng)産效率的(de)無縫進程。

3.6 DevOps 工(gōng)具

      無論是(shì)縱向集‍<☆成還(hái)是(shì)橫向集成，DevOps都(dōu)需要(y≤δ¶ào)通(tōng)過工(gōng)具鏈與持續集成、交付、反饋與優化(huà)進行(xíng)端到®ε(dào)端整合。如(rú)華為(wèi)的(de)軟件(jiàn)λ×開(kāi)發雲服務, 基于二十幾年(niánαδε)的(de)研發實踐，融合DevOps理(lǐ)念方法，為(wèi)企業(yè)提供一(y✘≥ī)站(zhàn)式的(de)雲上(shàng)開(kāi)發工(g© ōng)具平台。華為(wèi)軟件(jiàn)開(k•<āi)發雲提供項目管理(lǐ)、配置管理(lǐ)、代碼檢查、編譯構建、測試、部署、發布等端§π到(dào)端地(dì)覆蓋全軟件(jiàα↔n)生(shēng)命周期的(de)相(xiàng)關服務。類似的(de)D$≤≤ΩevOps 工(gōng)具數(shù)不(bù)勝數(shù)，常見(jiàn)的(de)✘₽$DevOps 生(shēng)态圈工(gōng)具如(rú)圖 5。

圖 5 DevOps 生(shēng×♥>☆)态圈工(gōng)具

3.7 DevOps 與Agile 的(de)關聯

       DevOps 和(hé)ε•♠γ Agile 都(dōu)是(shì)用(yòng)于生(shēng)産産品、↑↓"¶進行(xíng)發布或發行(xíng)的(de)現(xiàn)代軟件(jiàn)開(kāi)發框架§♦。DevOps 是(shì)一(yī)種文(wén)化(huà)，促進軟件(jià<↑¶n)開(kāi)發和(hé)維護中所有(yǒu)角色之間(jiān)的(πλ‌de)協作(zuò)。Agile 是(shì)一(yī)種開ε•(kāi)發方法，在需求不(bù)斷變化(huà)的(de)常見(jiàn)現(xi‌ àn)實中保持工(gōng)作(zuò)'§∏ε效率和(hé)促進發布。DevOps 和(hé) A★ £§gile 并不(bù)是(shì)相(xiàng)互排斥的(de)，而是(shì)經常搭配使↔÷ 用(yòng)。

4.

持續集成

4.1 持續集成背景

      集成♥₹↑軟件(jiàn)的(de)過程不(bù)是(shì)新問(wè ×✘n)題，如(rú)果項目開(kāi)發的(de)規模比較小(xiǎo)，比如(rú)一(yī)ε"×☆個(gè)人(rén)的(de)項目，如(rú)果它對(duì)外(wài​±‍↑)部系統的(de)依賴很(hěn)小(xiǎ↑₽δo)，那(nà)麽軟件(jiàn)集成不(bù)是(shì)☆'問(wèn)題，但(dàn)是(shì)随著(zhe✘☆™©)軟件(jiàn)項目複雜(zá)度的(de)增加（即使增加一(yī)個(gè)人(£∑↔×rén)），就(jiù)會(huì)對(duì)集成和(hé‌®≥)确保軟件(jiàn)組件(jiàn)能(néng)↓★↓夠在一(yī)起工(gōng)作(zuò)提出了(le)更多(duō)的(de)要(yào)求÷≠-要(yào)早集成，常集成。早集成，頻(pín)繁的(de)集成幫助項 ↑‍★目在早期發現(xiàn)項目風(fēng)險和(hé)質量問(wèn)α☆✔§題，如(rú)果到(dào)後期才發現(xiàn)這(zhφσ✘Ωè)些(xiē)問(wèn)題，解決問(wèn)題代價很(hěn)大(dà)γ♦，很(hěn)有(yǒu)可(kě)能(néng)導緻項目延 ™期或者項目失敗。

4.2 持續集成定義

      大(d&φ×à)師(shī)Martin Fowler對(duì)持續集成是(shì)這(&γγzhè)樣定義的(de):

      持續集成是(shì)一(yī)種軟件(jià≥δ₹ n)開(kāi)發實踐，即團隊開(kāi)發成員(yuán)經βσ©δ常集成它們的(de)工(gōng)作(zuò‍γ∞)，通(tōng)常每個(gè)成員(yuán)每天至少(sh₽¶®​ǎo)集成一(yī)次，也(yě)就(jiù)意味著(zhe)每天可(kě)能★>(néng)會(huì)發生(shēng)多(duō)次集成。每次集成都(dōu​σ'¶)通(tōng)過自(zì)動化(huà)的(de)構建（包括編譯，發布​  ♥，自(zì)動化(huà)測試)來(lái) "×'驗證，從(cóng)而盡快(kuài)地(dì)發現(xiàn)集成錯(cuò)誤。許多₹•★&(duō)團隊發現(xiàn)這(zhè)個(gè)過程可(kě)以大(dà$§↓↔)大(dà)減少(shǎo)集成的(de)問(wèn)題，讓團隊能(néng)夠更快(kuà÷ αi)的(de)開(kāi)發內(nèi)聚的(de)&&←軟件(jiàn)。

4.3 持續集成的(de)價值

• 減少(shǎo)風(fēng)險

        一(yī)天中₽φ進行(xíng)多(duō)次的(de)集成，并做(zuò)了(le)相("π∏‌xiàng)應的(de)測試，這(zhè)樣有(yǒu)利于檢查缺陷，了(le)解軟件(jiàn)≈λ 的(de)健康狀況，減少(shǎo)假定。

• 減少(shǎo)重複過程

       減少(shǎo)重複的(de)過程可 ∏€(kě)以節省時(shí)間(jiān)、費(fèi)用(yòng)和(hé✔™<)工(gōng)作(zuò)量。說(shuō)起來(lái)簡單，做(zuò" ₩)起來(lái)難。這(zhè)些(xiē)浪費(fèi)時(shí)間(jiān)的₹β(de)重複勞動可(kě)能(néng)在我們的(dβ ←Ωe)項目活動的(de)任何一(yī)個(gè)環節發生(≠≥ shēng)，包括代碼編譯、數(shù)據庫集成、測試、審查、部πε署及反饋。通(tōng)過自(zì)動化(huà)的(de)持續集成可(kě)以将這₽₽(zhè)些(xiē)重複的(de)動作(zuò)都★♣÷✘(dōu)變成自(zì)動化(huà)的(de)，無需太多(duō≤©∏)人(rén)工(gōng)幹預，讓人(rén)們的(de)時(shí)間(jiān)更多(₽≥duō)的(de)投入到(dào)動腦(nǎo)筋的(de)、更高(gāo)價值的(de)事(sh™ ì)情上(shàng)。

• 任何時(shí)間(jiān)、任何地(dì)點生(shēng)成可(kě)部署的(‍<de)軟件(jiàn)

       持續集成可(kě)以讓您在任何時(shí₽↑‌)間(jiān)發布可(kě)以部署的(de)軟件(jiàn)。從£δ(cóng)外(wài)界來(lái)看(kàn)‌<，這(zhè)是(shì)持續集成最明(míng)顯的¶≈(de)好(hǎo)處，我們可(kě)以對(duì)改進軟件(jiàn)品質和(hé)★↓減少(shǎo)風(fēng)險說(shuō)起來(lái)滔滔不(bù)絕，但(dàn)對↔π(duì)于客戶來(lái)說(shuō)，可(kě)以部署的(de)☆σ↕軟件(jiàn)産品是(shì)最實際的(de)資✔→≥産。利用(yòng)持續集成，您可(kě)以經常對(duβ ì)源代碼進行(xíng)一(yī)些(xiē)小(xiǎo)改動，并将這(≈∏zhè)些(xiē)改動和(hé)其他(tā)的(de↕ ✔)代碼進行(xíng)集成。如(rú)果出現(xiàn)問(wèn)題，項目成員(yuán ​<)馬上(shàng)就(jiù)會(huì)被"→δφ通(tōng)知(zhī)到(dào)，問(wèn)題會(huì)第一(yī)時(sh₹∞"♦í)間(jiān)被修複。不(bù)采用(yòng)持續集成的(de)情況下₽β"(xià)，這(zhè)些(xiē)問(wèn)≥→→§題有(yǒu)可(kě)能(néng)到(dào)交付前§™‌δ的(de)集成測試的(de)時(shí)候×★£才發現(xiàn)，有(yǒu)可(kě)能(néng)會(huì)導緻延遲發布産品≠↔​✘，而在急于修複這(zhè)些(xiē)缺陷的(de)時(shí)候★♣≤ 又(yòu)有(yǒu)可(kě)能(néng)引入新的(de)缺陷，最終可(kě)能(néσ¶ng)導緻項目失敗。

• 增強項目的(de)可(kě)見(jiàn)性

       持續集成讓我們₽≠≥δ能(néng)夠注意到(dào)趨勢并進行(xíng)有(yǒu)效的(de)決策。如(rβ≠'ú)果沒有(yǒu)真實或最新的(de)數(shù)據提供→©支持，項目就(jiù)會(huì)遇到(dào)麻煩，≠ ₩每個(gè)人(rén)都(dōu)會(huì)提出他(tā)最好(hǎo)的(de)猜測。'πβ 通(tōng)常，項目成員(yuán)通(tōng)過手工(gōng)收集這(zhè)​Ω÷些(xiē)信息，增加了(le)負擔，也(yě)很(hěn)耗時(shí)®♥。持續集成可(kě)以帶來(lái)兩點積極效果：‍₩βπ

       (1)有(yǒu)效決策♦γ：持續集成系統為(wèi)項目構建狀态和(hé)品質指标提供了(le)及時✘¶↑←(shí)的(de)信息，有(yǒu)些(xiē)持續集成系₩₽∏↓統可(kě)以報(bào)告功能(néng)完成度和(hé)缺陷率。

       (2)注意到(dào)趨勢：由于♥¥¥經常集成，我們可(kě)以看(kàn)到(dào)一(yī)些(xiē)趨勢，如(rú)構÷"建成功或失敗、總體(tǐ)品質以及其它的(★‌₩de)項目信息。

       建立團隊對(du α'ì)開(kāi)發産品的(de)信心

      &n✘¥→bsp;持續集成可(kě)以建立開(kāi)發團隊對(↕φduì)開(kāi)發産品的(de)信心，因為(wèi)他(tā)們清楚的(de≥¥≈)知(zhī)道(dào)每一(yī)次構÷$€♦建的(de)結果，他(tā)們知(zhī)道(dào)他δ ​(tā)們對(duì)軟件(jiàn)的(de)改動造成了(​₹le)哪些(xiē)影(yǐng)響，結果怎麽樣。

4.4 持續集成的(de)要(yào)點

1. 統一(yī)的(de)代碼庫
2. 自(zì)動構建
3. 自(zì)動測試
4. 每個(gè)人(rén)每天都(dōu)要(yào)向代碼庫主幹提交代碼
5. 每次代碼遞交後都(dōu)會(huì)在持續β∏✔λ集成服務器(qì)上(shàng)觸發一(yī)次構 £♣建

6. 保證快(kuài)速構建

7. 模拟生(shēng)産環境的(de)自(zì)動測試

8. 每個(gè)人(rén)都(dōu)可(kě)₹©λ←以很(hěn)容易的(de)獲取最新可(kě)執行(xíng)的(de)應用(©‍"yòng)程序

9. 每個(gè)人(rén)都(dōu)清楚正在發生(shēn≈≤g)的(de)狀況

10. 自(zì)動化(huà)的(de)部署

4.5 持續集成的(de)原則

1. 所有(yǒu)的(de)開(kāi)發人(r≠←γén)員(yuán)需要(yào)在本地(dì‌₹♦)機(jī)器(qì)上(shàng)做(zuò)本地(dì)構建，然後再提交到(dào)版‌ ∏本控制(zhì)庫中，從(cóng)而确保他(tā)們的(de)變更不(bù)會(≈≠huì)導緻持續集成失敗。

2. 開(kāi)發人(rén)員(yuán)每±✘天至少(shǎo)向版本控制(zhì)庫中提交一(yī)次代碼。&÷ 

3. 開(kāi)發人(rén)員(yuán)每天至少(shǎo)需要(yào)從(cóng)版₽¶"♠本控制(zhì)庫中更新一(yī)次代碼到(dà‌↓♥o)本地(dì)機(jī)器(qì)。

4. 需要(yào)有(yǒu)專門(mén)的(de)集成服↓ 務器(qì)來(lái)執行(xíng)集成構建,每天要(yào)執行(xíng)多(duō↑γ$ )次構建。

5. 每次構建都(dōu)要(yào)100%通(tōng)過。

6. 每次構建都(dōu)可(kě)以生(shēε ∏•ng)成可(kě)發布的(de)産品。

7. 修複失敗的(de)構建是(shì)優先級最高(®≥gāo)的(de)事(shì)情。

8. 測試是(shì)未來(lái)，未來(lái)是(shì)測試。

4.6 持續集成的(de)工(gōng)作(zuò)流‌±程

     ≈×ε' 持續集成（Continuous integration，簡稱CI）是(shì)軟件(≥ε£γjiàn)的(de)開(kāi)發和(hé)發布标準流程中最重要(yào)的(de)部分(fα♠®ēn)。作(zuò)為(wèi)一(yī)種開(kāi)☆>發實踐，在CI中可(kě)以通(tōng)過自✔‌•(zì)動化(huà)等手段高(gāo)頻(pín)率地(dì)去(qù)獲取産品γ↔≤反饋并響應反饋的(de)過程。簡單來(lái)說(shuō)  ，就(jiù)是(shì)持續不(bù)斷地(dì←<α±)（一(yī)天多(duō)次）将代碼合并（集成）到(dào)主幹源碼倉庫，讓産品可(kě)以×δ‍快(kuài)速叠代，同時(shí)保持高(gāo)∞≥™♥質量。

      持續集成強調對(duì)于開✘₩(kāi)發人(rén)員(yuán)的(de)每個(gè)提交，立刻進行(∏¥xíng)構建、掃描、（單元）測試。根據結果，我們可(kě)以✔ &×确定新代碼和(hé)原有(yǒu)代碼能(néng)否正确地(dì)集成在一≥♣≤(yī)起。如(rú)一(yī)個(gè)完整的(de≠§÷)CI系統應該包含3個(gè)基本模塊：

      一(♣Ωyī)個(gè)可(kě)以自(zì)動構建的(de)過程，自(zì)動編譯代碼，可(kě≥∞)以自(zì)動分(fēn)發，部署和(hé)測試。 $ε¥

      一(yī)個(gè)代碼£>♣倉庫，例如(rú)Git。

      一(yī)σ←₽<個(gè)持續集成的(de)服務器(qì)。

      如(rú)圖 3是(shì)典型的↔<★₽(de)持續集成流程圖。

圖3持續集成流程圖

      正如(rú)圖3持續集成流程所示，∞γ€通(tōng)用(yòng)的(de)持續集成（CI）流程主要(yào)包括：

1. 簽出代碼：

     從(cóng)源碼管理(lǐ)系統裡(l¶δ→ǐ)簽出或者克隆最新的(de)代碼到(dੱ•αo)本地(dì)開(kāi)發環境

1. 提交（commit）：

      基于主幹×π↑分(fēn)支創建一(yī)個(gè)新的(de)功能(néng)分(fēn)支，并在此分(f∞δ$✘ēn)支編寫代碼，并向倉庫提交代碼

1. 測試（第1輪）：
   Ω≠ ± 代碼倉庫對(duì)commit操§• ‍作(zuò)配置了(le)鈎子(zǐ)（hook）， 每一(yī)次提交代碼都(dōu)會(hu✘∑∏ì)觸發測試。 →™♠​
   ₩Ω 單元測試（針對(duì)函數(shù)或模®​₹λ塊的(de)測試）和(hé)功能(néng)測試（集成測試）将會(huì)被執行(x ♣íng)、根據需要(yào)設置是(shì)否執行(xíng)端對(duì)端測試。 ‍±  ≥
   ♥¶←• 一(yī)般來(lái)說(shuō)，這(zhè)₹∞πγ些(xiē)測試也(yě)會(huì)被打包到↓β(dào)代碼裡(lǐ)。 ♦✘ ✘€↑γ

2. 構建（build）：
   'Ω ₩ 通(tōng)過測試（第1 ε≤©輪）後，将源碼轉換為(wèi)可(kě)以運行(xíng)的(de)實際代碼，£÷比如(rú)安裝依賴，配置各種資源等。 Ω 

&δ÷÷       源代碼一 ©₽±(yī)般是(shì)自(zì)包含構建的(de)，即CI流程所需的(de)構建腳本是(shì✘ γ)放(fàng)在源碼倉庫裡(lǐ)的(de)。 ♣↔

1. 測試（第2輪）：
   ← ↔¥ 以自(zì)動化(h✔♦uà)為(wèi)主的(de)全面測試，包括單元測試和(hé)集成測§ Ω 試，必要(yào)時(shí)做(zuò)端對(duì)端測試‌₹×，确保新版本的(de)每一(yī)個(gè)更新點γ©♣都(dōu)必須測試到(dào)。 "×≈ Ω∏☆Ω

2. 合并：
   >∞±± 通(tōng)過測試（第2輪）後，将代碼更新集成到(dà♣✔β↕o)主幹。  ₩ 

3. 回滾：
   π←♦± 如(rú)果當前版ε‌本發生(shēng)問(wèn)題，就(jiù)回滾到(dào)上(shàng₹§βγ)一(yī)個(gè)版本的(de)構建結果 ↑ ‌ ∏ε
   ☆β 一(yī)般來(lái)說(shuō)，CI服務器(γ♥'qì)會(huì)配置成在遇到(dào)故障時(₹"®♠shí)發送郵件(jiàn)相(xiàng)關人(ré×$♠€n)員(yuán)，可(kě)以快(kuài)速知(zhī)曉故障并且→λ♦盡快(kuài)采取更正措施。 ∏ε≠ 

4.7 持續集成注意事(shì)項

       當需要(yào)代碼變更‍>φ并集成時(shí)，開(kāi)發者會(huì)從(cón₩'g)基礎代碼庫複制(zhì)以進行(xíng)作(zuò)業(yè)，其<£≤‍他(tā)開(kāi)發者提交代碼的(deε​φ)變更至來(lái)源代碼庫，并透過副本≠‌的(de)方式取代來(lái)源代碼庫的(de)代碼。不(bù)隻變更目前的(de)代碼庫，新γε₩的(de)代碼也(yě)可(kě)以新增成為(wèi)程序≥∞₩×庫、其它共享資源與潛在沖突。

       當分(fēn)支代碼開(kāi)發者進行(→&ε☆xíng)主線重新集成時(shí)，當分(fēn)支代碼保持在取出↑δ狀态時(shí)間(jiān)越長(cháng)，就(jiù)愈容易遭遇集成↕≥多(duō)重沖突的(de)風(fēng)險以及集成失敗。因♣♦↑±為(wèi)他(tā)們拿(ná)到(dào)的(de)是(shì)副本，所以當開(kāi)™₹∑₽發者将代碼提交到(dào)代碼庫時(sh✔×≠♣í)，首先必須更新代碼以反映他(tā)們在代©≤¶ 碼庫中的(de)更改。代碼庫包含的(de)λ₹更改越多(duō)，開(kāi)發人(rén)員(yuán)在提交自(zì)己φ↓的(de)更改前必須運行(xíng)的(de♣♥∏∞)基礎工(gōng)作(zuò)就(jiù)越多(duō)。

     ♦λ × 最終，該程序庫也(yě)許變成非常不(bù)同于開(kāi↕  ‍)發者的(de)目标代碼，他(tā)們進入有(yǒu)時(shí)候被稱為(wè♦±i)合并地(dì)獄或集成地(dì)獄的(de)階段，這(zhè)時(shí)候開(kāiα♠∞)發者所花(huā)費(fèi)的(de)集成時(shí)間(jiān)，将超$♣∞過最初代碼開(kāi)發的(de)時(shí)間(jiān)。

      持續集成涉及預先σ★集成與預先與經常性的(de)集成，借此來(lái)避免掉入集成地(dì)獄的(de)陷阱， "&©實踐的(de)目标是(shì)減少(shǎo)重工(gōng)、減少(shǎo)成πᶩ本與時(shí)間(jiān)。

      持續集成補充的(de)實¶↑©±踐是(shì)在提交代碼之前，每個(gè)開(✘→ kāi)發人(rén)員(yuán)必須運行(xíng)一(y↔φī)個(gè)完整的(de)構建并通(tōng)過所有(yǒu)的(de)單元測<λ✔試、集成測試。當持續集成服務器(qì)偵測到(dào)代碼€÷♣有(yǒu)新的(de)提交時(shí)，必須經常性與自(zì)動化(huà)的(de)進行(xí™→★ng)此類單元測試或集成測試任務。代碼每次集成到(d∞£Ωào)主幹之前，必須通(tōng)過自(z​ αì)動化(huà)測試，以便快(kuài)速發現(xiàn)和(hé)定位錯(cu♥€♥ò)誤。值得(de)注意的(de)是(shì)，持續集成并不(bù)能(néng±✘ ​)消除錯(cuò)誤，而是(shì)讓它們非常容易發現(xiàn)和(hé)改正 σ™。

轉載汽車(chē)電(diàn)子(zǐ)相(xiàng)關文(wén)章(zh®©♥λāng)

轉自(zì)汽車(chē)電(diàn)子(zǐ)與軟件(jiσσσλàn)