當(dāng)前數(shù)字化轉(zhuǎn)型的形勢下，軟件行業(yè)面臨著巨大的市場機(jī)遇，而軟件系統(tǒng)復(fù)雜度不斷增加，跨地域高效協(xié)作、多環(huán)境部署等問題也逐漸突出，DevOps能幫助企業(yè)提升軟件研發(fā)效率，通過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來使得構(gòu)建、測試、發(fā)布軟件能夠更加快捷、頻繁和可靠。
基于此，我們策劃組織了2期【DevOps職業(yè)認(rèn)證訓(xùn)練營】，并邀請到姚冬、卜漢東兩位專家老師全程陪伴學(xué)習(xí)與答疑。在整理問答的過程中我們發(fā)現(xiàn)，學(xué)員提出的問題覆蓋了規(guī)劃設(shè)計(jì)、開發(fā)集成、測試、部署發(fā)布、運(yùn)維監(jiān)控等DevOps落地實(shí)踐中的關(guān)鍵疑點(diǎn)與難點(diǎn)。
本文從中挑選整理了60個(gè)精華問答，希望通過這些問題與解析，幫助更多DevOps實(shí)踐者解決DevOps落地過程中的疑惑與痛點(diǎn)。
【一、華為端到端DevOps概覽】
Q1：華為端到端的DevOps工具鏈?zhǔn)侨绾纬休d敏捷和DevOps相關(guān)理念和方法的？
A：敏捷和DevOps的理念其實(shí)是相通的，DevOps可以視作敏捷的延伸，敏捷思想打破了需求與開發(fā)之間的壁壘，DevOps則通過將開發(fā)與運(yùn)維間的壁壘打破，打通軟件交付全流程。
華為云DevOps工具鏈DevCloud包含了從需求管理到代碼托管、構(gòu)建部署、測試等一系列步驟，覆蓋軟件開發(fā)全生命周期。理念往往需要結(jié)合實(shí)踐，我們可以通過DevCloud進(jìn)行需求管理、每日站會等等許多敏捷實(shí)踐，通過提交代碼可以觸發(fā)執(zhí)行流水線，讓開發(fā)人員專注開發(fā)。
Q2：華為云DevCloud與傳統(tǒng)基于開源組件拼接的工具鏈，有什么差異優(yōu)勢？
A：傳統(tǒng)的由開源組件拼接而成的工具鏈，大部分都是使用Jira來進(jìn)行需求管理、用Git來做代碼托管、用Jenkins做DevOps開發(fā)，因?yàn)槠浣M件大部分都是開源的，所以一般費(fèi)用較低或者免費(fèi)，其缺點(diǎn)是使用者需要掌握很多工具，而且這些工具并不是在同一個(gè)平臺上。華為云DevCloud是一站式的軟件開發(fā)平臺，可以做到所有工具都在一個(gè)平臺上，端到端打通覆蓋整個(gè)軟件開發(fā)全生命周期。
用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的環(huán)境，還需要定制化地做一些腳本、配置等，華為云DevCloud相當(dāng)于是一個(gè)已經(jīng)封裝好了的DevOps開發(fā)工具，可以極大減少這些操作。
在華為云DevCloud里，將編譯構(gòu)建、部署任務(wù)等做成了原子化的操作，如果我們想要做Tomcat部署，可以直接使用這些模板，只需要對里面的步驟進(jìn)行細(xì)微的調(diào)整即可。而且它還使用了可視化視圖，操作起來一目了然，學(xué)習(xí)成本也比較低。華為云DevCloud還支持代碼檢查、自定義shell、Python、腳本、自定義report展示。
Q3：DevOps /敏捷和SDLC 有何不同？
A：DevOps/敏捷和SDLC的角度不一樣。SDLC是指系統(tǒng)生命周期，它提出的幾種典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。敏捷打破了需求和開發(fā)之間的溝通壁壘，DevOps則打通了整個(gè)軟件交付的全流程。
Q4：DevOps人員在與項(xiàng)目的結(jié)合中是否會承擔(dān)更多開發(fā)、測試、運(yùn)維的工作？
A：DevOps不會讓人去承擔(dān)更多開發(fā)、測試、運(yùn)維的工作。DevOps里有一個(gè)理念：讓開發(fā)的人專注于開發(fā)、測試的人專注于測試、運(yùn)維的人專注于運(yùn)維，所有的工具層面的東西全部交給工具，只要把一切可自動(dòng)化的東西自動(dòng)化，所有的人忙自己手頭的工作就好了。
Q5：DevOps的反模式有哪些？
A：參考《9種DevOps團(tuán)隊(duì)結(jié)構(gòu)適用類型與7種反型》
A：DevOps也好，敏捷也好，其初衷和理念適用于所有行業(yè)，但是每個(gè)行業(yè)在執(zhí)行和實(shí)際落地效果上會有一些折扣，比如持續(xù)交付的生產(chǎn)環(huán)境、自動(dòng)化部署、質(zhì)量管控、自動(dòng)化流轉(zhuǎn)等過程的實(shí)現(xiàn)等。
簡單而言，互聯(lián)網(wǎng)的一些應(yīng)用，或者說SaaS應(yīng)用，相對來說更適合DevOps的研發(fā)模式。原因是：其業(yè)務(wù)對軟件更新、發(fā)布的要求較高；沒有太大的歷史包袱；相對更容易對標(biāo)目標(biāo)受眾群體，包括生產(chǎn)環(huán)境等。
傳統(tǒng)類的業(yè)務(wù)比較重，比如銀行的核心系統(tǒng)，實(shí)踐起來相對較難，也不是說不能用敏捷或DevOps。比如持續(xù)集成、每天多次構(gòu)建、多次提交代碼、自動(dòng)化測試、可視化等，都可以實(shí)行。
對于非軟件行業(yè)，如硬件、嵌入式、機(jī)械類，實(shí)踐起來也比較難，比如測試自動(dòng)化等，需要做一些工具或平臺的適配，引進(jìn)插件或工具后，流程也能夠跑起來，只是會慢一些。
綜上，我認(rèn)為敏捷和DevOps本身是一條沒有終點(diǎn)的路，所有行業(yè)都可以到這條路上來，只是走得難易與遠(yuǎn)近的問題。
Q7：在企業(yè)落地DevOps有沒有什么套路？
A：企業(yè)實(shí)際情況各不相同，落地DevOps沒有統(tǒng)一的套路，但會有一些建議的方式。DevOps偏工程側(cè)，通常建議先把版本管理建立起來，比如Git代碼倉、代碼分支管理等；接下來需要把流水線構(gòu)建起來，在上面逐漸進(jìn)行自動(dòng)化測試、分層測試等。
Q8：最能有效促進(jìn)Scrum團(tuán)隊(duì)本身的持續(xù)改進(jìn)的是什么實(shí)踐？
A：每個(gè)團(tuán)隊(duì)遇到的問題都是不一樣的，如果一定要找一個(gè)通用的答案，首先要保證團(tuán)隊(duì)每日站會、評審會議等如質(zhì)如期進(jìn)行，以此來保持持續(xù)改進(jìn)。
Q9：基于DevOps實(shí)現(xiàn)持續(xù)有效規(guī)劃應(yīng)該先從哪個(gè)層面去入手呢？
A：首先需要理解DevOps和敏捷的含義，我們一般說的規(guī)劃與設(shè)計(jì)更偏向于敏捷項(xiàng)目管理中涵蓋的需求和計(jì)劃。
狹義的DevOps主要是CI/CD，即持續(xù)集成和持續(xù)部署，是偏工程側(cè)的。廣義的DevOps，即本訓(xùn)練營中講的DevOps是“端到端的DevOps”，從持續(xù)集成/持續(xù)部署，向前延伸到業(yè)務(wù)側(cè)，向后延伸到運(yùn)維/運(yùn)營側(cè)，因此也涵蓋了前段的需求和設(shè)計(jì)層面。
回到問題，基于DevOps實(shí)現(xiàn)持續(xù)有效規(guī)劃，應(yīng)該從需求和計(jì)劃切入，包括整個(gè)的市場分析、目標(biāo)客戶群體的用戶畫像，用戶的痛點(diǎn)是什么，針對這些痛點(diǎn)提供什么樣的功能，然后到產(chǎn)品應(yīng)該怎么設(shè)計(jì)，接下來才真正落到研發(fā)這個(gè)主體上。
從方法論角度來看，需求和設(shè)計(jì)層面的方法論包括設(shè)計(jì)思維、精益創(chuàng)業(yè)等。做好需求分析后，就要進(jìn)行需求拆分，排列優(yōu)先級，這樣就進(jìn)到敏捷項(xiàng)目計(jì)劃里，方法論包括看板、Scrum等，大規(guī)模團(tuán)隊(duì)敏捷框架有SAFe等。
Q10：Scrum，看板和 XP 是敏捷開發(fā)的具體方式，老師能否具體講解一下區(qū)別？
A：參考文章《DevOps VS 敏捷：傻傻分不清楚》。
Scrum和看板更側(cè)重在團(tuán)隊(duì)級敏捷項(xiàng)目管理層面，XP更偏向于工程實(shí)踐層面。
Scrum和看板兩者比較：“標(biāo)準(zhǔn)的”Scrum包括3355的框架；看板源自豐田的精益生產(chǎn)，其背后是精益的思想，通過可視化、限制在制品的數(shù)量，快速暴露問題和瓶頸點(diǎn)，集中對最嚴(yán)重的瓶頸點(diǎn)進(jìn)行修復(fù)，然后去尋找下一個(gè)瓶頸點(diǎn)。
DevOps的很多理念同樣借鑒了精益的思想，個(gè)人認(rèn)為，看板可以應(yīng)用到很多領(lǐng)域。另外，Scrum和看板在實(shí)施或應(yīng)用時(shí)并沒有沖突，可以結(jié)合起來使用。
Q11：企業(yè)組織架構(gòu)中什么角色或者部分適合推行DevOps落地？
A：企業(yè)組織架構(gòu)中一般都沒有專門的組織來推行和落地DevOps。DevOps包括兩個(gè)部分“Dev”和“Ops”，就是指開發(fā)部門和運(yùn)維部門。
幾種常見的情況：
如果是由開發(fā)部門來發(fā)起DevOps落地，就是由開發(fā)往運(yùn)維去推進(jìn)。我們平時(shí)看到比較多的是測試團(tuán)隊(duì)或傳統(tǒng)的質(zhì)量管理部門來發(fā)起，從開發(fā)到測試再往前一步到運(yùn)維生產(chǎn)環(huán)境上去，因?yàn)檫@些部門本身就承擔(dān)著代碼托管、編譯構(gòu)建、自動(dòng)化測試等職能。
而有的公司會把內(nèi)部的基礎(chǔ)設(shè)施、IT支撐、測試等放在數(shù)據(jù)中心，往前去推把自己變成類似我們講的DevOps工程師，然后通過自動(dòng)化工具幫助開發(fā)團(tuán)隊(duì)進(jìn)行自動(dòng)化部署等，這就是從運(yùn)維側(cè)往前推進(jìn)DevOps落地。
還有一種情況，就是近年來比較火的云原生，架構(gòu)師更多考慮采用微服務(wù)架構(gòu)，通過基礎(chǔ)設(shè)施即代碼等方式自動(dòng)化部署到Docker環(huán)境中去，因此引入自動(dòng)化流水線、Infrastructure as Code（基礎(chǔ)設(shè)施即代碼）、接口測試等實(shí)踐，這些都屬于DevOps的范疇。
還有一些其他的角色，比如敏捷教練、內(nèi)部的技術(shù)教練等，他們本身就是在做研發(fā)管理的落地實(shí)踐，很自然地轉(zhuǎn)化去做DevOps推進(jìn)。
綜上，DevOps的推進(jìn)和落地不一定非要有一個(gè)DevOps工程師或獨(dú)立的DevOps團(tuán)隊(duì)，初期引入DevOps的時(shí)候需要有一個(gè)團(tuán)隊(duì)或角色去承擔(dān)起這個(gè)職責(zé)，進(jìn)行概念和實(shí)踐的導(dǎo)入和探索，這時(shí)更容易把DevOps工程師、DevOps團(tuán)隊(duì)建立起來。而后期應(yīng)該把這些工程師或能力分散到各個(gè)團(tuán)隊(duì)中去，讓DevOps在企業(yè)內(nèi)有更廣泛的傳播和實(shí)踐。
Q12：請問在Scrum中，如果沒有項(xiàng)目經(jīng)理，是由TeamLeader還是ScrumMaster協(xié)調(diào)資源？
A：應(yīng)該由TeamLeader來協(xié)調(diào)資源，ScrumMaster不是管理角色，而更多的是一個(gè)輔助的牧羊犬的角色，在Scrum實(shí)施過程中守護(hù)團(tuán)隊(duì)Scrum流程不受干擾。
Q13：對于非產(chǎn)品形態(tài)的項(xiàng)目，Product Owner來自哪個(gè)部門更合適？（業(yè)務(wù)部門/研發(fā)部門）
A：Product Owner代表客戶，一般是哪個(gè)部門更接近業(yè)務(wù)，更了解業(yè)務(wù)和系統(tǒng)，就由這個(gè)部門的人來擔(dān)任。非產(chǎn)品形態(tài)項(xiàng)目的Product Owner，要求既了解業(yè)務(wù)又懂技術(shù)，一般可以由業(yè)務(wù)分析師、PMO等角色擔(dān)任。
Q14：實(shí)際開發(fā)中，客戶往往無人承擔(dān)PO的角色，而是領(lǐng)導(dǎo)來承擔(dān)，如何破解這個(gè)問題？
A：這種情況可稱為“BDD”，Boss-Driven Development，老板驅(qū)動(dòng)開發(fā)。好處是至少有一個(gè)人能拍板；壞處是拍板的人，你可能很難去辯駁或談判，所以最好還是能夠把客戶側(cè)的人拉進(jìn)來。當(dāng)然，如果老板確實(shí)對業(yè)務(wù)非常了解，也非常專業(yè)，并且是一個(gè)可溝通的人，也是可以的。PO的核心要求是需要有一個(gè)人代表客戶或業(yè)務(wù)側(cè)，針對需求或范圍做決定，且當(dāng)團(tuán)隊(duì)有問題的時(shí)候，可以隨時(shí)找到這個(gè)人。
Q15：影響地圖主要應(yīng)用于哪個(gè)環(huán)節(jié)？
A：從HE2E DevOps實(shí)施框架圖可以看到，在端到端的DevOps實(shí)踐中，影響地圖通常用于需求規(guī)劃或業(yè)務(wù)規(guī)劃階段，與傳統(tǒng)的Scrum流程相比，更偏業(yè)務(wù)側(cè)。影響地圖通過四層結(jié)構(gòu)：why、who、how、what來拆解業(yè)務(wù)和需求，也可以用于運(yùn)營或項(xiàng)目冷啟動(dòng)環(huán)節(jié)。
Q16：請問如果一個(gè)大的Story拆分成多個(gè)小的Story，甚至再次拆分成孫子輩的Story，如何更好地表示這些關(guān)聯(lián)關(guān)系？
A：Story拆分有兩種方式：一種是從epic（史詩故事）到feature到story的拆分，epic以月為單位，feature以周為單位，story以天為單位；另一種是平級拆分，所有拆分的故事全部叫story，只不過它們之間存在父子關(guān)系。不管是三層還是四層，我們只關(guān)注父子關(guān)系，從一個(gè)父story拆分出子story，如果粒度不夠小，則以子story為父story繼續(xù)拆分出它的子story。如果系統(tǒng)需要有層級追溯，可以用樹狀或腦圖等結(jié)構(gòu)來展現(xiàn)。
Q17：學(xué)完課程感覺用戶故事和項(xiàng)目管理里的工作包很像，二者有個(gè)共同的問題，拆解到什么粒度是好的用戶故事？
A：故事也好，需求也好，只是一個(gè)名字，用戶故事之所以叫用戶故事，有兩點(diǎn)表征：1）它是站在用戶的角度去看；2）它講了一個(gè)故事、一個(gè)場景。好的用戶故事遵循INVEST原則，即一個(gè)合適的用戶故事應(yīng)該是獨(dú)立的（Independent）、有價(jià)值的（Valuable）、可討論的（Negotiable）、小的（Small）、可估算的（Estimable）和可測試驗(yàn)證的（Testable）。
Q18：如果采用敏捷開發(fā)，最終的用戶需求如何呈現(xiàn)給用戶？如果是需要存檔的用戶需求說明書、設(shè)計(jì)說明書或操作手冊之類的文檔，適合從DevCloud導(dǎo)出后再修改么？另外如果出現(xiàn)變更，如何確保文檔與代碼一致？
A：如果是需求文檔，可以以用戶故事的形式存放，華為云DevCloud或者其他工具都提供多元的存儲格式，如文本、圖片、附件等，華為云DevCloud有一個(gè)幫助網(wǎng)站，每一個(gè)新上線的功能都會在這里進(jìn)行同步和更新。
也可以把詞條或需求存放到wiki里，并跟前端的需求條目之間建立鏈接。wiki本身是可以有層級關(guān)系的，可以把需求從wiki里導(dǎo)出來形成文檔形式，如果做得好，還會有版本計(jì)劃，比如版本里包括10條需求，可以統(tǒng)一導(dǎo)出一篇需求規(guī)格說明文檔。
需求和代碼之間的同步，可以通過流程等方式去控制，比如發(fā)版的檢查點(diǎn)，這可能需要以人工方式去做，但也可以通過一些工具來輔助。比如提交代碼的時(shí)候需要提交注釋，可以把這個(gè)注釋關(guān)聯(lián)到一個(gè)工作項(xiàng)上，一個(gè)需求可能會修改多個(gè)文件里的多段代碼，這其實(shí)就是一個(gè)完整的變更集的概念，這個(gè)變更是為了同一個(gè)目的，是有相關(guān)性的，如果要從代碼里去剝離的話，應(yīng)該會把這一次變更集統(tǒng)一進(jìn)行剝離。在未來查看代碼時(shí)，可以進(jìn)行代碼版本比較，看兩個(gè)版本之間進(jìn)行了哪些增加/修改、這些變更是為什么目的、其意圖是什么。
Q19：對于變化的需求或者新增的需求，是應(yīng)該放到當(dāng)前迭代里，還是規(guī)劃到后面的迭代里，持續(xù)規(guī)劃是指規(guī)劃過程貫穿整個(gè)生命周期么？
A：變化或新增的需求都會統(tǒng)一放到一個(gè)大的池子里，我們稱之為product backlog（產(chǎn)品待辦事項(xiàng)列表），這是一個(gè)一維的表格，所有需求按照優(yōu)先級排列。我們要通過判斷新進(jìn)需求的優(yōu)先級，看它應(yīng)該放在什么位置。敏捷強(qiáng)調(diào)需求是動(dòng)態(tài)變化的，我們會定期對需求列表進(jìn)行梳理，看是否需要進(jìn)行優(yōu)先級排序的調(diào)整，
因此變化或新增的需求不會放到當(dāng)前的迭代里，因?yàn)楫?dāng)前迭代是一個(gè)固定的時(shí)間窗口，且范圍相對固定，團(tuán)隊(duì)對此進(jìn)行了承諾。我們會將其放入大的需求池，是在下個(gè)迭代還是之后的迭代實(shí)現(xiàn)，取決于該需求的優(yōu)先級。
Q20：對于初學(xué)者剛剛接觸一個(gè)項(xiàng)目，但是項(xiàng)目的需求不明確、結(jié)構(gòu)不成熟，怎么從敏捷入手？
A：這里包括兩種情況：初學(xué)者、項(xiàng)目在初級階段。如果是初學(xué)者，應(yīng)該通過獲取現(xiàn)有資產(chǎn)快速熟悉和上手；如果項(xiàng)目處于初級階段，需求也不太明確，可以通過敏捷的快速交付、精益的MVP等實(shí)踐，快速獲取反饋，對后續(xù)工作進(jìn)行指導(dǎo)和建議。
Q21：作為整個(gè)項(xiàng)目的入口，需求的質(zhì)量如何把控和評測？
A：明確定義需求可以轉(zhuǎn)開發(fā)的標(biāo)準(zhǔn)，即DoR。那什么是DoR呢？敏捷開發(fā)發(fā)展了幾個(gè)年頭之后，人們發(fā)現(xiàn)進(jìn)入迭代開發(fā)應(yīng)當(dāng)滿足一定條件，否則過于模糊的需求會導(dǎo)致迭代的失敗，在迭代內(nèi)花費(fèi)過多的時(shí)間去做需求澄清，因此給進(jìn)入迭代設(shè)立門檻，就是Definition of Ready，簡略稱之為“DoR”， 最初的Ready是指準(zhǔn)備好可以進(jìn)入迭代開發(fā)。
Q22：持續(xù)規(guī)劃與設(shè)計(jì)有什么度量數(shù)據(jù)或指標(biāo)用于衡量團(tuán)隊(duì)績效或用于持續(xù)改進(jìn)？如何衡量持續(xù)規(guī)劃與設(shè)計(jì)的成熟度？
A：度量工具推薦Scum的燃盡圖、看板的累積流圖。研發(fā)效能的核心度量數(shù)據(jù)指標(biāo)包括團(tuán)隊(duì)速率、Lead time，即需求的平均交付時(shí)長。
Q23：敏捷下的組織過程資產(chǎn)（配置、文檔等）這些有好的存儲方案么？
A：理論上文檔、資產(chǎn)等都存儲在資產(chǎn)庫里，常用的知識庫或資產(chǎn)平臺有Conflunce、IBM的Rational Asset Manager等。資產(chǎn)和知識是不同的概念，現(xiàn)在做資產(chǎn)管理的相對少一些，知識庫可以用wiki等平臺，便于統(tǒng)一維護(hù)更新和協(xié)同。
Q24：DevOps 持續(xù)規(guī)劃與設(shè)計(jì)在DevOps生命周期中是處于開始的時(shí)刻，為什么還說代碼集成是整個(gè)DevOps生命周期的核心呢?
A：“代碼集成”包括兩部分：代碼和集成。
整個(gè)軟件生命周期包括三個(gè)版本：需求版本，即發(fā)版計(jì)劃；代碼版本；上線發(fā)布的二進(jìn)制包的版本。其中代碼版本處于承前啟后的中間位置，且是唯一真正有價(jià)值的。需求和文檔是沒有價(jià)值的，只有由代碼編譯成二進(jìn)制包并部署上線才是有價(jià)值的。在代碼層面多花一些精力是非常有必要的，所有的研發(fā)其實(shí)都是在一個(gè)代碼倉庫里進(jìn)行協(xié)同開發(fā)，包括代碼版本管理、分支管理等模式，因此將代碼視為DevOps生命周期的核心也是必然的。
軟件研發(fā)最痛苦的地方往往是在集成層面，一開始大家各寫各的代碼，一旦要將這些不同的代碼進(jìn)行集成的時(shí)候，問題就出現(xiàn)了。持續(xù)集成的概念來源于XP，“如果代碼集成是一件非常痛苦的事情，那我們就每天多次地進(jìn)行。”一切殺不死你的都會讓你更強(qiáng)大，持續(xù)地進(jìn)行集成，你會想辦法去減少集成的痛苦。就像跑步一樣，假如以前的集成是一塊大石頭，每天多次集成就相當(dāng)于將這塊石頭變成一顆顆的小石子，大石頭打在身上會非常疼，小石子就好多了。這也是我們?yōu)槭裁匆鸭赏疤?，并且持續(xù)去進(jìn)行的原因，所以在DevOps生命周期中持續(xù)集成也非常重要。
Q25：如何加強(qiáng)開發(fā)人員對于版本質(zhì)量的信心？
A：加強(qiáng)對版本質(zhì)量的信心，不只是針對開發(fā)人員，對所有人都應(yīng)該如此。整個(gè)DevOps的過程其實(shí)就是在保障整體的版本質(zhì)量，包括靜態(tài)代碼檢測、接口API測試等。
另一方面，版本對需求的映射關(guān)系或完成程度，應(yīng)該從業(yè)務(wù)場景往下去切，看整個(gè)需求的匹配程度。
第三點(diǎn)應(yīng)該是我們通常說的非功能性需求（Non-functional requirements），比如負(fù)載、性能、安全、并發(fā)支持等，這些要根據(jù)我們服務(wù)承諾的質(zhì)量來做相關(guān)措施。
Q26：敏捷開發(fā)相比傳統(tǒng)開發(fā)有什么優(yōu)點(diǎn)？
A：我認(rèn)為最大的優(yōu)點(diǎn)或特點(diǎn)是敏捷開發(fā)更真實(shí)，或者說它更愿意承認(rèn)研發(fā)的本質(zhì)或現(xiàn)狀。
傳統(tǒng)的研發(fā)認(rèn)為質(zhì)量受三個(gè)因素制約：范圍、資源、時(shí)間，且默認(rèn)范圍和資源投入是相對確定的，時(shí)間是變化的。然而，在真實(shí)場景或變化的市場下，時(shí)間和資源是固定的，沒辦法討價(jià)還價(jià)，因?yàn)槭袌觥I(yè)務(wù)、客戶都不會等你，在這樣的前提下，軟件的需求或范圍實(shí)際上是可以商量或討論的，我們要以可變的范圍去贏得市場、時(shí)間窗口。
敏捷開發(fā)要求我們不斷交付高優(yōu)先級的需求，并獲取反饋，不斷調(diào)整。這是敏捷開發(fā)的最大的核心，承認(rèn)市場是變化莫測的，需求范圍是可變的。
Q27：一個(gè)產(chǎn)品，既有主線版本，又有很多的行業(yè)定制分支（50+），適合什么樣的分支策略？
A：這種場景在傳統(tǒng)的產(chǎn)品里比較常見，個(gè)人認(rèn)為應(yīng)該考慮的是產(chǎn)品策略而不是分支策略。如果分支非常多，會導(dǎo)致產(chǎn)品碎片化嚴(yán)重。
我們在持續(xù)集成、持續(xù)交付的時(shí)候，推崇主干開發(fā)或短的分支，不希望這些分支長期存在，否則在產(chǎn)品進(jìn)行合并時(shí)會非常痛苦，工作量也會隨著分支的多少和分支存在的時(shí)間呈幾何倍數(shù)增長，所以不建議用長期存在的分支。
那可以用什么樣的方式來解決呢？首先要看整個(gè)版本上是否一定要出現(xiàn)這么多定制化的分支，這些分支有沒有可能通過配置文件、功能開放等方式處理或?qū)崿F(xiàn)。舉個(gè)例子，我們做項(xiàng)目管理的軟件，每個(gè)客戶要求的字段、功能流轉(zhuǎn)的流程都不太一樣，如果都通過代碼實(shí)現(xiàn)，有多少客戶就會出現(xiàn)多少個(gè)分支，可能都不止50個(gè)。
我們是怎么做的呢？針對字段，我可以配置一個(gè)界面，里面包括常見屬性的字段，這個(gè)字段可以是文本類型或下拉框等形式；功能流轉(zhuǎn)的話，新進(jìn)來一個(gè)需求，它的下一個(gè)狀態(tài)是什么、應(yīng)該觸發(fā)什么動(dòng)作、應(yīng)該是什么樣的角色來觸發(fā)這個(gè)動(dòng)作等這些都是可以進(jìn)行配置的，這些配置信息存在數(shù)據(jù)庫里，變成用戶的配置數(shù)據(jù)，這樣我的主代碼主程序是保持不變的，只需要提供一套模型根據(jù)數(shù)據(jù)去驅(qū)動(dòng)適配或?qū)崿F(xiàn)。這是我們更推崇的方式，可以用來消滅那些分支。
Q28：日常項(xiàng)目開發(fā)，在代碼分支管理上經(jīng)常疑惑用什么分支管理策略，比如是選擇基于生產(chǎn)分支工作流，還是基于環(huán)境等等，在實(shí)際實(shí)踐中，我們應(yīng)該重點(diǎn)考慮哪些因素？既可以兼顧管理效率，又可以確保代碼質(zhì)量。
A：個(gè)人建議采用分支開發(fā)主干發(fā)布或分支開發(fā)分支發(fā)布的分支管理策略。基于環(huán)境進(jìn)行分支構(gòu)建的話，以前我們會有開發(fā)庫測試庫等倉庫管理的概念，但現(xiàn)在全部是持續(xù)集成、自動(dòng)化部署，就沒必要再基于環(huán)境去拉取分支了。
如何保證代碼質(zhì)量，我們在CI/CD流水線、自動(dòng)化部署和構(gòu)建的同時(shí)需要考慮每一個(gè)環(huán)境上跑哪些測試，這些測試大部分通過自動(dòng)化的方式實(shí)現(xiàn)，也有少量的是手工進(jìn)行。
A：華為云團(tuán)隊(duì)也是采用特性分支的管理模式，同時(shí)會做多級流水線觸發(fā)不同環(huán)境的流水線來做相關(guān)構(gòu)建，除了開發(fā)環(huán)境的流水線以外，還有測試、類生產(chǎn)環(huán)境等流水線。
A：首先主干上提交的流程或質(zhì)量要嚴(yán)格控制，真正達(dá)到DoD（Definition of Done）的標(biāo)準(zhǔn)，這里可能需要一些機(jī)制人為地進(jìn)行管控，比如Committer機(jī)制等。提交的時(shí)候，除了非功能性的要求，比如跑相關(guān)的回歸測試、代碼檢視以外，還有很重要的功能性要求，比如對需求的實(shí)現(xiàn)程度的檢查。另外“基礎(chǔ)設(shè)施即代碼”，還要看持續(xù)集成、持續(xù)部署、自動(dòng)化測試能不能快速有效地跑起來，并保持高度一致。
Q31：持續(xù)集成的成功因素是什么？
A：持續(xù)集成主要包括代碼倉庫、自動(dòng)構(gòu)建、自動(dòng)部署、自動(dòng)測試四個(gè)方面。要求每人每天都要向主干提交代碼，觸發(fā)自動(dòng)構(gòu)建和自動(dòng)部署，在類生產(chǎn)環(huán)境進(jìn)行自動(dòng)化測試，同時(shí)需要團(tuán)隊(duì)每個(gè)成員確保清楚正在發(fā)生的狀況，以此來保證持續(xù)集成的成功。
Q32：華為云上的CI/CD與K8s上搭的CI/CD有什么區(qū)別？
A：華為云DevCloud打通了端到端的軟件交付全流程，集成了常用的DevOps開發(fā)工具，不僅可以完成CI/CD，還可以直接在上面進(jìn)行項(xiàng)目管理和開發(fā)；而K8s只是軟件開發(fā)中一個(gè)單獨(dú)的工具，沒有項(xiàng)目需求管理等功能，需要配合其他工具一起使用才能實(shí)現(xiàn)完整的軟件開發(fā)與交付。
Q33：開發(fā)和修復(fù)bug的工時(shí)如何進(jìn)行安排呢？之前迭代出來的bug是按照單獨(dú)工時(shí)安排，還是統(tǒng)一安排在開發(fā)中？
A：主要看發(fā)版的標(biāo)準(zhǔn)和要求是什么，通常來說可以帶病發(fā)版，但如果是非常嚴(yán)重的缺陷，就不能上線，必須先修復(fù)這些bug。一般bug會跟需求放在同一個(gè)池子里，根據(jù)它的優(yōu)先級和影響程度來進(jìn)行排序，決定是先修復(fù)bug還是先做需求。如果修改bug是為了掃清技術(shù)債務(wù)，建議在一個(gè)迭代里固定一定比例的時(shí)間來進(jìn)行。
Q34：感覺SaltStack和Ansible中哪個(gè)是最好的配置管理（CM）工具？為什么？
A：兩者定位不一樣。個(gè)人認(rèn)為Ansible并不是一個(gè)標(biāo)準(zhǔn)的配置管理工具，它更多是通過自動(dòng)化部署的手段去touch環(huán)境這一側(cè)，SaltStack相對來說功能性更強(qiáng)一些。
Q35：在代碼互評審和評審流程中如何高效的提升代碼質(zhì)量？
A：人機(jī)結(jié)合，將重復(fù)性的，比如檢查代碼風(fēng)格、命名規(guī)則等工作交給工具；人工集中看代碼實(shí)踐的邏輯、對需求的匹配等。將人從重復(fù)性的工作中解放出來，節(jié)約時(shí)間和人力。
華為實(shí)行代碼審查Committer機(jī)制，開發(fā)人員提交代碼后，會自動(dòng)拉起自動(dòng)化代碼檢查。提交一個(gè)Pull Request，工具匹配相關(guān)的review進(jìn)行評審和打分，如果是重要實(shí)現(xiàn)還可能會有一個(gè)評審會議，然后進(jìn)入最終Committer決定是否將提交的代碼合并到主干上去。
Q36：“通過持續(xù)測試實(shí)現(xiàn)快速與高質(zhì)量“是敏捷測試原則之一，而測試金字塔頂端的一些測試往往依賴許多外部因素，較為脆弱，容易因被測軟件之外的因素而失??；且由于這類測試同時(shí)測試了軟件中的多個(gè)模塊，定位問題就會更難一些。對于 Flaky tests 怎樣處理比較好？刪除還是進(jìn)行標(biāo)記使其不中斷后續(xù)的測試且不影響質(zhì)量門禁？
A：Flaky Tests，就是指在被測對象和測試條件都不變的情況下，有時(shí)候失敗、有時(shí)候成功的測試。因此，F(xiàn)laky Tests實(shí)際上就是不穩(wěn)定的測試，或者隨機(jī)失敗(隨機(jī)成功)的測試。
測試金字塔之所以是正的三角形，核心理念是越往上，即金字塔頂端的測試，其跨度越大，影響面越大，一旦出現(xiàn)問題，爆炸的半徑也會更大，在這個(gè)層面做測試投入產(chǎn)出較小，工作量大且很難執(zhí)行，比如測試故障定位等，而且自動(dòng)化用例的復(fù)用程度或穩(wěn)定性也較差，維護(hù)成本也比較高。當(dāng)然該做的工作一定要做，但相對而言，建議這個(gè)層面的測試數(shù)量要適當(dāng)減少。
相反，越往底層，比如單元測試，爆炸半徑相對就小一些，復(fù)用度和投入產(chǎn)出比也更高，而且在這個(gè)層面發(fā)現(xiàn)的bug應(yīng)該是最多的。建議金字塔底層的測試措施應(yīng)該相對多做。
中間比如接口測試或跨組件的集成等，如果微服務(wù)拆分相對顆粒度小一些，各方面相對就比較好，且接口測試相應(yīng)的工具也比較多，投入產(chǎn)出比也會越來越大。接口測試也可以多做一些，這樣中間層變大，金字塔也會變成橄欖球形。
Q37：構(gòu)建本地持續(xù)測試和云上持續(xù)測試的對比難易程度和成本，如何選取？
A：本地持續(xù)測試和云上持續(xù)測試的差異在于：本地需要自行對工具和版本進(jìn)行維護(hù)，云上的環(huán)境相對快捷。從成本方面考慮，云上是按需的，性能測試、壓力測試等適合在云上進(jìn)行，因?yàn)樽约喝ゴ罱ㄒ惶?0萬/100萬并發(fā)的環(huán)境成本非常高；越往前端的測試頻度非常高，適合在本地進(jìn)行構(gòu)建。另外還需要綜合考慮開發(fā)人員的使用習(xí)慣、公司對于數(shù)據(jù)的安全要求等進(jìn)行選取。
Q38：從傳統(tǒng)的瀑布型測試到敏捷測試再到DevOps，三者之間具體有什么區(qū)別？
A：瀑布型測試是在開發(fā)完成交付以后才進(jìn)行完整的測試，測試主體是測試人員；敏捷測試往前走一步，做大量的持續(xù)集成等實(shí)踐（如果敏捷實(shí)踐不只是在管理層面的話）；DevOps是全流程測試，除了測試左移外，還有測試右移，頻繁地持續(xù)部署到準(zhǔn)生產(chǎn)或生產(chǎn)環(huán)境上去跑相關(guān)測試，甚至還有現(xiàn)網(wǎng)測試，包括混沌工程、Chaos monkey等，其概念更廣。DevOps信奉Resilience（韌性），測試這件事很痛苦，我們要頻繁地去做。和反脆弱的概念比較一致，“一切殺不死你的讓你更堅(jiān)強(qiáng)”。
Q39 在測試自動(dòng)化環(huán)節(jié)中應(yīng)該如何簡化測試流程又能快速發(fā)現(xiàn)業(yè)務(wù)風(fēng)險(xiǎn)？
A：測試流程未必會簡化，所謂的簡化應(yīng)該是指人員參與的流程減少，把大量能夠讓機(jī)器完成的工作交給機(jī)器、回歸測試等實(shí)現(xiàn)自動(dòng)化，將人從枯燥的重復(fù)性的測試活動(dòng)中解放出來，去做一些新型測試的探索。
Q40：SRE和DevOps有什么區(qū)別和聯(lián)系？
A：DevOps通常由兩種角色去發(fā)起，Dev和Ops，即開發(fā)和運(yùn)維。
SRE是Google首先提出的一個(gè)概念，Site Reliability Engineer（網(wǎng)站可靠性工程師），從Google運(yùn)維體系出來的一個(gè)角色。
SRE工程師會通過自動(dòng)化工具幫助開發(fā)人員，以運(yùn)維的角度去參與研發(fā)并提供一些支持，包括開發(fā)一些自動(dòng)化部署及運(yùn)維相關(guān)的工具，通過這些工具和流程使能開發(fā)人員。
兩者比較而言，DevOps概念和范圍相對更大一些，SRE則聚焦在開發(fā)與運(yùn)維層面。
Q41：在Scrum中只有 Dev team，沒有專門的測試團(tuán)隊(duì)?！白鰷y試者勝于做檢查者”也要求測試人員不僅能發(fā)現(xiàn)問題更要準(zhǔn)確定位問題。持續(xù)測試向價(jià)值流持續(xù)交付的兩端延伸，要求測試人員不僅要懂業(yè)務(wù)、懂開發(fā)還要懂運(yùn)維，對測試人員的要求很高。在這種背景下，測試人員該如何進(jìn)行職業(yè)發(fā)展規(guī)劃？
A：確實(shí)測試人員的焦慮相對更多，因?yàn)椴还芰鞒桃埠?、角色分工也好，他都處于開發(fā)和運(yùn)維之間的位置，像三明治一樣，比較難受。
換個(gè)角度來看，測試是承上啟下的活動(dòng)，DevOps或敏捷在開始的時(shí)候都會相對順利一些，短期成效很快，但等真正進(jìn)入到測試層面，就像進(jìn)入深水區(qū)，推進(jìn)變得困難，原因可能就是自動(dòng)化測試沒做好。這樣看來測試人員或測試活動(dòng)其實(shí)大有可為，我們強(qiáng)調(diào)測試應(yīng)該是一類活動(dòng)，分配在整個(gè)研發(fā)生命周期過程中，而不是中間的某個(gè)階段，因此對測試人員的要求當(dāng)然也會更高。
以往測試人員給人的印象是在研發(fā)提交后才參與進(jìn)來，或者大量通過手工界面的點(diǎn)擊去做回歸等工作?，F(xiàn)在和未來，這類測試人員存在的價(jià)值會很低，未來可能會要求測試人員懂業(yè)務(wù)，從業(yè)務(wù)的角度設(shè)計(jì)測試用例；還要懂開發(fā)，需要寫測試腳本；還要懂運(yùn)維。其實(shí)這些要求對所有的工程師都同樣存在，包括開發(fā)工程師，要會做架構(gòu)、做設(shè)計(jì)、做開發(fā)、還可能要自己做測試、部署運(yùn)維等；運(yùn)維工程師也是如此，如果轉(zhuǎn)型SRE工程師的話，也要往前段去走。從這點(diǎn)來看，大家都在同一水平線上，所有人都要求往T型人才發(fā)展。
綜上，測試工程師應(yīng)該是一個(gè)全程的質(zhì)量保障人員，要從專業(yè)測試的視角對研發(fā)流程、需求、交付等進(jìn)行質(zhì)量控制，還需要引入相關(guān)實(shí)踐、開發(fā)工具或做工具集成，去賦能開發(fā)和運(yùn)維。真正好的測試對整個(gè)團(tuán)隊(duì)的幫助和提升應(yīng)該是最大的。
Q42：與傳統(tǒng)項(xiàng)目比較，在敏捷項(xiàng)目中，測試工作在整個(gè)流程中所占的比重是否更少了，頻次更高了，這是否意味著人效更高了？在DevOps流程下，產(chǎn)品人員、開發(fā)人員、主導(dǎo)測試人員的比例是否有一個(gè)新的經(jīng)驗(yàn)參考？
A：與傳統(tǒng)項(xiàng)目相比，敏捷項(xiàng)目中，測試工作比重更大、頻次更高、人效也會更高，但這個(gè)更高不是通過人去堆，而是通過自動(dòng)化工具或時(shí)間來完成。在DevOps流程下，專職的測試人員數(shù)量會下降，現(xiàn)在大量的開發(fā)測試是由開發(fā)人員來做，在華為內(nèi)部稱為開發(fā)者測試，強(qiáng)調(diào)開發(fā)人員自己去做測試，以前開發(fā)測試比例差不多是3:1， 甚至1:1，現(xiàn)在可能是5：1或10:1的比例。產(chǎn)品人員跟以往應(yīng)該沒有太大差異，現(xiàn)在強(qiáng)調(diào)產(chǎn)品思維、運(yùn)營思維，業(yè)務(wù)運(yùn)營人員的人數(shù)會增加。
Q43：小團(tuán)隊(duì)（5人，分工：2前端，3后端，沒有專業(yè)測試人員）需要單獨(dú)配備測試人員嗎，一邊開發(fā)一邊測試，還是每個(gè)人對自己代碼負(fù)責(zé)最后一塊集中測試。這兩種哪種好一些？
A：個(gè)人認(rèn)為5人團(tuán)隊(duì)沒有必要配置專職測試，可以先由開發(fā)承擔(dān)測試，當(dāng)團(tuán)隊(duì)認(rèn)為需要有一個(gè)專業(yè)的測試去知道或支持時(shí)，再去引入專業(yè)測試人員。那端到端的測試誰來做？建議是采用輪崗機(jī)制，類似on call，讓團(tuán)隊(duì)成員輪流去做，這樣可以讓所有人對完整的測試都有了解和重視。
Q44：未來是否會研測一體化？
A：我認(rèn)為研側(cè)一體化會是一個(gè)趨勢，開發(fā)者測試或開發(fā)測試的比例會越來越大，且不斷往前端延伸，
社會分工本就是合久必分分久必合，大分工衍生了一些新的概念，專業(yè)的人做專業(yè)的事，驅(qū)使我們更聚焦于自己的業(yè)務(wù)本質(zhì)，比如IaaS（基礎(chǔ)設(shè)施即服務(wù)），運(yùn)維/環(huán)境管理、系統(tǒng)管理等會有專業(yè)的人去做，可以看看你是否就是這樣一個(gè)專職的人才；測試也是如此，比如TaaS（Test as a service），也是一個(gè)非常專業(yè)的領(lǐng)域，要求懂開發(fā)、懂業(yè)務(wù)、懂運(yùn)維。再有就是看公司的核心業(yè)務(wù)是什么，很多公司都不是專門做測試、運(yùn)維或工具的，我們應(yīng)該專注聚焦于公司主營業(yè)務(wù)。
Q45：如果組織中缺少專業(yè)的安全與審計(jì)人員，應(yīng)該如何去補(bǔ)足這方面的能力？
A：有些團(tuán)隊(duì)會把這個(gè)能力轉(zhuǎn)移給相關(guān)的SaaS服務(wù)平臺或第三方廠商。但平臺只能提供問題的展現(xiàn)，實(shí)際的安全審計(jì)處理還需要專人進(jìn)行。團(tuán)隊(duì)規(guī)模小時(shí)，可以通過業(yè)務(wù)上的分割和一些工具手段，盡量減輕相應(yīng)人員的壓力。
Q46：小團(tuán)隊(duì)安全管控得太嚴(yán)格了，對開發(fā)測試都會造成很多不便，也會影響問題排除追蹤，如何合理度量安全管控？
A：項(xiàng)目進(jìn)入正規(guī)化流程后會有很多環(huán)境：開發(fā)環(huán)境、測試環(huán)境、類生產(chǎn)環(huán)境、生產(chǎn)環(huán)境等，可以采用多環(huán)境不同程度安全管控的策略，比如在進(jìn)行開發(fā)環(huán)境測試時(shí)安全管控力度可以松一些，類生產(chǎn)環(huán)境測試時(shí)安全管控嚴(yán)格一些。
Q47：持續(xù)部署是不是可以做到熱部署，不暫停業(yè)務(wù)直接通過流水線進(jìn)行部署、提供用戶體驗(yàn)？
A：持續(xù)部署，每一次變化都是直接部署到生產(chǎn)環(huán)境里，但持續(xù)交付是有一定選擇性的，我們可以選擇性地把一些需要的東西部署到生產(chǎn)環(huán)境中。如果希望可以做到熱更新、熱部署，不暫停業(yè)務(wù)，可以通過持續(xù)部署的方式，直接使用流水線來實(shí)現(xiàn)。
Q48：K8s和Docker在應(yīng)用上有什么區(qū)別？
A：Docker是一種容器技術(shù)，在實(shí)踐中可以直接使用Docker進(jìn)行鏡像構(gòu)建等操作；K8s是進(jìn)行集群管理的技術(shù)手段，華為云DevCloud的幫助中心有一個(gè)鳳凰商城的實(shí)踐案例，和HCIP考試中的實(shí)驗(yàn)一樣，只是多了CI/CD的環(huán)節(jié)，在這個(gè)環(huán)節(jié)中就使用了K8s。
Q49：K8S 和 云原生是什么關(guān)系？
A：云原生是包括微服務(wù)、DevOps、容器化、持續(xù)交付等理念和方法，K8s只是一個(gè)集群管理的工具。
Q50：如果生產(chǎn)環(huán)境有等保要求，還有什么辦法實(shí)現(xiàn)持續(xù)部署嗎？
A：如果生產(chǎn)環(huán)境有等保要求的話，不太適合直接做持續(xù)部署，這時(shí)使用持續(xù)交付的方式更好一些，我們可以先決定應(yīng)該把哪些特性搬到生產(chǎn)環(huán)境上去。
Q51：新版程序修改了數(shù)據(jù)結(jié)構(gòu)，如何進(jìn)行應(yīng)用設(shè)計(jì)或部署方案，以應(yīng)對可能出現(xiàn)重大問題所需要的版本回退？
A：當(dāng)我們做一些比較大的修改時(shí)，一般會先部署到類生產(chǎn)環(huán)境上，檢視沒問題后才會通過灰度的方式同步到生產(chǎn)環(huán)境中。
Q52：我們已經(jīng)在做持續(xù)集成了，但持續(xù)交付和持續(xù)部署應(yīng)該怎么落地？
A：如果已經(jīng)在做持續(xù)集成，且做得比較成熟了的話，再往前落地持續(xù)交付和持續(xù)部署會相對容易。我們經(jīng)常說：持續(xù)交付只是持續(xù)集成往前的一小步，最后一公里或最后一米會比較痛苦。其實(shí)更多的痛點(diǎn)不在于技術(shù)層面，而是在于流程、制度層面，可能很難打穿部門墻、穿透企業(yè)管控類的要求，這些都未必是技術(shù)能解決的問題。
Q53：通過自動(dòng)化的方式實(shí)現(xiàn)持續(xù)集成和持續(xù)交付，中間會不會出現(xiàn)干擾而發(fā)生錯(cuò)誤？
A：一般來說，通過自動(dòng)化的方式實(shí)現(xiàn)持續(xù)集成和持續(xù)交付后，不是很容易發(fā)生錯(cuò)誤。錯(cuò)誤的出現(xiàn)可能是由于配置問題導(dǎo)致的，在配置相應(yīng)流水線時(shí)沒有配置好，比如參數(shù)出現(xiàn)問題，版本變得不一致等。除此之外還可能會有一個(gè)意外導(dǎo)致的問題，比如網(wǎng)絡(luò)故障等。
Q54：如果生產(chǎn)環(huán)境要求網(wǎng)絡(luò)隔離，還有什么辦法實(shí)現(xiàn)持續(xù)部署嗎？
A：如果生產(chǎn)環(huán)境要求網(wǎng)絡(luò)隔離的話，我們的流水線一般會搭建在公司內(nèi)部，也就是從提交代碼到構(gòu)建部署都會在公司內(nèi)部實(shí)現(xiàn)。這個(gè)過程中使用云上自動(dòng)化產(chǎn)品會少一些，因?yàn)槟壳按蟛糠衷粕蠘?gòu)建的工具都必須訪問公網(wǎng)才可以做到流水線的效果。
因此這種環(huán)境下，建議在本地搭建自動(dòng)化構(gòu)建流水線，或者購買可供私有化部署的工具。也可以在公網(wǎng)進(jìn)行代碼托管和構(gòu)建，只在部署的時(shí)候通過手工部署的方式將軟件包放到網(wǎng)絡(luò)隔離的機(jī)器上去。
Q55：Docker與虛擬機(jī)有何不同？
A：從上圖可以用比較清楚的看到Docker和虛擬機(jī)的異同。左邊的VM是虛擬機(jī)使用，container是容器使用，也就是我們說的Docker。兩邊都有server端和Host OS（虛擬機(jī)上的系統(tǒng)）。我們知道每個(gè)APP上都有Bin/libs，在Docker容器技術(shù)環(huán)境下，相同的APP可以共用同一個(gè)Bin/libs。大大節(jié)省了所占的資源空間。
Q56：到目前為止，已經(jīng)學(xué)習(xí)了很多DevOps的功能，但是有一個(gè)困惑，對于使用DevOps是零代碼，那么對于專業(yè)的開發(fā)人員來說，會不會慢慢降低他們的代碼開發(fā)積極性？
A：DevOps提供的零代碼是指在整個(gè)DevOps工具鏈中希望是零代碼的，通過將一切可自動(dòng)化的工具自動(dòng)化，將開發(fā)人員從各種維護(hù)工作中解放出來，使他們專注于開發(fā)。
Q57：在DevOps實(shí)踐中，環(huán)境差異的問題需要在哪個(gè)環(huán)節(jié)就開始著手來注意減少或者避免？
A：配置即代碼，在開發(fā)環(huán)節(jié)配置差異化的時(shí)候把環(huán)境差異等都配置進(jìn)去。
Q58：在DevOps轉(zhuǎn)型過程中，對組織和團(tuán)隊(duì)最有挑戰(zhàn)的有哪些？
A：我認(rèn)為DevOps轉(zhuǎn)型最難的有兩方面：一是如何爭取公司高層同意推動(dòng)DevOps轉(zhuǎn)型；二是如果請了教練/顧問協(xié)助DevOps轉(zhuǎn)型，顧問/教練走后，如何繼續(xù)保持和落地DevOps實(shí)踐。
Q59：小團(tuán)隊(duì)如果想要使用DevOps需要全員學(xué)習(xí)嗎，感覺每個(gè)人都學(xué)習(xí)時(shí)間成本挺高的，是否可以專人負(fù)責(zé)特定階段？
A：團(tuán)隊(duì)如果想要進(jìn)行DevOps轉(zhuǎn)型，需要專門有一個(gè)人把這些流程和工具研究明白，或者聘請一位外部DevOps顧問，再由整個(gè)專職人員或DevOps顧問在整個(gè)團(tuán)隊(duì)進(jìn)行培訓(xùn)和推動(dòng)。
A：先回憶一下四個(gè)閉環(huán)過程：
第一階段閉環(huán)：需求開發(fā)測試融合，將產(chǎn)品、研發(fā)、測試等角色融合，組建跨職能團(tuán)隊(duì)，提升產(chǎn)品交付價(jià)值與質(zhì)量；
第二階段閉環(huán)：開發(fā)測試融合，組建研發(fā)部門內(nèi)部的跨職能團(tuán)隊(duì)，提升自動(dòng)化水平，降低修復(fù)成本；
第三階段閉環(huán)：研發(fā)運(yùn)營一體化，實(shí)施產(chǎn)品自運(yùn)營、自運(yùn)維，打破了市場、研發(fā)、運(yùn)維部門之間的壁壘，更多角色融入交付鏈路，提升業(yè)務(wù)響應(yīng)力，建立價(jià)值反饋流；
第四階段閉環(huán)：目標(biāo)是逐步實(shí)現(xiàn)所有業(yè)務(wù)線都以跨職能團(tuán)隊(duì)為最小組織單元，實(shí)現(xiàn)業(yè)務(wù)敏捷性，持續(xù)提升企業(yè)的市場競爭力。
難點(diǎn)包括：
打通需求難。產(chǎn)品側(cè)和研發(fā)側(cè)溝通難。在傳統(tǒng)瀑布模式下產(chǎn)品和研發(fā)的溝通存在很多問題，比如需求溝通不明確等，引入敏捷的計(jì)劃會議，在計(jì)劃會議上做需求澄清，可以解決這一難題。
開發(fā)測試融合難。在很多公司這是兩個(gè)團(tuán)隊(duì)，還有些公司沒有測試的角色，要進(jìn)行人員和過程的融合比較困難。
研發(fā)運(yùn)營結(jié)合難。研發(fā)運(yùn)營一體化，運(yùn)營部分的內(nèi)容怎么跟開發(fā)結(jié)合也是一個(gè)難點(diǎn)。
組織結(jié)構(gòu)管理難。整個(gè)流程打通了，人員的管理和組織結(jié)構(gòu)的變動(dòng)方面也可能會存在問題。
以上難點(diǎn)需要根據(jù)公司具體情況來實(shí)踐和探索最佳解決方案。
華為云
專欄
閩公網(wǎng)安備 35010202001226號
