作(zuò)者：極氪軟件(jiàn)及電(diàn)子(zǐ)中心 Filip

       經過十多(Ω♦φduō)年(nián)的(de)發展，敏捷軟件(jiàn)開(kāi)發已經從(cóng)一&↔ (yī)種前衛的(de)開(kāi)發方式轉變成γ¶為(wèi)在各大(dà)軟件(jiàn)公司中被廣泛應用(y≥≠òng)的(de)主流技(jì)術(shù✘↕♦)，變成了(le)互聯網行(xíng)業(₽πyè)的(de)一(yī)種潮流，而随著(zhe)軟件(j£¥iàn)定義汽車(chē)等概念的(de)興起，軟件(jiàn)在一(yī)輛(liàngβ≤±)汽車(chē)中的(de)價值正在不(bù)斷增加。電(diàn)動化(hu€≥à)、網聯化(huà)、智能(néng)化(huà)、共享化(♦φhuà)的(de)背後都(dōu)需要(yào)♦€強大(dà)的(de)軟件(jiàn)能(néng)力作(zuòεπ)為(wèi)支撐，而軟件(jiàn)能(néng)力不(bù)僅體(tǐ)現(xi♠γàn)在構建出高(gāo)質量的(de)軟件(jiàn)産品上(shà☆±'‍ng)，同時(shí)還(hái)體(tǐ)現(xiàn)在軟件(jiàn)産品的(de)快(k✘‍uài)速叠代以滿足快(kuài)速變化(huà)的(de)市(shì)場(ch↑♠ǎng)需求的(de)能(néng)力之上(shàng)。這(zh§≥>è)樣的(de)變化(huà)無疑給汽車(chē)軟件(jiàn)開(kāi¶✔♥±)發帶來(lái)了(le)新的(de)挑戰，同時(shí)也(yěσ←∞©)帶來(lái)了(le)巨大(dà)的(de)機(jī)遇λ☆φ ，新玩(wán)家(jiā)紛紛入場(chǎng)，期望在軟件(jiàn)和(hé)用(yò®$↕ng)戶體(tǐ)驗上(shàng)赢得(de)市(shì)場(chǎng)，而傳統的(de)汽₽♥α≠車(chē)制(zhì)造商則正重新審視(shì)組織架構、人(rén)才、流程、職責↓  等方方面面以期适應新的(de)變化(huà)，成為(wèi¥♠)軟件(jiàn)驅動的(de)公司。

     ₹™α  持續集成/持續發布（Continuous Integration andC<→™ ontinuous Delivery）是(shì)敏捷軟件(jiàn)開(kāi)發中的(de)核心過程，本文(wén)将從(cón& g)持續集成/持續發布角度探討(tǎo)汽車(chē)軟件(jiàn)開(kāi₽< ★)發過程中的(de)代碼管理(lǐ)和(hé)發布流程。

傳統汽車(chē)軟件(jiàn)的(de)開(δ∏★kāi)發流程

       傳統汽車(chē)軟件(jiàn)開(β ♥←kāi)發大(dà)量依賴于供應商，汽車(chē)制(zhì)造商提出需求，由供βΩ應商負責軟件(jiàn)編寫和(hé)實現(xiàn)。在過去(q‍₩ù)十幾年(nián)的(de)時(shí)間(<>jiān)裡(lǐ)，汽車(chē)電(dià₹∞σ♣n)子(zǐ)器(qì)件(jiàn)的(de±$¶)數(shù)量增長(cháng)迅速，車(chē)內(nèi)電(diàn)子(zǐ×β)控制(zhì)單元（ECU）從(cóng)十幾個(gè)增長(cháng)到(d®<ào)了(le)上(shàng)百個(gè)，帶來(lái)的(de)是(s≠βhì)軟件(jiàn)複雜(zá)度的(de)快(kuài)速增加。除了(le)汽車(chē)Ω★≈γ功能(néng)繁多(duō)所帶來(lái)的(de)軟件(jiàn)複雜(zá)度，汽車(β÷♥chē)電(diàn)子(zǐ)類産品在軟硬上(shàng)往往對(duì)設備的(de)高(&ε©gāo)可(kě)靠性、穩定性有(yǒu)著(zhe)嚴格的(de₹☆)要(yào)求，這(zhè)些(xiē)要(yào)求在消費(fèi)電(diàn)子(zǐ)&±×>類，甚至是(shì)醫(yī)療電(diàn)子(zǐ)類和(hé)工(gōng)業(yè)★&控制(zhì)類産品上(shàng)是(shì)沒有(yǒu)的(de✘σ★)。因此，為(wèi)了(le)滿足功能←♠(néng)安全等要(yào)求，汽車(chē)的(de)軟硬件(jiࣣn)往往需要(yào)做(zuò)額外(wài)設計(jì)。面對(duì)這(zhè)樣的(de☆& ×)複雜(zá)系統，汽車(chē)行(x÷♠∑íng)業(yè)制(zhì)定了(le)許多(duō)标準及方法論以規範開(kāi)♠±發過程，而在軟件(jiàn)開(kāi)發過程中，最有(yǒu)名的φΩ≤(de)是(shì)ASPICE（Automotive Software ®εφProcess Improvement and CapabilitydEterminatiπ↓on）。

      ≤<↔← Automotive SPICE簡稱ASPICE，是(shì)ISO/IEC 15504（SPICE）國(guó)際标準在車(chē)用(yò™÷β₩ng)領域下(xià)的(de)修改版本。其目的(de)是(shì)為(wèi)了(le)<₹★評估汽車(chē)産業(yè)中，電(diàn)子(zǐ)控制(zh↕•ì)器(qì)供應商開(kāi)發的(de)流程。

       ☆ ASPICE 建立在 V 模型之上(shàng)，它需要(yào)與每個(gè)​☆α開(kāi)發階段相(xiàng)對(duì)應的(de)測試階段。 這(zhè)是(shì)一(yī)個(gè)嚴格的(de)模型<γδ©，需要(yào)嚴格的(de)評估以确保持續的(de)γ&‌←評估和(hé)發展。下(xià)圖是(shì)ASPICE中定義的(de)典型開(kāi)發流程：

From: https://www.automotivespice.com

       V 模型的(de)左側包括需求分(fēn)析、系統設計(jì)、架構設計(jì)、模塊設計(§'¶<jì)、編碼；

      &nb₩©sp;V 模型的(de)右側包括單元測試、集成測試、系統測試、驗收測試。

        從(cóng)上(shàn¶♥≠>g)面可(kě)以看(kàn)出，V模型是(shì)一(yī)種類似于瀑布式的×£★←(de)開(kāi)發模型，開(kāi)發模型是(shì)≤™•‌線性的(de)，制(zhì)造商隻有(yǒu)等到(dào)整個(gè)過程的(∑♠∑de)末期才能(néng)見(jiàn)到(dào)開(kāi)發成果。盡管在實際過©≈¥程中，可(kě)以進一(yī)步分(fēn)解成更小(xiǎo)的(de)任務進行(xíng)₹≥φ驗證，但(dàn)階段的(de)劃分(fēn)依然比較固定，階段之間(jiān)會(huì)要(ε$≠yào)求大(dà)量的(de)文(wén)檔。

敏捷開(kāi)發的(de)理(lǐ)念

        傳統裝載在汽車(chē)上(shàng→π)的(de)軟件(jiàn)往往一(yī)旦賣σ$✔♥出，就(jiù)不(bù)會(huì)再變更，升級需要(yào)去(q$$₩ ù)線下(xià)4S店(diàn)完成。在這(zhè)樣的(de)情況下(xià)，基于♦α♦V模型進行(xíng)軟件(jiàn)開(kāi)發有(yǒu)利于需求和(hé)過程管理(lǐ)，ε₹£明(míng)确範圍和(hé)進度。不(bù)過，這(zhè)樣的(de)情況正在發↕∑£≈生(shēng)變化(huà)，一(yī)方面，消費(fèδ↑i)者對(duì)新技(jì)術(shù)越來(lái)越感興趣，特别是(s ÷hì)與用(yòng)戶有(yǒu)直接交互的(de)信息娛樂(yuè)系統或者是(shì)智能× (néng)駕駛功能(néng)，用(yòng)戶希望功能(néng)¥¥∑不(bù)斷地(dì)完善，獲取新的(de)技(jì)術(shù)不(bù)用(yòng)換一(y€ ī)台新車(chē)；另一(yī)方面，随著(zhe)π㶱車(chē)內(nèi)固件(jiàn)升級（FOTA）和(hé)應用(yòng)軟件(jiàn)升級£♣σ'（SOTA）技(jì)術(shù)的(de)成熟，汽車(‌λ >chē)制(zhì)造商已經有(yǒu)可(kě)能(néng)在遠(yuǎn)程完¶​φ成軟件(jiàn)的(de)更新。軟件( ↕₩jiàn)和(hé)硬件(jiàn)的('≥de)開(kāi)發過程正在逐步解耦，軟件(jiàn)需要(yào)實現(xiàn)小(xiǎo±φ £)步快(kuài)跑，不(bù)斷叠代。這(zhè)個(gè)時(shí)候，汽車(c© hē)軟件(jiàn)的(de)新老(lǎo)從(cóng)業(yè)者們開(k×α×āi)始思考如(rú)何改變，是(shì)否≥♦ <能(néng)在汽車(chē)行(xíng)業(yè)中★←☆應用(yòng)敏捷開(kāi)發的(de)理(lǐ)念或者是(shì)将敏捷開(™♣♠∞kāi)發與傳統的(de)開(kāi)發模型進行(xíng)結合。目标是(shì)獲得(de)效率α ÷和(hé)質量的(de)平衡。

       與傳統計(jì)劃​≠±☆驅動的(de)開(kāi)發相(xiàng)比，敏捷開(kāi)發有(yǒ∑αλu)兩個(gè)核心理(lǐ)念：

       1. 自(zì)适應的(de)而不(bù)是(shì)預測的(≤↔¥≥de)；

       2.✔§§ 以人(rén)為(wèi)本而不(bù)是(sh©& ì)流程為(wèi)導向的(de)

        計(jì™♠)劃驅動的(de)工(gōng)程期望在開(kāi)發之前提出一(yī)↑€ ¥個(gè)預測計(jì)劃。該計(jì)≥₽劃列出了(le)整個(gè)項目的(de)人(rén)員(yuán™φ)、資源和(hé)進度。軟件(jiàn)☆   設計(jì)也(yě)是(shì)預先完成的(de)，預計(j‍→±ì)實現(xiàn)與此設計(jì)一(yī)緻。成功的(de)衡量标準是(shì)發展遵循α∞♥這(zhè)個(gè)計(jì)劃的(de)程¶☆♥度。

敏捷計(jì)劃是(shì)用(yòng)來(lái)幫助控制(zhì)變更的(♦♥de)基線。敏捷團隊的(de)計(jì)劃與傳統團隊一(yī)樣仔細，但(dà←βΩΩn)計(jì)劃會(huì)不(bù)斷修改以反映在項目中學♥₹到(dào)的(de)東(dōng)西(xī)。成功取決于軟件(jiàn)提供的λ✘(de)價值。

      &nbs<✘¥p; 計(jì)劃驅動的(de)工(gōng)程尋求一(yī)種結構以将個(gè)體(tǐ)∏∞差異減少(shǎo)到(dào)微(wēi)不(bù)足道® ✔ (dào)的(de)程度。這(zhè)樣的(de)  ∏↓工(gōng)業(yè)流程更具可(kě)預測性，在人(rén)員(yuán)轉移時δ∏∞(shí)能(néng)夠更好(hǎo)地(dì)應•‍★↕對(duì)，并且更容易定義技(jì)能(néng)。ε‍↔

        敏©€¶捷工(gōng)程将軟件(jiàn)開(k✔γ§āi)發視(shì)為(wèi)人(rén)類活動，其中涉及的 ♥&∑(de)人(rén)員(yuán)以及他(tā)們如(rú×♦‍$)何作(zuò)為(wèi)一(yī)個(gè)團隊是(shì)成功背後的(de)主要(←₽‍yào)驅動力。

持續集成

       在敏捷開(kāi)發的(de)理(l©★≤₽ǐ)念（原則）之下(xià)的(de)有(yǒu)力實踐是(shì)持續​≠集成和(hé)持續交付（CI/CD）的(de)軟件(jiàn)産品（有(yǒu)的(de)制(zhì)造商也(yě)同樣在探索₩σ☆♥硬件(jiàn)産品敏捷開(kāi)發的(de)可(kě)™♣≠€能(néng)性）。持續集成和(hé)持續交付的(de)&φ±重要(yào)特點是(shì)自(zì)動化(huà)、不(bù)斷構建，下(xiε&∏✘à)圖是(shì)敏捷開(kāi)發的(de)主要(yào✔↕)過程：

（From：https://faun.pub/most-popular-ciΩ₹÷₽-cd-pipelines-and-tools-ccfdce429867）

        持續集成和≤•✘¥(hé)持續交付需要(yào)快(kuài)速完成計(jì)劃、編碼、測試、發布的(®₽βde)循環，持續集成和(hé)持續交付并不(bù)是(shì)畫(huà)成“圓”的(de)V模型，自(zì)動化(huà)的(de)測試和(hé)自(zì)動化(huà)的(de)發布是(≥>shì)不(bù)可(kě)或缺的(de)組成部分(fē×↕☆>n)。而這(zhè)一(yī)過程應用(yòng)于每一(yī)次提交，意&≥±味著(zhe)每一(yī)次代碼的(de)提交、合并都(dōu)會(huì€λ)經過自(zì)動化(huà)的(de)測試，成為(wèi)一(yī&♦≥)個(gè)新的(de)發布版本。為(wèi)了(le™ββ)效率的(de)考量，可(kě)在提交合并和(hé)版本發布時(shíσβ'≤)，進行(xíng)不(bù)同程度的(de)測試。重要(y→§ào)的(de)是(shì)持續獲得(de)版本，為≠♥(wèi)進一(yī)步驗證和(hé)最終交付給用(yò ®ng)戶提供有(yǒu)力支持。

        ÷₩為(wèi)了(le)完成這(zhè)樣快(ku★♠'ài)速的(de)發布，CI/CD本身(shēn)也(yě)成為(wèi)了(le)一(yī)個(gè)複雜(zá)β♣₽的(de)軟件(jiàn)産品，需要(yào)專業(yè)的α☆<©(de)軟件(jiàn)團隊進行(xíng)維護，編寫大•∑±(dà)量代碼以實現(xiàn)各個(gè)任務的(de)調度，集成多(duō)個(gè)工(↕€gōng)具鏈以提高(gāo)整個(gè) ±→過程的(de)效率。而這(zhè)也(yě↕©)是(shì)汽車(chē)制(zhì)造商實現(​$σxiàn)敏捷軟件(jiàn)開(kāi)發轉型的(de)一(yī¥≤∞)個(gè)挑戰。在過渡期間(jiān)，往往會(huì)因為(wèi)工(gōng)具鏈的(d≈ ✔e)不(bù)成熟而影(yǐng)響産品的(de)< ∑ 開(kāi)發效率，甚至于忽略必要(yào)的(de)自(zì)動化(huà)測試和(hé)反饋，₹↓δ​使産品的(de)質量出現(xiàn)問(wèn)題。

代碼分(fēn)支模型

       持續集&"←成和(hé)持續交付的(de)落地(dì)過程中，需要(yào)考量不(bù)少(sφ♣→hǎo)因素，包括但(dàn)不(bù)限于工(gōng)具鏈的(de)選擇、流程的©₩≠γ(de)制(zhì)定、服務器(qì)的(de)搭建等等，而代碼分(fēn)支模型的(de)​₹ 選擇是(shì)持續集成團隊和(hé)軟件(jiàn)開(kāi)發團隊需要(yào)©®在早期進行(xíng)定義并共同遵守的(de)一(yī)項規範，下(xià)面将對(duì)↓✔持續集成過程中代碼分(fēn)支模型的(de)選擇進行(xíng)探討(tǎo••)。

      &nbs♠₩p;分(fēn)支模型是(shì)軟件(jiàn)開(kāi)發團隊通(tōng)過Git 等版本控制(zhì)系統編寫、合并和(hé)交付代碼時(sh₩≠∏®í)采用(yòng)的(de)策略。好(hǎo)的(de)分(fēn)支模型增強了(le)軟件(jiε ♦àn)交付過程中的(de)協作(zuò)∑£、效率和(hé)準确性。 它定義了(le)團隊如(rú)何使用(yòng)分(fēn)支來(lái)實現(xλ♥‌iàn)并發開(kāi)發。

良好(hǎo)的(de)分(fēn)支模型往往可(kě)以達到(dào)> $λ以下(xià)目标：

      1. 對(duì)持續集成的(de)良好(hǎo)支持。

      2. 确保高(gāo)頻(pín)率的(de)集成。關于高(gāo)頻(pín)率≥λ←集成的(de)優勢，大(dà)家(jiā)可(kě)✘✔以閱讀(dú)Integration Frequency進一(yī)步了(le)解。

      3. 減少(shǎo)合并沖突和(hé)處理(•★↑lǐ)沖突的(de)成本（在開(kāi)發過程中，處理(lǐ)φ☆ε大(dà)量合并沖突是(shì)開(kāi)®Ω​發人(rén)員(yuán)非常頭痛的(de)問(wèn)題，并且很(h"•ěn)容易發生(shēng)錯(cuò)誤）。

      比較常見(jiàn)的(de)分(fēn)₽☆支模型有(yǒu)：Git-flow、GitHub Flow、GitLab Flow和(hé)Trunk-based developme≤ε"nt。

      在持續集成中，使€ε↕用(yòng)Trunk-baseddevelopment是(shì)一(yī)個(gè)常見(jiàn)的(d£↑e)選擇，下(xià)面簡單介紹一(yī)下(xià)各個(©σ♠<gè)分(fēn)支模型的(de)特點。

Trunk-based developm♣'ent

      &nbs∞§p;Trunk-based develop∏' "ment (TBD) 是(shì)基于主幹開(kāi)發是(shì)一(yī)種分(fēn)支模型，所有♦→(yǒu)開(kāi)發人(rén)員(yuán)每天都(dōu)将他(tā)們↕±的(de)更改直接集成到(dào)共享主幹（trunk或master）中。 理(lǐ)想情況下(xià)，主幹始終處于可(kě)發布狀态。

下(xià)圖說(shuō)明(míng)了(le) TBD 的(de)基本流程：

（From:https://trunkbaseddevelopment.com/#scal→§ed-trunk-based-development）

      基于主幹開(kāi)發的(d‍₽‍e)典型策略如(rú)下(xià)：

     1. 開(kāi)發基于主幹，沒有(yǒu)長(cháng)期存在的(de)功能(©¥néng)分(fēn)支（feature branch）。 如(rú)果需要(yào)功能(néng)分(fēn)支，它應該¶∏σ>是(shì)本地(dì)的(de)或短(du•φǎn)期的(de)，并在幾天內(nèi)合并到(dào)主✔•₹幹；

     2¶★®. 主幹應保持健康且可(kě)發布的(de)狀态；

     3. 發布分(fēn)支（release branch）從(cóng)主幹中“即時(shí)”檢出（checkout）（例如(rú)發布前 2 周）并在發布之前凍結（例如(rú)發布前 1 周）；

     4. 修複應該首先上(shàng)傳到(dào)主幹，然後cherry-pick到(dào)發布分(fēn)支（這(zhè)有(yǒu)助于确保主←‍≠幹中包含所有(yǒu)修複并避免回退）。

      TBD非常适合持續集成，持續集成的(de)流程可(kěγ≤)以在主幹上(shàng)運行(xíng)，對(duì)每次提交♥↓>≠進行(xíng)驗證，在代碼成功合并後進一(yī)步生(shēng)成交付物(✔‌₽wù)。發布分(fēn)支是(shì)為(wèi)了(le)更好(hǎo)>β↕的(de)管控産品的(de)質量，因為(wèi)實際過程中，盡管主幹®↑ €經過驗證，但(dàn)缺少(shǎo)凍結過程，新的(de)提交容易造成意想不(bù)到(λ₹₽dào)的(de)問(wèn)題，發布分(fēn)支的(de)存在有(yǒu)效地✘±α(dì)控制(zhì)了(le)這(zhè→™≤)一(yī)影(yǐng)響。在發布分(fēn)支檢出後，同樣可(kě)以與主幹一(yεεī)起進行(xíng)持續集成和(hé)交付。

使用(yòng)TBD的(de)主要(yào)挑戰是(shì)' 當有(yǒu)體(tǐ)量較大(dà)的(de)新特性需要(yào)開(kāi)發時​‍♠(shí)，高(gāo)頻(pín)的(de)'φ集成會(huì)比較難做(zuò)到(dào)，開(kāi↔'♠")發人(rén)員(yuán)需要(yào)額外(wài)的(de)工(gōng)作(zuò)（如α≥'₽(rú)使用(yòng)标志(zhì)位等方式），避免不(bù)完整的(d↕↓e)功能(néng)在産品中運行(xíng)。

Git Flow

      Git Flow模型背後的(de)主要(yào)思想是(shì)将工(gō→β$¶ng)作(zuò)隔離(lí)到(dào)不(bù)同類型的(de)分(fēn)支（main, develop, feature, §ε♠release, hotfix）。 主幹分(fēn)支和(hé)開(kāi)發分(fē∞αφδn)支都(dōu)是(shì)長(chá$≥ng)期存在的(de)。下(xià)圖是(shì)Git Flow的(de)典型流程：

（From:https://docs.gitlab.com/ee/topic∏ ✘s/gitlab_flow.html#git-flow-and-its-proble᧥★ms）

       雖然Git Flow使開(kāi)發、修複、發布分(fēn)支很(hěn)清晰，但(dàn)很(hěn)難在采用(☆✔‍yòng)Git Flow的(de)工(gōng)程項目上(shàng)<↔‌進行(xíng)持續集成，main和(hé)develop分(fēn)支都(dōu)是(shì)長(cháng)期存✘"≤ 在的(de)，且随著(zhe)時(shí)間(jiān)的(de)增加，兩者可(λ£kě)能(néng)會(huì)有(yǒu)越來(lái)越大(dà λφφ)的(de)差異，難以形成自(zì)動化(huà)的(de)集成交付閉環。

GitHub Flow

      GitHub Flo"♣★‍w 對(duì)Git Flow進行(xíng)了(le)改進。開(kāi)發人(r'₩♥én)員(yuán)使用(yòng)功能( <‍néng)分(fēn)支（feature branch）并定期将其功能(néng)分(fēn)支推送到(dào)主幹。 發布通(tōng)常是(shì)直接從(có≈♦★Ωng)主幹完成的(de)。每個(gè)開(kāi)←≠♠ 發人(rén)員(yuán)都(dōu)會(huì)創Ω→ 建一(yī)個(gè)新分(fēn)支，即功能(néng)分(fēn)支。 功能(néng)分(fēn)支在功能(néng)完成後合并到(dà€‌o)主幹。

      GitHub Flow對(duì)持續集成有(yǒu)良好(hǎo)支←σ持的(de)，但(dàn)功能(néng)分(fēn)支可(kě↑")能(néng)會(huì)存在較長(cháng)的(de)時♥εφ→(shí)間(jiān)，從(cóng)而影₩φ(yǐng)響軟件(jiàn)集成的(de)頻(pín)度。

      另外(wài)，GitHub Flow的(de)概念中并沒有(yǒu)發布分(fēn)支，發布直接從(cóng)主幹進行(x£₽íng)，會(huì)對(duì)軟件(j≈±iàn)的(de)質量的(de)管控帶來(lái)更大(dà)的(de)挑戰→₽ δ。

GitLab Flow

     $‌ GitLab Flow在GitHub Flow的(de)基礎上(shàng)增加了(le)發布分(fēn)支（release branch），對(duì)持續集成有(yǒu)良好(hǎo)的(de)支持¶₽↓，也(yě)可(kě)以對(duì)需要(yào)發布的(de)産品→<£♦提前進行(xíng)凍結以更好(hǎo)的(de)管理₹♥™(lǐ)質量。它和(hé)TBD的(de)主要(yào)區(qū)别是(shì¥↑Ω)在模型的(de)理(lǐ)念上(shàng)，TBD更加鼓勵高(gāo)頻(pín)率的(de)代碼合并和(hé)‍¶←集成。

轉載汽車(chē)電(diàn)子(zǐ)相(xiàng)關文(wén)章(zh∑↑πāng)

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