董璐 京東數(shù)科持續(xù)集成平臺(tái)研發(fā)負(fù)責(zé)人 重點(diǎn)關(guān)注于持續(xù)交付平臺(tái)的建設(shè)、敏捷項(xiàng)目管理的推廣、優(yōu)化研發(fā)過程與提升研發(fā)質(zhì)量等方面。
本文主要分為四部分：
DevOps平臺(tái)建設(shè)的目標(biāo)：目標(biāo)一致，在前進(jìn)的道路上遇到的困難和阻力就更加相似，針對(duì)這些共性的問題，我們更容易找到合適的解決方案；
建設(shè)和落地的困難：京東數(shù)科在建設(shè)和推廣DevOps平臺(tái)的過程中遇到了不少困難，大家可以結(jié)合自身的情況，看看這些困難能否引起你的共鳴；
迭代式建設(shè)，層層推進(jìn)；軟硬兼施，逐步落地：這兩部分內(nèi)容結(jié)合上面提到的問題，分享在建設(shè)和落地的過程中，我們分別選擇什么策略來(lái)解決這些問題。
一、DevOps平臺(tái)建設(shè)的目標(biāo)
我們?yōu)槭裁唇ㄔO(shè)DevOps平臺(tái)？因?yàn)轭I(lǐng)導(dǎo)覺得我們的工作進(jìn)度太慢，其實(shí)本質(zhì)上是市場(chǎng)認(rèn)為我們的進(jìn)度太慢。
引用杰克·韋爾奇的一句話，“如果外界的變化率超過了內(nèi)部的變化率，那末日就不遠(yuǎn)了”。這句話其實(shí)是在講，我們要去擁抱市場(chǎng)的變化，并且能夠先于市場(chǎng)變化而變化，那么我們才能夠有長(zhǎng)遠(yuǎn)發(fā)展，有資格和其他公司競(jìng)爭(zhēng)。
對(duì)我們IT行業(yè)其實(shí)也一樣，如果你的產(chǎn)品還沒上線，別人已經(jīng)占領(lǐng)了市場(chǎng)。那么你就失去了先機(jī)，所以這也提醒我們：迭代的速度得跟上。
下面列出了幾項(xiàng)我們建設(shè)DevOps時(shí)要關(guān)注的指標(biāo)：
提升質(zhì)量
提升效率
沉淀數(shù)據(jù)
輔助決策
1）提升質(zhì)量
提升質(zhì)量是首要的。而我們講到質(zhì)量，其實(shí)就是按照既定的要求去達(dá)成目標(biāo)，有要求就要有反饋。整個(gè)過程一定不是一個(gè)人、或者一個(gè)角色在參與，而是多個(gè)角色都參與其中、相互制約，才能有反饋，從而保證質(zhì)量。
我們講DevOps，不只是包含了研發(fā)和運(yùn)維的DevOps，而是說要把研發(fā)過程中各個(gè)角色的人都納入進(jìn)來(lái)，相互制約和影響，才能有效地保證研發(fā)質(zhì)量。
各個(gè)階段的人需要對(duì)自己的工作負(fù)責(zé)，保證符合要求，再由平臺(tái)來(lái)確認(rèn)是否按照要求進(jìn)行，然后從上一個(gè)節(jié)點(diǎn)反饋到下一個(gè)節(jié)點(diǎn)。
這樣的研發(fā)過程，才是一個(gè)保證質(zhì)量的研發(fā)過程。
2）提升效率
提升效率也是我們建設(shè)DevOps平臺(tái)的一個(gè)重要指標(biāo)。
① 降低溝通成本
我們把溝通的結(jié)果都落實(shí)到平臺(tái)上，以此來(lái)在線管理、共享信息，從而降低溝通成本。
這時(shí)有的同學(xué)會(huì)說，你這樣做不僅沒有降低溝通成本，反而還增加溝通成本了呀！我本來(lái)只需要一次線下溝通，只要發(fā)個(gè)會(huì)議紀(jì)要郵件就可以了，現(xiàn)在你還要我記錄到平臺(tái)上，根本沒有達(dá)到降低溝通成本的目的??！
大家想一下，第一次溝通當(dāng)然是成本。而如果中途出現(xiàn)問題，我們就需要二次確認(rèn)，那這是不是也屬于成本？功能上線了，出了Bug導(dǎo)致資損，那復(fù)盤算不算溝通成本？
如果按照剛才說的結(jié)論，將溝通的邏輯、設(shè)計(jì)、問題、風(fēng)險(xiǎn)都落實(shí)到平臺(tái)上，這些成本是不是被大大降低了？而且我們要復(fù)盤的時(shí)候，也會(huì)有據(jù)可依。
金融、保險(xiǎn)、健康行業(yè)還會(huì)有審計(jì)的環(huán)節(jié)，對(duì)研發(fā)過程有監(jiān)管，當(dāng)他們要求你提供相關(guān)材料的時(shí)候，是不是也算是成本？
而如果是在線管理的話，這個(gè)成本就會(huì)被節(jié)省掉。
② 增加質(zhì)量把控
我們做DevOps平臺(tái)，肯定會(huì)集成很多質(zhì)量管控的工具，比如自動(dòng)化測(cè)試、代碼掃描、漏洞檢查等等。這些工作直接在平臺(tái)上自動(dòng)化實(shí)現(xiàn)，就會(huì)直接節(jié)省大家的工作時(shí)間。
③ 降低研發(fā)風(fēng)險(xiǎn)
我們經(jīng)常會(huì)聽到一個(gè)笑話，說研發(fā)同學(xué)的工作內(nèi)容只有兩個(gè)，一個(gè)是寫B(tài)ug，另一個(gè)是改Bug，這說到底還是不能保障研發(fā)過程的質(zhì)量。
如果把一部分研發(fā)規(guī)范、驗(yàn)證、分支策略，甚至是架構(gòu)等要求都放到DevOps平臺(tái)上，且由平臺(tái)來(lái)實(shí)現(xiàn)，通過平臺(tái)來(lái)規(guī)避、降低研發(fā)風(fēng)險(xiǎn)，就可以盡可能地縮短大家寫B(tài)ug和改Bug的時(shí)間。
④ 提升自動(dòng)化水平
更遠(yuǎn)一點(diǎn)的目標(biāo)其實(shí)是提升數(shù)字化水平，既然我們已經(jīng)開始進(jìn)行DevOps平臺(tái)建設(shè)，那么就應(yīng)該讓機(jī)器去做它應(yīng)該做的。
自動(dòng)化越完善，效率就會(huì)越高，就越能夠節(jié)省人力和成本。
3）沉淀數(shù)據(jù)、輔助決策
整個(gè)研發(fā)過程都被管控起來(lái)了，是不是應(yīng)該從沉淀的數(shù)據(jù)中挖掘一下我們的研發(fā)瓶頸和短板了？這就是我想跟大家分享的沉淀數(shù)據(jù)和輔助決策。
下面我給大家列出幾個(gè)出發(fā)點(diǎn)，大家可以根據(jù)這些維度去復(fù)盤一下自己公司的研發(fā)過程是否有問題。如果有，那么哪里的問題最大？只有找到了問題，才能更好地解決問題。
我們要量化好這些數(shù)據(jù)并落盤固化下來(lái)，接著通過分析找到問題，才能根據(jù)這個(gè)根因來(lái)優(yōu)化研發(fā)過程，提升團(tuán)隊(duì)整體研發(fā)實(shí)力。
二、建設(shè)和落地的困難
這個(gè)問題是一個(gè)最為共性的問題。因?yàn)镈evOps平臺(tái)的建設(shè)，基本上都是業(yè)務(wù)迭代到一定階段時(shí)候的要求和產(chǎn)物。
沒有哪個(gè)公司會(huì)說，雖然我們的業(yè)務(wù)產(chǎn)品還沒開始，但是先建一套DevOps平臺(tái)吧！那這個(gè)公司就是還沒掙著錢就開始琢磨怎么花錢了，所以基本也沒有公司會(huì)這樣干。
歷史包袱主要有這四點(diǎn)：
代碼托管分散：公司越大，這個(gè)現(xiàn)象會(huì)越明顯。像京東數(shù)科，因?yàn)楹芏嗍召?gòu)而來(lái)的小公司和業(yè)務(wù)快速擴(kuò)張，導(dǎo)致早期代碼托管比較分散，很多部門或者子公司都會(huì)自己搭個(gè)Git或者Gitlab，然后就開始開發(fā)。這樣做的問題是，產(chǎn)品下線了卻都還不知道代碼在哪臺(tái)機(jī)器上；
上線無(wú)管控：無(wú)管控指的是可以自由上線。如果你突然讓他上DevOps平臺(tái)，有了工具，但他反而覺得還不如自己上服務(wù)器上折騰一下，發(fā)布一個(gè)版本更為方便和自由；
研發(fā)過程不持續(xù)：很多節(jié)點(diǎn)看上去都挺自動(dòng)化的，但是真要把研發(fā)過程用到的工具都羅列出來(lái)，就會(huì)發(fā)現(xiàn)工具極其繁雜且不統(tǒng)一。這邊測(cè)試過程用著禪道，那邊用著Bugzilla，還有用Excel的；上線工具有的人直接用jenkins發(fā)布，有的人寫一個(gè)腳本發(fā)布，還有的自己上傳，你們想想公司里有沒有這種現(xiàn)象；
源碼不可追溯：平臺(tái)建設(shè)到一定階段，找個(gè)項(xiàng)目來(lái)試用，來(lái)遷移吧！結(jié)果源碼找不到了，也說不清楚現(xiàn)在線上正在跑的項(xiàng)目到底對(duì)應(yīng)哪個(gè)tag。
剛才說到的這些問題，在京東數(shù)科早期都有遇到過，都是真事兒！
在建設(shè)過程中，我們很容易進(jìn)入一個(gè)誤區(qū)——你會(huì)被研發(fā)和運(yùn)維牽著鼻子走。
一開始我們會(huì)感覺研發(fā)、測(cè)試、運(yùn)維的積極性特別高，后面就會(huì)發(fā)現(xiàn)我們做得越多，他們的需求也就越多，而且滿意度卻越來(lái)越低。做到最后，DevOps平臺(tái)變成了研發(fā)工具倉(cāng)庫(kù)和集合，大家在平臺(tái)上也只是使用工具。
那么平臺(tái)的建設(shè)工作就變成了多個(gè)工具的集成工作，這個(gè)時(shí)候做得再多也只是在打通工具之間的聯(lián)系，并沒有在做平臺(tái)建設(shè)。
另外就是缺乏規(guī)則，沒有沉淀，導(dǎo)致這個(gè)平臺(tái)就算做得再久也會(huì)沒有價(jià)值。原本你要做一個(gè)游戲規(guī)則的制定者，制定統(tǒng)一標(biāo)準(zhǔn)讓大家根據(jù)統(tǒng)一的玩法來(lái)工作。
但是最后卻發(fā)現(xiàn)，你制定的游戲規(guī)則就是沒有規(guī)則，最后也沒有沉淀出有價(jià)值的數(shù)據(jù)和標(biāo)準(zhǔn)。久而久之，DevOps平臺(tái)的建設(shè)就爛尾了，也無(wú)法再繼續(xù)進(jìn)行下去。
在落地過程中會(huì)發(fā)現(xiàn)更多的問題：
談到落地，首先當(dāng)然是要跟領(lǐng)導(dǎo)匯報(bào)工作，像是“平臺(tái)要上線啦！我們做了多少功能，做出來(lái)的價(jià)值有多高！”
然后，領(lǐng)導(dǎo)就會(huì)在你畫的這個(gè)餅上提出想法和要求，比如我們經(jīng)常會(huì)遇到的，領(lǐng)導(dǎo)說：“我想知道咱們研發(fā)團(tuán)隊(duì)每天都提交多少代碼？誰(shuí)提交的最多？哪些項(xiàng)目進(jìn)展的比較快，質(zhì)量比較好？源碼和需求有沒有關(guān)聯(lián)性？我知道他們?cè)趯懘a，那他們寫的代碼和我這個(gè)項(xiàng)目進(jìn)展有沒有關(guān)呀？”
到這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)，其實(shí)自己在做的主要內(nèi)容是用戶當(dāng)前關(guān)注的問題，但卻不是領(lǐng)導(dǎo)關(guān)注的主要內(nèi)容。
還有就是項(xiàng)目遷移，我們將項(xiàng)目遷移到DevOps平臺(tái)上肯定會(huì)產(chǎn)生成本，因?yàn)檫@需要研發(fā)團(tuán)隊(duì)對(duì)研發(fā)的過程做出改變，所以說研發(fā)團(tuán)隊(duì)的認(rèn)可也是我們的阻力之一。
之前大家都是散養(yǎng)，現(xiàn)在要制定規(guī)則，大家多多少少都會(huì)有抵觸的情緒。之前隨便拉一個(gè)代碼庫(kù)就能干的事情，現(xiàn)在卻要走流程，走立項(xiàng)。
但是規(guī)則制定得太松散，就會(huì)發(fā)現(xiàn)平臺(tái)根本沒有規(guī)則可言；規(guī)則制定得太嚴(yán)謹(jǐn)，就會(huì)發(fā)現(xiàn)平臺(tái)上沒有用戶。上面列舉的四項(xiàng)內(nèi)容是一般的DevOps平臺(tái)都會(huì)有的功能，但是在散養(yǎng)階段卻都是沒有的。
剛才說的這些沖突會(huì)在平臺(tái)落地的時(shí)候都爆發(fā)出來(lái)，那么我們能夠采取了怎樣的策略和手段呢？
三、迭代式建設(shè)，層層推進(jìn)
上面提到，我們?cè)诮ㄔO(shè)的過程中會(huì)不斷給產(chǎn)研測(cè)和運(yùn)維人員打磨工具。這樣的DevOps平臺(tái)，真的是我們要建設(shè)的DevOps平臺(tái)嗎？
DevOps雖然不是業(yè)務(wù)平臺(tái)，但也具備全局的產(chǎn)品視角，不然就會(huì)出現(xiàn)上面說的問題。
所以首先要對(duì)整個(gè)研發(fā)過程做一個(gè)抽象梳理，然后逐層遞進(jìn)地完成平臺(tái)建設(shè)。
DevOps平臺(tái)是要把研發(fā)過程中參與的人員都納入進(jìn)去：產(chǎn)品人員提出需求，然后組會(huì)確認(rèn)可行性和排期，接著交給研發(fā)人員進(jìn)行開發(fā)迭代，測(cè)試人員通過測(cè)試后，平臺(tái)正式發(fā)布上線。這是研發(fā)DevOps平臺(tái)的主流程，所有的工作都要在主流程上進(jìn)行，只是不同團(tuán)隊(duì)做的是不同節(jié)點(diǎn)的工作。
主流程也需要明確下來(lái)，我們要做的是一款產(chǎn)品，也可以稱之為業(yè)務(wù)產(chǎn)品。當(dāng)然整個(gè)建設(shè)過程也是一個(gè)持續(xù)迭代、層層建設(shè)的過程。
1）工具化
工具化也適合大多數(shù)的公司，可以先用各種各樣開源的工具支撐起研發(fā)、測(cè)試和運(yùn)維的需求。不需要抵觸工具化，因?yàn)橛械臅r(shí)候我們的能力有限，完全拋棄工具并不現(xiàn)實(shí)，所以我們要做的其實(shí)是充分利用工具。
想要利用多種多樣的工具，在選擇的時(shí)候最好就選擇比較大眾的工具，太小眾的最好不要用。因?yàn)槲覀円獮楹罄m(xù)的系統(tǒng)化和平臺(tái)化做準(zhǔn)備，不能自己給自己挖坑。
2）系統(tǒng)化
工具化是為了解決眼前的問題，而系統(tǒng)化是為了發(fā)展。我們要對(duì)工具做關(guān)聯(lián)，同時(shí)也要注意關(guān)聯(lián)的過程中不要忘記我們是在做產(chǎn)品，所以一定要依據(jù)產(chǎn)品的設(shè)計(jì)來(lái)做工具集成。
系統(tǒng)化的目的是打通各個(gè)工具的環(huán)節(jié)，而用大眾化的工具支撐平臺(tái)在這里就能凸顯出它的意義了。
工具太小眾，很可能出現(xiàn)問題但是你卻無(wú)法解決。可能要集成的時(shí)候連接口都沒有，使用小眾工具，在系統(tǒng)化的道路上就處處是坑。
3）平臺(tái)化
DevOps做到最后，還是要靠真技術(shù)。如果光靠工具進(jìn)行組裝，局限性就會(huì)很大。是時(shí)候該替換掉的中間件和工具組件就要替換掉，該自研的就要自研，一定不能被工具局限住，我們的最終目標(biāo)是讓每個(gè)環(huán)節(jié)都協(xié)作起來(lái)。
1）系統(tǒng)化
系統(tǒng)化做的是，打通工具集，為每個(gè)環(huán)境挑選主要的工具，以此來(lái)完成不同階段的工具統(tǒng)一。
還是以Bug管理為例，
我們同時(shí)使用禪道、Bugzilla、JIRA不行嗎？行！
JIRA一定比禪道好嗎？禪道一定比Bugzilla好嗎？不一定！
這里需要進(jìn)行抉擇，而這個(gè)抉擇需要由DevOps平臺(tái)建設(shè)方來(lái)制定。我們只有先統(tǒng)一好工具，才能把精力放在更有價(jià)值的地方。如果數(shù)據(jù)分散在不同的地方，下一步需要推進(jìn)的時(shí)候要采集數(shù)據(jù)、改變用戶習(xí)慣就會(huì)非常困難。
系統(tǒng)化需要同時(shí)考慮各個(gè)階段工具之間的對(duì)接。松散在不同地方的工具是沒有靈魂和凝聚力的，久而久之很可能還會(huì)被打散。所以我們要把工具打通，通過接口、文件、甚至是數(shù)據(jù)庫(kù)層面，想盡一切辦法讓整個(gè)過程轉(zhuǎn)起來(lái)，以完成系統(tǒng)化的轉(zhuǎn)變。
2）平臺(tái)化
平臺(tái)化的過程中工具并不那么重要，重要的是信息流。因?yàn)檫@個(gè)時(shí)候工具組件已經(jīng)成形，需要做的是通過替換或者自研去頂替已經(jīng)被淘汰的工具。剩下的工作是過程優(yōu)化，要讓整個(gè)研發(fā)過程更加平臺(tái)，各個(gè)環(huán)節(jié)之間都有聯(lián)系，并通過平臺(tái)沉淀的數(shù)據(jù)為我們提供價(jià)值。
我們建設(shè)DevOps平臺(tái)的目的是什么？是為了保證質(zhì)量，提升效率，價(jià)值反饋！DevOps平臺(tái)建設(shè)到最后還是要發(fā)揮它最大的價(jià)值，只有整個(gè)研發(fā)過程在你手上可控，你才能更好地分析、找到研發(fā)過程的優(yōu)化點(diǎn)，以此來(lái)改善過程。
四、軟硬兼施，逐步落地
1）制定游戲規(guī)則
DevOps平臺(tái)的建設(shè)過程，也是研發(fā)規(guī)范的制定過程。之前對(duì)大家來(lái)說玩法比較自由，但是現(xiàn)在上了平臺(tái)就不能再隨便亂跑了。
首先，平臺(tái)制定了游戲規(guī)則，就需要在規(guī)則下進(jìn)行研發(fā)，但很多規(guī)范需要宣貫，比如說：
分支策略問題：我們要給用戶講明白，這個(gè)分支的策略是怎樣的策略？為什么這樣做？有什么好處？應(yīng)該怎么應(yīng)用？
質(zhì)量卡點(diǎn)要求：質(zhì)量檢查包括什么內(nèi)容？分別會(huì)在什么時(shí)間點(diǎn)采集哪些質(zhì)量指標(biāo)數(shù)據(jù)？分析的時(shí)候依據(jù)又是什么？
安全校驗(yàn)規(guī)則：規(guī)則包括哪些？遇到問題要怎樣處理、優(yōu)化工程才能滿足這些指定好的規(guī)則？
2）落實(shí)研發(fā)過程
落實(shí)研發(fā)流程也可以叫實(shí)操培訓(xùn)，和用戶明確應(yīng)該如何使用平臺(tái)，誰(shuí)應(yīng)該干什么，每一個(gè)環(huán)境又有什么任務(wù)等等，這個(gè)落實(shí)和培訓(xùn)的流程是我們作為DevOps平臺(tái)建設(shè)者的責(zé)任。
不像新聞?lì)?、電商類的APP，大家用一兩次就能熟悉流程和操作，這種管理支撐類的平臺(tái)有一定門檻，DevOps平臺(tái)甚至要復(fù)雜得多。
所以要明白的是，我們自身有責(zé)任和義務(wù)告訴用戶怎么使用平臺(tái)，每個(gè)節(jié)點(diǎn)上他們應(yīng)該做什么。
我們的義務(wù)明確了，那么用戶的義務(wù)是不是也要跟著落實(shí)了呢？那當(dāng)然不是我們?nèi)ヂ鋵?shí)，而是領(lǐng)導(dǎo)幫忙去提點(diǎn)提點(diǎn)。
誰(shuí)都想不受約束，都想自由地去干自己喜歡干的事情，但是我們要對(duì)項(xiàng)目負(fù)責(zé)，要對(duì)公司負(fù)責(zé)。我們承認(rèn)這種改變會(huì)給用戶帶來(lái)成本，但是這個(gè)成本是必須的，不然等在平臺(tái)發(fā)展到一定的規(guī)模之后再去做規(guī)定的事情就會(huì)產(chǎn)生更大的成本，到那個(gè)時(shí)候再后悔就晚了！
鐵腕政策應(yīng)該怎么做？
限期遷移，強(qiáng)制推廣：注意，這項(xiàng)措施一定是等平臺(tái)具有一定成熟度的時(shí)候再去做，還沒有穩(wěn)定的時(shí)候，不要盲目推進(jìn)，不然就會(huì)丟失團(tuán)隊(duì)管理者的信任。假設(shè)大家都很積極地幫你去推進(jìn)，最后你卻掉鏈子，那么后面的遷移之路會(huì)越來(lái)越難；
規(guī)范化調(diào)整，償還技術(shù)債：這是京東數(shù)科項(xiàng)目遷移的必經(jīng)之路，之前存在的很多問題都要調(diào)整。舉個(gè)最明顯的例子，很多項(xiàng)目依賴快照發(fā)布上線，但是快照很多時(shí)候都不穩(wěn)定，如果快照版本更新遇上發(fā)布上線，這就能體現(xiàn)出這個(gè)問題的嚴(yán)重性和普遍性了，所以對(duì)待這個(gè)問題決不能手軟；
全面檢查，做好質(zhì)量管控：在項(xiàng)目遷移過來(lái)的時(shí)候，一定要對(duì)項(xiàng)目進(jìn)行強(qiáng)制檢查，不符合的地方一定要進(jìn)行調(diào)整，并且在起點(diǎn)就控制好，這樣才不至于越落地，標(biāo)準(zhǔn)越低；
用數(shù)據(jù)說話，納入績(jī)效考核：和績(jī)效掛鉤也是迫不得已的做法，在國(guó)企、事業(yè)單位用的最多，而互聯(lián)網(wǎng)公司用的還比較少。但是這不失為一個(gè)比較好的措施，只是不到迫不得已還是不要強(qiáng)制納入績(jī)效，畢竟DevOps建設(shè)團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)都是一家人，一家親。
最后還是要強(qiáng)調(diào)，樹立榜樣很重要。無(wú)論你的DevOps平臺(tái)是非常好還是一般，都需要有試點(diǎn)團(tuán)隊(duì)的支持，我們篩選出具有代表性的項(xiàng)目團(tuán)隊(duì)并以此作為榜樣。當(dāng)然這個(gè)團(tuán)隊(duì)需要比較愿意配合并且樂意去接受和改變，對(duì)于這樣的團(tuán)隊(duì)我們要重點(diǎn)照顧，甚至親力親為幫助他們完成項(xiàng)目遷移。
一旦你有了成功案例，故事就好講了，去別的團(tuán)隊(duì)推廣和遷移都會(huì)容易很多。無(wú)論是什么階段，能有一個(gè)標(biāo)桿樣板，都可以起到由點(diǎn)及面，逐步落地的作用。
Q & A
Q1：怎么實(shí)現(xiàn)一鍵創(chuàng)建開發(fā)測(cè)試環(huán)境？
A：
建議首先標(biāo)準(zhǔn)化部署的方式，如部署路徑，日志輸出路徑，啟動(dòng)用戶等；
先滿足一類工程的部署，比如先考慮Tomcat部署，然后再擴(kuò)展到其他類別的部署；
先使用開源組件，如Jenkins，Ansible，通過接口調(diào)用來(lái)實(shí)現(xiàn)平臺(tái)對(duì)接；
管理服務(wù)之間的依賴，可以一次性部署多個(gè)服務(wù)。
Q2：項(xiàng)目團(tuán)隊(duì)才用的gitlab，想問下如何從0開始搭建DevOps平臺(tái)？
A：從0開始的話還是建議從開源軟件開始，優(yōu)先考慮代碼托管、自動(dòng)化構(gòu)建、部署，gitlab+jenkins是最快的方式。
Q3：京東的mobile端如何做DevOps的？
A：移動(dòng)端的DevOps還是比較復(fù)雜的，對(duì)于組件化和非組件化的工程，研發(fā)過程還是不同的，不過整體主階段是類似的，都是從研發(fā)、測(cè)試、到灰度，然后到發(fā)版，涉及到的功能點(diǎn)會(huì)比較多。
比如安裝包的加固和簽名、渠道的管理、IOS的發(fā)版還會(huì)涉及到證書的管理，是一個(gè)比較復(fù)雜的過程，移動(dòng)端持續(xù)集成的建設(shè)也是一個(gè)逐步建設(shè)的過程。
Q4：bug管理也是DevOps平臺(tái)開發(fā)？
A：Bug的管理是為了持續(xù)集成的過程更完整，如果當(dāng)前有其他更緊急的問題要處理，那么可以不考慮Bug管理。如果想讓整個(gè)研發(fā)過程在DevOps平臺(tái)上一站式解決，不僅是Bug，像代碼掃描的缺陷，掃描規(guī)則、安全規(guī)則、測(cè)試用例、自動(dòng)化測(cè)試腳本等等都應(yīng)該是要考慮的范疇，總之，只要是能讓研發(fā)團(tuán)隊(duì)更便捷的完成研發(fā)工作，都是我們要關(guān)注的內(nèi)容。
Q5：最難纏不配合的部門是怎樣的，如何解決他，有沒有哪些業(yè)務(wù)是放棄接入？
A：我個(gè)人認(rèn)為還是不要太過于糾結(jié)，有一些項(xiàng)目不是靠我們努力就可以接入的，偶爾也會(huì)有歷史包袱過重，或者確實(shí)不適應(yīng)平臺(tái)的項(xiàng)目存在，可以考慮2/8原則。如果你為了以項(xiàng)目付出的努力值得你這樣做，可以去努力，如果能幫助更多更有價(jià)值的項(xiàng)目，我建議可以先放一放。
Q6：Android+IOS如何在一起持續(xù)集成？
A：持續(xù)集成的過程是相同的，不同的是編譯機(jī)的選擇，打包的方式、研發(fā)過程、測(cè)試過程、發(fā)布過程大體還是相似的。對(duì)于不同的部分用不同的路線來(lái)處理，是可以在一起持續(xù)集成的，畢竟從產(chǎn)品經(jīng)理的角度來(lái)看，提出的一個(gè)需求在Android端和IOS端都是要上線的，可以合并處理。
Q7：接口自動(dòng)化測(cè)試依賴的數(shù)據(jù)該如何生成？尤其上游依賴環(huán)節(jié)比較多的情況下？
A：要達(dá)到單個(gè)服務(wù)的自動(dòng)化測(cè)試數(shù)據(jù)自動(dòng)生成的目標(biāo)，對(duì)于依賴服務(wù)比較多的情況下，各個(gè)服務(wù)最好能夠提供自己的聯(lián)調(diào)環(huán)境。比如我是A服務(wù)的研發(fā)人員，我依賴B，最好讓B能夠提供一個(gè)聯(lián)調(diào)環(huán)境，或者B的研發(fā)人員可以通過DevOps平臺(tái)很快給你搭建B的服務(wù)，生成一個(gè)臨時(shí)的聯(lián)調(diào)環(huán)境，讓B的研發(fā)負(fù)責(zé)測(cè)試數(shù)據(jù)。
讓人員各司其職，對(duì)于復(fù)雜的系統(tǒng)是不可能靠一個(gè)服務(wù)的研發(fā)人員處理所有的測(cè)試數(shù)據(jù)的。
Q8：生產(chǎn)環(huán)境，做了哪些發(fā)布，灰度發(fā)布怎么做？
A：生產(chǎn)環(huán)境至少還是要準(zhǔn)備兩個(gè)，一個(gè)是預(yù)發(fā)，一個(gè)是生產(chǎn)。預(yù)發(fā)環(huán)境使用生產(chǎn)環(huán)境的數(shù)據(jù)、網(wǎng)絡(luò)，但是流量入口是獨(dú)立的，目的就是在新的功能要發(fā)布生產(chǎn)的時(shí)候，先發(fā)布到預(yù)發(fā)環(huán)境，然后通過特定的入口進(jìn)行預(yù)發(fā)環(huán)境驗(yàn)證，沒有問題再升級(jí)生產(chǎn)環(huán)境，否則對(duì)預(yù)發(fā)環(huán)境進(jìn)行回滾。
灰度發(fā)布在移動(dòng)端用的比較多，比如對(duì)某一特定區(qū)域的用戶進(jìn)行灰度測(cè)試，北京的用戶可以升級(jí)客戶端到最新版本，先看市場(chǎng)的反應(yīng)，或者對(duì)某一個(gè)渠道的用戶進(jìn)行灰度測(cè)試，比如我們Android從360和華為商店上下載的版本就不同，達(dá)到部分灰度的效果。
Q9：多團(tuán)隊(duì)，多分支并行開發(fā)，到底怎么做？
A：這里涉及到分支策略的處理，多分支并行開發(fā)其實(shí)就是拉取多個(gè)分支進(jìn)行不同功能的開發(fā)，也可以進(jìn)行多分支并行測(cè)試，但是最終要上線時(shí)，只有一個(gè)分支能進(jìn)入上線，上線完成后，會(huì)升級(jí)項(xiàng)目基線，然后其他分支要將基線Merge到當(dāng)前分支重新進(jìn)入測(cè)試上線流程?；蛘呖梢远喾种Р⑿虚_發(fā)，使用集成分支進(jìn)行測(cè)試，然后一起上線，只要是在分支策略的約束下，能夠保證基線穩(wěn)定，過程如何處理都是可以靈活設(shè)計(jì)的。
Q10：規(guī)則檢查用什么工具呢？
A：具體還要看檢查什么規(guī)則，比如：
檢查是否依賴快照包，可以通過maven的enforce插件完成；
檢查是否有依賴包版本沖突，可以通過maven獲取依賴樹，然后進(jìn)行對(duì)比；
檢查是否符合分支策略要求，可以對(duì)接gitlab或者自研的代碼托管平臺(tái)，通過對(duì)比分支版本來(lái)完成。
Q11：持續(xù)集成平臺(tái)生產(chǎn)平臺(tái)和開發(fā)測(cè)試要分開嗎？
A：服務(wù)端可能是分開的，但是對(duì)于用戶來(lái)講，作為一個(gè)平臺(tái)來(lái)使用還是比較方便的，很多公司因?yàn)榫W(wǎng)絡(luò)要求，開發(fā)環(huán)境、測(cè)試環(huán)境和生產(chǎn)環(huán)境是網(wǎng)絡(luò)隔離的，我們可以在不同的網(wǎng)絡(luò)環(huán)境下搭建不同的服務(wù)，這樣在辦公環(huán)境訪問DevOps可以同時(shí)操作不同環(huán)境的構(gòu)建部署，完成研發(fā)過程。
Q12：如果有很多服務(wù) ，是應(yīng)該給每個(gè)服務(wù)都設(shè)計(jì)一個(gè)pipeline 還是所有服務(wù)公用一個(gè)流水線？
A：個(gè)人建議還是每個(gè)服務(wù)都有自己的pipeline，甚至一個(gè)服務(wù)可以有多個(gè)pipeline，每個(gè)pipeline負(fù)責(zé)不同的功能，如提供代碼掃描、自動(dòng)執(zhí)行自動(dòng)化測(cè)試的，自動(dòng)更新測(cè)試環(huán)境的，甚至還有發(fā)布部署的，在不同的時(shí)間點(diǎn)，在不同的情況下觸發(fā)不同流水線的運(yùn)行。
聯(lián)系客服
