自動(dòng)化工具對(duì)中國(guó)DevOps實(shí)踐的影響*

黃 璜,張 賀,2,邵 棟,2

1(南京大學(xué) 軟件學(xué)院,江蘇 南京 210093)

2(計(jì)算機(jī)軟件新技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué)),江蘇 南京 210023)

1 研究背景

社會(huì)經(jīng)濟(jì)的不斷發(fā)展使得用戶需求的多樣性以及市場(chǎng)競(jìng)爭(zhēng)的激烈性不斷增強(qiáng),如何快速完成軟件的開(kāi)發(fā)運(yùn)營(yíng)從而縮短實(shí)現(xiàn)軟件的商業(yè)價(jià)值的時(shí)間成為所有軟件企業(yè)組織在應(yīng)對(duì)軟件行業(yè)發(fā)展的挑戰(zhàn)時(shí)所需要考慮的重要問(wèn)題.為了應(yīng)對(duì)這個(gè)問(wèn)題,從21 世紀(jì)初開(kāi)始,敏捷原則和精益方法在軟件開(kāi)發(fā)實(shí)踐中不斷得到普及,Scrum和極限編程(extreme programming,簡(jiǎn)稱XP)是其中最典型的兩種方法.而隨著敏捷原則在開(kāi)發(fā)中的迅速應(yīng)用,面向經(jīng)驗(yàn)性的傳統(tǒng)運(yùn)維與它的矛盾逐漸加深,如何解決這一矛盾成為了一個(gè)新的研究話題.John 和Paul 在“10+Deploys Per Day:Dev and Ops Cooperation at Flickr”的演講中總結(jié)了Dev 和Ops 的不同觀點(diǎn)和思維方式,提出以自動(dòng)化基礎(chǔ)設(shè)施與共享版本控制為核心的解決方案,并闡述了以信任與尊重為核心的早期DevOps 文化[1].

然而,DevOps 發(fā)展了近10 年,至今仍缺乏對(duì)其清晰和統(tǒng)一的認(rèn)知.Andrej 等人認(rèn)為,DevOps 是一種組織方法,強(qiáng)調(diào)在軟件開(kāi)發(fā)組織中的團(tuán)隊(duì),特別是開(kāi)發(fā)與運(yùn)維團(tuán)隊(duì)內(nèi)部或者之間的情感共鳴和跨職能協(xié)作,以此來(lái)達(dá)到快速交付和響應(yīng)變化[2].Matej 等人認(rèn)為,DevOps 包含了一系列能夠縮短軟件設(shè)計(jì)變化的、可控的、可操作的軟件工程策略[3].Ramtin 等人也對(duì)學(xué)術(shù)界和業(yè)界出現(xiàn)的DevOps 相關(guān)的概念進(jìn)行了研究[4,5].因?yàn)闆](méi)有官方定義,所以每個(gè)人都可以根據(jù)自己的想法賦予DevOps 一個(gè)定義,也就不斷地為DevOps 增加了新概念、新實(shí)踐和新工具.

從發(fā)展程度上看,Puppet Labs 在“2017 年DevOps 報(bào)告”[6]中指出,高性能的DevOps 團(tuán)隊(duì)在代碼生成量與穩(wěn)定性方面優(yōu)于其他團(tuán)隊(duì).由于社會(huì)環(huán)境對(duì)人有巨大的影響[7,8],DevOps 實(shí)踐在中國(guó)環(huán)境下會(huì)與國(guó)際范圍內(nèi)有一定的差異,南京大學(xué)在2018 中國(guó)DevOps 年度報(bào)告[9]中提出了準(zhǔn)高性能團(tuán)隊(duì)的概念,認(rèn)為中國(guó)在DevOps 團(tuán)隊(duì)建設(shè)方面,大部分的團(tuán)隊(duì)還達(dá)不到Puppet Labs 所定義的高性能團(tuán)隊(duì)的標(biāo)準(zhǔn),而且國(guó)內(nèi)的準(zhǔn)高性能團(tuán)隊(duì)主要進(jìn)行的是主干開(kāi)發(fā)、版本控制、測(cè)試方面的實(shí)踐,更多的是使用工具幫助構(gòu)建開(kāi)發(fā)環(huán)境、實(shí)現(xiàn)自動(dòng)化部署和監(jiān)控軟件系統(tǒng)的健康狀況,對(duì)于計(jì)劃、持續(xù)集成和持續(xù)反饋階段的工具關(guān)注較少.

DevOps 是對(duì)傳統(tǒng)軟件開(kāi)發(fā)實(shí)踐的一場(chǎng)變革,其中,自動(dòng)化處于關(guān)鍵位置.因?yàn)槎讨芷诘母哔|(zhì)量交付需要高度的自動(dòng)化,而且快速獲取反饋的關(guān)鍵也是自動(dòng)化;工具是實(shí)現(xiàn)自動(dòng)化的基礎(chǔ),在DevOps 知識(shí)體系的5 個(gè)層面中(如圖1 所示),工具處于最底層,是DevOps 的基石[10-12],所以,對(duì)于DevOps 實(shí)踐中的自動(dòng)化支持工具的研究也在不斷地增多.而對(duì)于DevOps 自動(dòng)化支持工具的分類已經(jīng)有了很多成熟的模型,Xebialabs 公司提供了DevOps工具周期表,StackOverdrive 公司則提供了DevOps 工具全景圖.在學(xué)術(shù)界中,Vaasanthi 等人提出了基于數(shù)據(jù)挖掘技術(shù)的對(duì)DevOps 工具進(jìn)行分類的新方法[13],Kersten 則對(duì)DevOps 自動(dòng)化支持工具的爆炸性增長(zhǎng)問(wèn)題提出了自己的見(jiàn)解[14],Farcic 則對(duì)DevOps 工具集中的持續(xù)集成與持續(xù)部署部分保持了關(guān)注[15,16].

Fig.1 Knowledge system of DevOps圖1 DevOps 知識(shí)體系

隨著DevOps 的不斷發(fā)展,DevOps 觀念不斷獲得認(rèn)同,支持DevOps 的自動(dòng)化工具不斷增多.雖然DevOps不僅僅只會(huì)停留在工具層面,但是工具之于整個(gè) DevOps 是不可或缺甚至具有決定性作用的一部分.研究DevOps 中的自動(dòng)化工具,也會(huì)進(jìn)一步推動(dòng)DevOps 的全面發(fā)展.

本文第1 節(jié)介紹研究背景,闡述DevOps 文化以及DevOps 在中國(guó)的發(fā)展和DevOps 與自動(dòng)化支持工具的關(guān)系.第2 節(jié)介紹研究方法,闡明3 個(gè)研究問(wèn)題以及針對(duì)這3 個(gè)研究問(wèn)題使用的不同的研究方法和研究過(guò)程.第3 節(jié)對(duì)獲取到的數(shù)據(jù)進(jìn)行定性分析,通過(guò)系統(tǒng)化文獻(xiàn)評(píng)價(jià)獲得學(xué)術(shù)界最關(guān)注的一些DevOps 自動(dòng)化支持工具,通過(guò)灰色文獻(xiàn)評(píng)價(jià)獲得這些自動(dòng)化支持工具在實(shí)踐中存在的3 個(gè)層次的問(wèn)題,最后通過(guò)訪談得出企業(yè)進(jìn)行DevOps 轉(zhuǎn)型的一個(gè)范例以及對(duì)DevOps 自動(dòng)化工具的一些建議.第4 節(jié)對(duì)研究的成果和不足進(jìn)行討論.第5 節(jié)對(duì)研究進(jìn)行總結(jié)和回顧.

2 研究方法

2.1 研究問(wèn)題

DevOps 倡導(dǎo)的理念需要自動(dòng)化給予支持,尤其是在開(kāi)發(fā)和運(yùn)維方面.認(rèn)識(shí)DevOps 自動(dòng)化支持工具的現(xiàn)狀,理解現(xiàn)有自動(dòng)化工具在中國(guó)環(huán)境下DevOps 實(shí)踐中的問(wèn)題,能夠更好地促進(jìn)DevOps 在中國(guó)的發(fā)展,本文提出以下研究問(wèn)題.

研究問(wèn)題1:目前DevOps 實(shí)踐中有哪些自動(dòng)化工具?

該問(wèn)題旨在收集目前DevOps 實(shí)踐中的自動(dòng)化工具,形成一個(gè)工具集合,并為后續(xù)研究提供參考.為了回答這個(gè)問(wèn)題,本文從學(xué)術(shù)文獻(xiàn)中收集證據(jù),從學(xué)術(shù)文獻(xiàn)中搜索、篩選并統(tǒng)計(jì)DevOps 實(shí)踐中的自動(dòng)化工具.

研究問(wèn)題2:目前的自動(dòng)化工具在中國(guó)的DevOps 實(shí)踐中存在哪些問(wèn)題?

該問(wèn)題旨在找出中國(guó)的DevOps 實(shí)踐中自動(dòng)化工具存在的問(wèn)題.為了回答這個(gè)問(wèn)題,本文在學(xué)術(shù)文獻(xiàn)證據(jù)的基礎(chǔ)上,從部分中文博客論壇中收集灰色文獻(xiàn),進(jìn)而從這些證據(jù)中抽取數(shù)據(jù)進(jìn)行定性分析.

研究問(wèn)題3:自動(dòng)化工具在中國(guó)的DevOps 實(shí)踐中存在的問(wèn)題有哪些解決辦法?

該問(wèn)題旨在給研究問(wèn)題2 中的問(wèn)題提出解決方案.為了回答這個(gè)問(wèn)題,本文邀請(qǐng)國(guó)內(nèi)部分DevOps 研究者、DevOps 企業(yè)從業(yè)人員和DevOps 咨詢師進(jìn)行訪談,對(duì)訪談內(nèi)容抽取數(shù)據(jù)后進(jìn)行定性分析.

2.2 研究方法

DevOps 文化誕生于技術(shù)社區(qū),隨即廣泛地應(yīng)用到軟件企業(yè)組織中,近些年來(lái),學(xué)術(shù)界對(duì)它的關(guān)注也逐漸增強(qiáng),但是,相關(guān)的研究并不豐富,所以,我們除了需要學(xué)術(shù)文獻(xiàn),還需要使用博客等材料輔助分析.本文提出的各研究方法間的關(guān)系如圖2 所示,首先,采用系統(tǒng)化文獻(xiàn)評(píng)價(jià)(systematic literature review,簡(jiǎn)稱SLR)對(duì)目前學(xué)術(shù)界和工業(yè)界都認(rèn)可的DevOps 實(shí)踐中的自動(dòng)化工具加以集合,然后,通過(guò)灰色文獻(xiàn)評(píng)價(jià)(gray literature review,簡(jiǎn)稱GLR)對(duì)上述工具集合進(jìn)行問(wèn)題的總結(jié),歸納出多個(gè)自動(dòng)化工具在DevOps 實(shí)踐中存在的問(wèn)題,最后針對(duì)這些問(wèn)題,采取訪談的形式從企業(yè)人員、咨詢師、研究者這3 個(gè)角度獲取評(píng)價(jià),從而得出對(duì)每個(gè)問(wèn)題的建議.

2.2.1 系統(tǒng)化文獻(xiàn)評(píng)價(jià)

自2004 年Kitchenham 等人首次將系統(tǒng)化文獻(xiàn)評(píng)價(jià)(SLR)引入軟件工程以來(lái)[17],SLR 已成為軟件工程中一種重要的研究方法[18],在《DevOps 自動(dòng)化支持工具調(diào)研》[19]中,李杉杉等人對(duì)DevOps 實(shí)踐中的自動(dòng)化支持工具做出了系統(tǒng)化文獻(xiàn)評(píng)價(jià),對(duì)DevOps 自動(dòng)化支持工具的相關(guān)文獻(xiàn)進(jìn)行了檢索,本文按照?qǐng)?bào)告中的字符串((DevOps)in title or keyword or abstract AND (tool*)in full-text)進(jìn)行了初步的檢索,有168 篇文獻(xiàn)被確定為相關(guān)文獻(xiàn),其中包括IEEE Xplore 的71 篇,ACM Digital Library 的53 篇,SpringerLink 的19 篇以及ScienceDirect 的25 篇.由于本文更多關(guān)注自動(dòng)化工具在DevOps 實(shí)踐中的影響,只需要獲取學(xué)術(shù)界常見(jiàn)的工具集合,因此,我們對(duì)于文獻(xiàn)的選擇做出了更加嚴(yán)格的限制,在標(biāo)題、摘要和關(guān)鍵字中出現(xiàn)DevOps 和Tool 相關(guān)詞匯的文獻(xiàn)被篩選出來(lái)進(jìn)行數(shù)據(jù)抽取.最終,本文得到了50 篇DevOps 自動(dòng)化支持工具的相關(guān)文獻(xiàn),對(duì)這50 篇文獻(xiàn)中提到的工具進(jìn)行抽取,得到一個(gè)DevOps 自動(dòng)化支持工具的集合.

Fig.2 Research method圖2 本文研究方法

2.2.2 灰色文獻(xiàn)評(píng)價(jià)

灰色文獻(xiàn)是由傳統(tǒng)商業(yè)或?qū)W術(shù)出版和分銷渠道以外的組織制作的材料和研究.通常情況下,學(xué)術(shù)文獻(xiàn)中的信息會(huì)落后于灰色文獻(xiàn)[20],DevOps 文化起源于技術(shù)社區(qū),發(fā)展于軟件開(kāi)發(fā)組織,學(xué)術(shù)界在對(duì)DevOps 的理解上相對(duì)來(lái)說(shuō)落后于社區(qū)和軟件組織,而且研究者使用工具的頻率遠(yuǎn)低于工業(yè)界,在使用中遇到的問(wèn)題或困擾必然少于工業(yè)界,因此,針對(duì)DevOps 實(shí)踐中自動(dòng)化存在的問(wèn)題,單純地從學(xué)術(shù)文獻(xiàn)中獲取是不夠客觀和完整的.本文從文獻(xiàn)中識(shí)別了69 個(gè)自動(dòng)化工具,而XebiaLabs 公司根據(jù)工具類型的不同,把120 種DevOps 工具分成了15 個(gè)大類,由此可見(jiàn),灰色文獻(xiàn)對(duì)研究文獻(xiàn)具有極大的補(bǔ)充作用.

因此,針對(duì)研究問(wèn)題2,本文采用灰色文獻(xiàn)評(píng)價(jià)的方法,在選取灰色文獻(xiàn)來(lái)源時(shí),我們對(duì)比了簡(jiǎn)書(shū)、知乎和Gitbook 這3 個(gè)數(shù)據(jù)源.其中,Gitbook 中的數(shù)據(jù)均為書(shū)籍章節(jié),不能夠體現(xiàn)DevOps 實(shí)踐在中國(guó)環(huán)境下產(chǎn)生的問(wèn)題;知乎作為一個(gè)網(wǎng)絡(luò)問(wèn)答社區(qū),存在各種問(wèn)題與解決問(wèn)題的方法,但經(jīng)過(guò)檢索我們發(fā)現(xiàn),知乎中問(wèn)題和回答的數(shù)量級(jí)較小,選其作數(shù)據(jù)源可能會(huì)造成較大的偏差;簡(jiǎn)書(shū)作為一個(gè)原創(chuàng)社區(qū),其作者涵蓋了研究者、咨詢師和企業(yè)從業(yè)人員這3 類與DevOps 實(shí)踐中自動(dòng)化工具密切相關(guān)的人群,簡(jiǎn)書(shū)上超過(guò)50 萬(wàn)個(gè)專題中有像Docker 等專門(mén)收錄相關(guān)工具文章的專題,并且每個(gè)專題都有比知乎更多的文獻(xiàn).我們通過(guò)簡(jiǎn)書(shū)獲取博客,在保證博客的原創(chuàng)性與質(zhì)量的同時(shí),能夠更好地獲取DevOps 在中國(guó)實(shí)踐中產(chǎn)生的問(wèn)題,對(duì)結(jié)果的準(zhǔn)確性有著更好的支持.本文對(duì)于DevOps 實(shí)踐的幾個(gè)環(huán)節(jié):容器、持續(xù)集成、版本管理、編譯、配置管理,從簡(jiǎn)書(shū)中選擇其中最熱門(mén)的專題對(duì)其中的博客進(jìn)行爬取.一共爬取到1 942 篇博客.由于簡(jiǎn)書(shū)中的博客沒(méi)有標(biāo)簽選項(xiàng),而且對(duì)于關(guān)鍵詞的搜索策略為包含其中一個(gè)關(guān)鍵詞即列入結(jié)果列表,因此,本文檢索了關(guān)鍵詞“DevoOps”和“工具”,并對(duì)搜索結(jié)果以相關(guān)性排序的前50 篇博客進(jìn)行分析,對(duì)博客中提出的問(wèn)題進(jìn)行歸納,結(jié)合第1 次Web 挖掘時(shí)產(chǎn)生的統(tǒng)計(jì)數(shù)據(jù)整理問(wèn)題,形成DevOps 文化中自動(dòng)化工具所存在的問(wèn)題列表.

2.2.3 民族志:訪談

民族志是用來(lái)揭示在某種文化中支撐社會(huì)行為的過(guò)程和意義的方法[21-24].在民族志方法中,訪談是獲取數(shù)據(jù)的重要手段[25-28].相較研究文獻(xiàn)和灰色文獻(xiàn)而言,訪談可以通過(guò)引導(dǎo)訪談對(duì)象進(jìn)行深度交談來(lái)獲取更為可靠、有效并且接近實(shí)際的信息[29],對(duì)于DevOps 自動(dòng)化支持工具在使用中的問(wèn)題,通過(guò)訪談的形式可以更為準(zhǔn)確地了解它們?cè)趯?shí)際情境下的真實(shí)情況,此時(shí)獲取的有關(guān)這些問(wèn)題的建議或者解決方案,往往在真實(shí)情況下能夠更加容易地實(shí)現(xiàn).本文的訪談對(duì)象都是對(duì)DevOps 有一定了解的專家,在了解他們對(duì)DevOps 中事物的看法時(shí),結(jié)構(gòu)的或半結(jié)構(gòu)的訪談是最有價(jià)值的.而半結(jié)構(gòu)的訪談比結(jié)構(gòu)的訪談能夠獲取更多被訪談人員自己的想法,從而可以形成更加客觀的結(jié)論,因此,本文選取半結(jié)構(gòu)的訪談作為訪談方法.

三角測(cè)量是民族志研究的基礎(chǔ),是民族志研究正確性的關(guān)鍵所在,可以提高資料質(zhì)量和成果的精確度[25],因此,本文在選取被采訪人員時(shí),從DevOps 研究者、DevOps 企業(yè)從業(yè)人員和DevOps 咨詢師這3 個(gè)維度進(jìn)行,從而保證最終結(jié)論的準(zhǔn)確性.其中,DevOps 研究者來(lái)自高校,有多年的DevOps 研究經(jīng)驗(yàn);DevOps 咨詢師來(lái)自軟件咨詢公司,長(zhǎng)期從事DevOps 方面的軟件咨詢工作;DevOps 從業(yè)人員為各公司的架構(gòu)師,對(duì)于公司開(kāi)發(fā)運(yùn)維的方式有一定的認(rèn)識(shí),并且也參與過(guò)一些DevOps 項(xiàng)目的開(kāi)發(fā).

最終,本文邀請(qǐng)到7 位相關(guān)的專家參與訪談,名單見(jiàn)表1.

Table 1 List of interviewed experts表1 接受訪談的專家

針對(duì)3 個(gè)維度的被訪談人員,訪談時(shí)需要采用不同的訪談問(wèn)題,由于希望獲得更多的信息,因此,問(wèn)題中需要包含更多普泛的問(wèn)題,但是對(duì)某些具體的情形,則需要專門(mén)的問(wèn)題.另外,封閉式的問(wèn)題在嘗試量化行為模式時(shí)是比較有用的,而開(kāi)放式的問(wèn)題允許參與者本人來(lái)解析它,從而可以獲得更多信息,有助于闡釋不同人員自己的世界觀,因此,本文對(duì)被訪人員采用開(kāi)放式的問(wèn)題來(lái)進(jìn)行訪談.

Table 2 Outline of interview questions表2 訪談問(wèn)題大綱

自動(dòng)化支持工具作為研究的對(duì)象在訪談問(wèn)題中并不需要提及太多,這樣可以獲得更多的被訪人員在無(wú)意識(shí)下對(duì)自動(dòng)化支持工具的看法,從而提升結(jié)論的客觀性.訪談中的問(wèn)題不拘泥于表2 所列內(nèi)容,因?yàn)椴煌墓舅幍男袠I(yè)不同、環(huán)境不同,不同的咨詢師所服務(wù)的公司也各有不同,所以,對(duì)于每一位被訪人員,都需要在了解背景以后,根據(jù)具體的訪談情境做出針對(duì)性的修改,具體的修改內(nèi)容在結(jié)果分析中會(huì)列出.DevOps 咨詢師分布在全國(guó)各地,由于地域和時(shí)間的限制,我們對(duì)于這部分專家(E3、E4 和E5)采取線上訪談的模式.線上訪談是線上民族志的主要部分,是這個(gè)領(lǐng)域開(kāi)創(chuàng)性作品采用的方法之一.雖然Bruckman 認(rèn)為“線上訪談價(jià)值有限”,但是他評(píng)價(jià)的是基于文字的線上訪談,本文采取電話訪談作為線上訪談的形式,能夠獲取更多的細(xì)節(jié),而這種方法在Robert V.Kozinets 看來(lái)也是可取和可信的[30,31].

2.2.4 數(shù)據(jù)整合和分析

為了回答研究問(wèn)題,我們采用了定量和定性的數(shù)據(jù)分析方法.對(duì)于研究問(wèn)題1,采用統(tǒng)計(jì)性的描述去整合我們的數(shù)據(jù),為了方便理解,使用圖表來(lái)展示我們的數(shù)據(jù).扎根理論[32]被用于對(duì)研究問(wèn)題2 的回答,這樣的應(yīng)用能夠逐步發(fā)現(xiàn)工具在DevOps 實(shí)踐中產(chǎn)生的問(wèn)題,并能據(jù)此建立一個(gè)問(wèn)題的集合.而在回答研究問(wèn)題3 時(shí),我們結(jié)合了主題分析[33]和民族志方法中常見(jiàn)的摘要敘述[25]方式,包含了一些逐字引用,以說(shuō)明專家對(duì)某幾個(gè)問(wèn)題的真實(shí)看法.

3 結(jié)果分析

3.1 針對(duì)研究問(wèn)題1

圖3 所示的柱狀圖展示了初步檢索后的168 篇文獻(xiàn)(2011 年～2018 年)的分布情況,由圖3 可以看出,有關(guān)DevOps 工具相關(guān)的論文從2014 年開(kāi)始激增,在2014 年～2017 年間,每年增長(zhǎng)的幅度保持了一個(gè)較高水平,而在2018 年有一個(gè)急劇下降,這是因?yàn)?本研究的文獻(xiàn)檢索工作是在2018 年第1 季度展開(kāi)的.

Fig.3 Study distribution of DevOps tools圖3 DevOps 工具相關(guān)文獻(xiàn)分布

由此可見(jiàn),研究者對(duì)DevOps 自動(dòng)化工具相關(guān)研究的興趣是逐年遞增的.鑒于研究者對(duì)DevOps 的相關(guān)研究的興趣也是越來(lái)越強(qiáng),本文又以DevOps 為關(guān)鍵詞對(duì)4 個(gè)電子文獻(xiàn)庫(kù)進(jìn)行了一次檢索,記錄下每一年相關(guān)研究的數(shù)量,并計(jì)算每年與DevOps 工具相關(guān)的文獻(xiàn)所占比例,從圖3 所示的折線圖我們可以看出,從2014 年開(kāi)始,與自動(dòng)化工具相關(guān)的研究在DevOps 相關(guān)研究中所占的比例穩(wěn)定在35%～40%.這顯示了在DevOps 持續(xù)發(fā)展的階段,研究者始終保持了對(duì)自動(dòng)化工具的熱情,同時(shí)這也彰顯了自動(dòng)化工具作為DevOps 文化的基石的重要性.

針對(duì)DevOps 實(shí)踐中常用的自動(dòng)化工具,本文對(duì)篩選出的50 篇文獻(xiàn)進(jìn)行了數(shù)據(jù)抽取,共識(shí)別出69 個(gè)自動(dòng)化工具,其中提及率超過(guò)10%的工具排名如下文的圖4 所示.從圖中可以看出,Docker、Chef、Jenkins 是DevOps自動(dòng)化支持工具中最常見(jiàn)、最為研究者所青睞的3 個(gè)工具,尤其是Docker 和Chef,幾乎每?jī)善墨I(xiàn)就有一篇會(huì)提及它們.

3.2 針對(duì)研究問(wèn)題2

對(duì)于爬取到的博客文章,本文首先對(duì)發(fā)表的時(shí)間進(jìn)行了一些分析,從圖5 中我們可以看出,有關(guān)DevOps 實(shí)踐的5 個(gè)關(guān)鍵過(guò)程——容器、持續(xù)集成、版本管理、編譯和配置管理中有關(guān)工具的博客數(shù)量從2013 年至今總體上呈現(xiàn)上升的趨勢(shì),并在2017 年達(dá)到了頂峰,而從2017 年第4 季度開(kāi)始有小幅回落,出現(xiàn)這個(gè)狀況的原因可能是DevOps 經(jīng)過(guò)多年發(fā)展,在2017 年已經(jīng)接近成熟,尤其是在工具使用方面,面臨的問(wèn)題已經(jīng)趨于穩(wěn)定.

Fig.4 Frequency of automation tools in support of DevOps in studies圖4 DevOps 自動(dòng)化支持工具文獻(xiàn)提及頻率

Fig.5 Time distribution of blogs in 5 topics on DevOps in Jianshu圖5 簡(jiǎn)書(shū)DevOps 5 個(gè)專題中博客數(shù)量的時(shí)間分布

對(duì)于自動(dòng)化工具在DevOps 實(shí)踐中存在的問(wèn)題,根據(jù)對(duì)簡(jiǎn)書(shū)博客的分析,可以將其分為多樣性、聯(lián)系、文化這3 個(gè)不同維度的問(wèn)題.

3.2.1 DevOps 實(shí)踐中自動(dòng)化工具的多樣性問(wèn)題

在研究問(wèn)題1 中,本文根據(jù)文獻(xiàn)識(shí)別出了69 個(gè)DevOps 自動(dòng)化支持工具,而在第2 節(jié)也提到了XebiaLabs公司根據(jù)120 個(gè)DevOps 自動(dòng)化支持工具制作的DevOps 工具周期表,由此可見(jiàn),DevOps 自動(dòng)化工具數(shù)量龐大.而從第2 次Web 挖掘的博客中,本文共識(shí)別出162 個(gè)DevOps 自動(dòng)化支持工具,包括配置管理、構(gòu)建、測(cè)試、集成、部署等不同類型.眾多的工具帶來(lái)了選擇上的問(wèn)題,在簡(jiǎn)書(shū)的博客中,每一篇博客都選取了至少一個(gè)不相同的工具來(lái)搭建自己的工具鏈,同一篇博客也會(huì)在某個(gè)階段推薦兩個(gè)不一樣的工具,比如OneAPM 就比較了DevOps 配置管理階段的兩個(gè)工具Fabric 和Ansible 在使用時(shí)給用戶帶來(lái)的不同的體驗(yàn).

數(shù)量眾多的自動(dòng)化支持工具不僅帶來(lái)了選擇的問(wèn)題,有時(shí)也會(huì)帶來(lái)對(duì)工具的理解問(wèn)題,在工具日益增多的情況下,對(duì)于DevOps 的后來(lái)者需要學(xué)習(xí)和理解的DevOps 知識(shí)的廣度和深度也越來(lái)越大.同樣,對(duì)于一個(gè)工具來(lái)說(shuō),功能也是隨著時(shí)間而增多的,Nagios 的官網(wǎng)顯示,它的各種插件已經(jīng)達(dá)到了4 347 種.從表3 我們可以看到,大部分的DevOps 自動(dòng)化支持工具都有很多的插件,而復(fù)雜的工具會(huì)在工作時(shí)帶來(lái)更多復(fù)雜的情況,也會(huì)帶來(lái)更多的問(wèn)題.另一方面,隨著自動(dòng)化工具功能的完善,更多的軟件組織會(huì)采用更加復(fù)雜的方式進(jìn)行開(kāi)發(fā),例如,Docker 的興起鼓勵(lì)許多組織進(jìn)行基于微服務(wù)架構(gòu)的開(kāi)發(fā),這也增加了DevOps 自動(dòng)化的復(fù)雜性.

Table 3 The number of languages and plug-ins used by some automation tools in support of DevOps表3 部分DevOps 自動(dòng)化支持工具使用的語(yǔ)言和插件數(shù)量

3.2.2 DevOps 實(shí)踐中自動(dòng)化工具間的聯(lián)系問(wèn)題

DevOps 眾多的自動(dòng)化工具讓人在選擇上產(chǎn)生困惑,但是更重要的一個(gè)問(wèn)題是各個(gè)階段的工具之間的聯(lián)系問(wèn)題.在第1 節(jié)中提到,相比國(guó)外DevOps 實(shí)踐的發(fā)展,中國(guó)DevOps 文化更加關(guān)注于工具的使用,因此,打造一個(gè)易用的DevOps 工具鏈?zhǔn)敲恳粋€(gè)軟件組織都希望完成的事情.但是,現(xiàn)階段多數(shù)DevOps 工具鏈其實(shí)都不夠完善,目前大部分可用的DevOps 工具都是基于碎片點(diǎn)的孤立解決方案,只能在DevOps 工作流的特定階段完成特定任務(wù).以華為軟件開(kāi)發(fā)云為例,它的自定義流水線是解決不同階段工具聯(lián)系的一種方法,但是與其他工具鏈一樣,它重點(diǎn)關(guān)注于Dev 階段,對(duì)于Ops,雖有布局,但是關(guān)注并不像Dev 那樣多,這也導(dǎo)致在Dev 和Ops 銜接的時(shí)候會(huì)出現(xiàn)聯(lián)系不密切的問(wèn)題.此外,對(duì)于大部分的軟件組織來(lái)說(shuō),如何將傳統(tǒng)工具和新應(yīng)用聯(lián)系起來(lái),會(huì)是另一個(gè)棘手的問(wèn)題.

3.2.3 DevOps 實(shí)踐中有關(guān)自動(dòng)化工具的文化問(wèn)題

無(wú)論是DevOps 自動(dòng)化支持工具的數(shù)量問(wèn)題,還是各個(gè)階段工具間的聯(lián)系問(wèn)題,歸根結(jié)底它是DevOps 的文化問(wèn)題.沒(méi)有合適的文化和適應(yīng)這種文化的人,即使擁有再好的工具,也不會(huì)成功地實(shí)施DevOps 實(shí)踐.這一點(diǎn)在中國(guó)尤為重要,簡(jiǎn)書(shū)中幾乎每一篇有關(guān)DevOps 工具使用問(wèn)題的博客都會(huì)或多或少地提及其中的文化問(wèn)題,他們認(rèn)為單純地使用工具沒(méi)有辦法打破團(tuán)隊(duì)間的壁壘,因?yàn)槊恳粋€(gè)團(tuán)隊(duì)都希望使用最符合自己需求的工具鏈,甚至在同一個(gè)團(tuán)隊(duì)中,每個(gè)技術(shù)人員都有自己偏好使用的工具,而很多時(shí)候他們(技術(shù)人員)都自視甚高.

敏捷宣言中提到,最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì),Hackman 給我們提供了一個(gè)可以區(qū)分團(tuán)隊(duì)自組織4 個(gè)層次的權(quán)力矩陣[34](如后文的圖6 所示).在中國(guó)的環(huán)境下,軟件組織中的團(tuán)隊(duì)大多是管理者領(lǐng)導(dǎo)型團(tuán)隊(duì)和自管理型團(tuán)隊(duì).而在軟件組織中,為了保證各個(gè)部門(mén)間的協(xié)作,必須使用兼容工具,不匹配的工具集會(huì)產(chǎn)生瓶頸、誤解和誤導(dǎo),進(jìn)而導(dǎo)致大量的時(shí)間被浪費(fèi),而在多個(gè)部門(mén)需要使用一個(gè)DevOps 工具鏈時(shí),如果存在工具選用上的分歧,在中國(guó)的文化環(huán)境下,從權(quán)力矩陣中我們可以發(fā)現(xiàn),在環(huán)境這一部分的選擇大多由管理者或者企業(yè)組織的領(lǐng)導(dǎo)者決定,而這樣的決定形式很大程度上會(huì)導(dǎo)致團(tuán)隊(duì)間的信任危機(jī),從而影響業(yè)務(wù)效率,進(jìn)一步地,這也違背了我們?cè)诘? 節(jié)中提到的以信任和尊重為核心的DevOps 文化的精神.這一點(diǎn)尤其表現(xiàn)在開(kāi)發(fā)人員與運(yùn)維人員可能產(chǎn)生的沖突上,開(kāi)發(fā)人員關(guān)注的重點(diǎn)是新的功能的實(shí)現(xiàn),而運(yùn)維人員關(guān)注的重點(diǎn)是已有功能的成功運(yùn)行,不同的關(guān)注重點(diǎn)在工具鏈中想要獲得的內(nèi)容是不同的,想要工具鏈實(shí)現(xiàn)的細(xì)節(jié)也會(huì)是不同的,在開(kāi)發(fā)人員強(qiáng)勢(shì)、運(yùn)維人員弱勢(shì)的情況下,軟件組織必然會(huì)選用開(kāi)發(fā)人員所偏好的工具,這時(shí)候,開(kāi)發(fā)人員可能會(huì)因此擔(dān)負(fù)部分運(yùn)維任務(wù),這會(huì)更加惡化開(kāi)發(fā)、運(yùn)維二者的關(guān)系,從而讓DevOps 名存實(shí)亡,變成一種通過(guò)自動(dòng)化工具和手段構(gòu)建的標(biāo)準(zhǔn)流程.

3.3 針對(duì)研究問(wèn)題3

在訪談中提及工具的多樣性時(shí),專家們總是會(huì)談起工具的選擇、聯(lián)系等問(wèn)題,相較于工具本身,專家們更關(guān)注工具在整個(gè)實(shí)踐中的地位、發(fā)揮的作用以及它所帶來(lái)的影響.專家E5 就表示,“每個(gè)工具有不同的功能,我們做的事情就是把工具串起來(lái)”.專家E4 并不關(guān)注DevOps 自動(dòng)化支持工具的問(wèn)題,他認(rèn)為有了優(yōu)秀的工程師文化,自然而然地可以解決工具方面帶來(lái)的任何問(wèn)題(如圖7 所示).

這一點(diǎn)是可以被理解的,在整個(gè)DevOps 實(shí)踐中,不存在完全獨(dú)立于其他自動(dòng)化工具的工具,所以,對(duì)于訪談中的這一部分內(nèi)容我們也作了進(jìn)一步的識(shí)別:我們認(rèn)為,在單獨(dú)討論某一個(gè)工具時(shí),如果專家對(duì)這個(gè)工具進(jìn)行了延展,提及了與之有交互的其他工具,那么這一部分的訪談也會(huì)被認(rèn)為是涉及了工具間的聯(lián)系問(wèn)題;而在單獨(dú)討論某一工具時(shí),如果專家也提及了文化問(wèn)題,我們也認(rèn)為這一部分的訪談可以作為專家對(duì)文化問(wèn)題的回答.

在涉及DevOps 實(shí)踐中自動(dòng)化工具的多樣性問(wèn)題時(shí),眾多的插件使得工具變得更加復(fù)雜這個(gè)問(wèn)題在專家看來(lái)是不可避免的,因?yàn)椤安寮漠a(chǎn)生肯定是為了滿足某一個(gè)需求”.面對(duì)這個(gè)問(wèn)題,專家E7 認(rèn)為,在選擇工具時(shí)需要固定一個(gè)版本,不要冒然地改動(dòng),當(dāng)遇到問(wèn)題時(shí)再根據(jù)實(shí)際情況選擇合適的更新版本.

Fig.6 Power matrix圖6 權(quán)力矩陣

Fig.7 Part of interview with expert E4 on DevOps tools圖7 對(duì)專家E4 有關(guān)DevOps 工具的訪談片段

在面對(duì)如何選擇自動(dòng)化工具的問(wèn)題時(shí),專家們表示,適合公司的、團(tuán)隊(duì)成員更加熟悉的工具更應(yīng)該被使用.專家E1 就把選擇工具類比為選擇程序設(shè)計(jì)語(yǔ)言,認(rèn)為在選擇工具的時(shí)候需要考慮到團(tuán)隊(duì)的技術(shù)積累.若是某個(gè)環(huán)節(jié)上引入的工具對(duì)于團(tuán)隊(duì)人員來(lái)說(shuō)不是那么熟悉,那么專家給出的建議應(yīng)是從其中選擇開(kāi)源的、參考資料多的以及被使用程度高的工具,在專家E2 看來(lái),“在每個(gè)環(huán)節(jié)都有兩三款處于領(lǐng)先地位的工具,其他的工具其實(shí)差很多,而這些處于領(lǐng)先地位的工具的參考資料都是極大豐富的,比如說(shuō)版本控制階段的Git”(如圖8 所示).

Fig.8 Part of interview with expert E2 on tools selection criteria圖8 對(duì)專家E2 關(guān)于工具選擇標(biāo)準(zhǔn)的訪談片段

專家們表示流水線是解決工具之間聯(lián)系問(wèn)題的一個(gè)好的選擇.而在構(gòu)建流水線時(shí),專家E4 表示要從持續(xù)集成開(kāi)始,慢慢地?cái)U(kuò)展到持續(xù)交付,從而形成一個(gè)規(guī)范的自動(dòng)化的流水線.對(duì)于流水線的應(yīng)用,專家E3 則表示應(yīng)該從平臺(tái)開(kāi)始,技術(shù)先行,然后采用試點(diǎn)的方式,先對(duì)和企業(yè)核心資產(chǎn)關(guān)系不是太親密的部分進(jìn)行改革,逐漸改善流水線,最后達(dá)到引入DevOps 的目的.專家們對(duì)于流水線的建議十分契合唯物辯證法中的兩點(diǎn)論與重點(diǎn)論,在構(gòu)建這樣一條DevOps 流水線時(shí)全面統(tǒng)籌企業(yè)的所有部門(mén),厘清重要功能與在短時(shí)間內(nèi)可深入改革的部分,從持續(xù)集成這個(gè)重點(diǎn)開(kāi)始進(jìn)行DevOps 轉(zhuǎn)型,最終實(shí)現(xiàn)快速響應(yīng)交付.

在DevOps 實(shí)踐中運(yùn)維與開(kāi)發(fā)的聯(lián)系的問(wèn)題是最重要的部分之一,大部分專家也表示這是一個(gè)很關(guān)鍵但卻是比較困難的問(wèn)題.專家E7 認(rèn)為,他們公司就沒(méi)有完全打通開(kāi)發(fā)和運(yùn)維之間的壁壘,需要在以后的實(shí)踐中對(duì)持續(xù)部署這部分做更多的工作;專家E4 則認(rèn)為,目前開(kāi)發(fā)和運(yùn)維之間聯(lián)系不密切的原因是技術(shù)能力的不足,他相信,在基礎(chǔ)設(shè)施達(dá)到某一水平之后,二者之間的壁壘自然而然就會(huì)打通,而在達(dá)到這個(gè)水平之前,開(kāi)發(fā)和運(yùn)維的工具鏈仍然是封閉的.本文認(rèn)為,二位專家的意見(jiàn)是一致的,專家E4 作為咨詢師,在企業(yè)DevOps 轉(zhuǎn)型中提供咨詢的服務(wù),但是在基礎(chǔ)設(shè)施不能夠達(dá)到要求時(shí),也會(huì)束手無(wú)策;專家E7 作為DevOps 企業(yè)從業(yè)人員,則從實(shí)際的工作環(huán)境角度對(duì)基礎(chǔ)設(shè)施的問(wèn)題做出了自己的回答,并希望可以在某些環(huán)節(jié)能夠有技術(shù)上的提升.

在談到傳統(tǒng)工具與新工具的聯(lián)系問(wèn)題時(shí),專家們的分歧較為明顯,專家E1 表示,“要盡可能地降低整個(gè)學(xué)習(xí)的成本,盡可能地遷就項(xiàng)目團(tuán)隊(duì)成員原有的一些工具,然后需要去找新的工具,那么新的工具要與原有工具的匹配度盡可能地好一些”;而專家E2 則表示,應(yīng)該在軟件層面上對(duì)原有的工具進(jìn)行全部替換,他指出,現(xiàn)有的企業(yè)大多數(shù)是這樣進(jìn)行的.本文認(rèn)為,這是二位DevOps 研究人員在思考這樣的問(wèn)題時(shí)把自己代入的環(huán)境不同所造成的.專家E1 長(zhǎng)期從事敏捷開(kāi)發(fā)的研究,思考這類問(wèn)題時(shí)更多考慮的是有著長(zhǎng)期敏捷開(kāi)發(fā)經(jīng)驗(yàn)的組織,訪談中他也經(jīng)常提及敏捷在DevOps 中的作用與不同,敏捷團(tuán)隊(duì)比起其他傳統(tǒng)的團(tuán)隊(duì)對(duì)于DevOps 有更好的適應(yīng)性,DevOps 實(shí)踐中很多自動(dòng)化工具我們也可以在敏捷開(kāi)發(fā)中看到;而專家E2 長(zhǎng)期從事的是軟件開(kāi)發(fā)過(guò)程的研究,更多思考的是傳統(tǒng)的軟件開(kāi)發(fā)流程,在短周期交付的情況下,很多傳統(tǒng)的工具已經(jīng)不能滿足需求的快速變更,與其花費(fèi)時(shí)間匹配工具,不如直接更換全新的工具鏈.

在文化層面上,每一位專家都提到了組織結(jié)構(gòu)和制度問(wèn)題,他們提到的康威法則(Conway’s low)認(rèn)為,“一個(gè)組織最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的結(jié)構(gòu)”.而對(duì)于具體的企業(yè)文化,專家E1 表示要提升團(tuán)隊(duì)的自組織性,對(duì)于環(huán)境工具的選擇要聽(tīng)取更多團(tuán)隊(duì)的意見(jiàn),探索自組織型團(tuán)隊(duì)在中國(guó)環(huán)境中的優(yōu)秀實(shí)踐;專家E2 提出要明確團(tuán)隊(duì)目標(biāo),采用能夠?qū)崿F(xiàn)目標(biāo)的工具與流程,獎(jiǎng)懲應(yīng)該以實(shí)現(xiàn)多少目標(biāo)為依據(jù),同時(shí),程序員要增加自信心;專家E4 則表示,應(yīng)該更加相信程序員,對(duì)于工具問(wèn)題要給予他們更多的選擇權(quán)力;專家E7 在同意給程序員更多選擇空間的同時(shí)也認(rèn)為要通過(guò)更多的制度來(lái)保證擁有更多權(quán)力的程序員不會(huì)成為公司的隱患;專家E3 也對(duì)這方面做出了自己的總結(jié),“從組織結(jié)構(gòu)上打破部門(mén)墻,從工具的角度使信息透明,從而做到在工具上可以一次性做到協(xié)作,然后從流程上界定好開(kāi)發(fā)與運(yùn)維之間的責(zé)任關(guān)系,并且能力上要進(jìn)行多元化的發(fā)展”(如圖9 所示).

Fig.9 Part of interview with expert E3 on the relationship between development and operation teams圖9 對(duì)專家E3 關(guān)于開(kāi)發(fā)運(yùn)維的關(guān)系的訪談片段

綜合整個(gè)訪談,我們對(duì)各個(gè)專家的意見(jiàn)進(jìn)行了總結(jié),見(jiàn)表4.

Table 4 Recommendations for three dimensions of automation tools in support of DevOps表4 對(duì)DevOps 自動(dòng)化支持工具3 個(gè)層次問(wèn)題的建議

對(duì)這些建議,我們可以總結(jié)為3 點(diǎn):(1)選擇適合組織的、團(tuán)隊(duì)成員熟悉的自動(dòng)化工具,在此基礎(chǔ)上選擇開(kāi)源的、參考資料豐富、被廣泛認(rèn)可的自動(dòng)化工具,在適當(dāng)?shù)臅r(shí)候通過(guò)自己開(kāi)發(fā)工具適配組織結(jié)構(gòu),自己開(kāi)發(fā)插件滿足組織流程對(duì)自動(dòng)化工具的要求.(2)各個(gè)階段選擇相互匹配的自動(dòng)化工具,加強(qiáng)基礎(chǔ)設(shè)施的建設(shè)來(lái)加強(qiáng)工具間的聯(lián)系,并以此構(gòu)建一個(gè)標(biāo)準(zhǔn)化的自動(dòng)化的流水線.(3)構(gòu)建符合DevOps 價(jià)值觀的企業(yè)文化,變革組織結(jié)構(gòu),制定和完善相應(yīng)的制度,鼓勵(lì)程序員,使之保持信心和熱情.

在形成建議的同時(shí)我們對(duì)訪談中專家對(duì)于3 個(gè)層次問(wèn)題的關(guān)注程度,從在談及各個(gè)層次問(wèn)題時(shí)的態(tài)度、語(yǔ)速、語(yǔ)氣以及內(nèi)容的多少,形成了表5.

Table 5 Level of concern with three dimensions of automated tools in support of DevOps表5 對(duì)DevOps 自動(dòng)化支持工具3 個(gè)層次問(wèn)題的關(guān)注程度

專家E4 在談到具體工具時(shí)語(yǔ)速加快,而且迅速?gòu)木唧w工具談到每個(gè)工具之間的聯(lián)系,再上升為文化,我們就可以認(rèn)為,專家E4 對(duì)于DevOps 自動(dòng)化支持工具的第1 層次問(wèn)題的關(guān)注很少,甚至不關(guān)注,所以我們把他對(duì)多樣性問(wèn)題的關(guān)注程度標(biāo)注為1;專家E1 在談?wù)揇evOps 自動(dòng)化支持工具的時(shí)候就專注于工具本身,語(yǔ)氣平緩,語(yǔ)速適中,并沒(méi)有表現(xiàn)出對(duì)每一種類型的工具有強(qiáng)烈的興趣,所以我們認(rèn)為他對(duì)工具多樣性的關(guān)注程度為3;而專家E6 在訪談中大量地介紹他們公司所構(gòu)建的工具“布加迪”,語(yǔ)氣中充滿自豪與自信,并且堅(jiān)持認(rèn)為未來(lái)會(huì)繼續(xù)開(kāi)發(fā)這一工具,則本文認(rèn)為,他對(duì)于工具本身的關(guān)注是很多的,也很重視工具,所以我們認(rèn)為,他對(duì)工具多樣性的關(guān)注度為5.

從表5 中我們可以看出,DevOps 的研究者和咨詢師對(duì)文化問(wèn)題的關(guān)注明顯高于企業(yè)從業(yè)人員,這在一定程度上也顯示了兩種不同的思想,研究者和咨詢師更注重企業(yè)文化的培育,認(rèn)為企業(yè)文化決定了更多的東西,而企業(yè)從業(yè)人員不會(huì)對(duì)文化給予過(guò)多關(guān)注,他們?cè)诤醯氖枪ぷ魇欠窨旖?一個(gè)工具或者一種實(shí)踐能否帶來(lái)效率的提升,這也符合企業(yè)的定位,任何企業(yè)都需要以市場(chǎng)為導(dǎo)向,而目前的環(huán)境中,能夠快速地進(jìn)行開(kāi)發(fā)和運(yùn)維則是企業(yè)應(yīng)對(duì)市場(chǎng)變化的基礎(chǔ).訪談中,DevOps 的研究者也都提到了如今DevOps 的研究與工業(yè)界存在的差距,通過(guò)表3 我們也可以看到,這種差距是由于所處的不同的環(huán)境造成的,在某種程度上是不可避免的.研究者對(duì)DevOps 的研究想要更加深入,應(yīng)該要有更細(xì)致的規(guī)劃,進(jìn)入企業(yè)內(nèi)部參與企業(yè)的每一次轉(zhuǎn)變.而企業(yè)也應(yīng)當(dāng)重視研究者所給出的意見(jiàn),在追求快速、簡(jiǎn)潔流程的同時(shí),注重企業(yè)文化的培育.

根據(jù)各個(gè)專家在訪談中的建議、提出的看法以及企業(yè)中合適的做法,對(duì)于軟件組織引入DevOps,構(gòu)建合適的工具鏈,本文給出了如圖10 所示的自上而下的引入DevOps 的范例.軟件組織的高層受到DevOps 顧問(wèn)的影響,學(xué)習(xí)DevOps 的理念,從而轉(zhuǎn)變自己的思想,使之適應(yīng)DevOps 的價(jià)值觀,然后從制度入手,把DevOps 團(tuán)隊(duì)的權(quán)力與義務(wù)以制度化的形式確定下來(lái),保證在后續(xù)過(guò)程中每個(gè)環(huán)節(jié)的責(zé)任都能夠找到承擔(dān)的人員或團(tuán)隊(duì),DevOps 顧問(wèn)在制度的起草階段起到一個(gè)建議人的作用.在確定了新的制度以后,軟件組織高層應(yīng)該對(duì)DevOps 團(tuán)隊(duì)充分地信任,DevOps 團(tuán)隊(duì)?wèi)?yīng)該在DevOps 顧問(wèn)的指導(dǎo)下,由原來(lái)的Dev 團(tuán)隊(duì)和Ops 團(tuán)隊(duì)消除部門(mén)墻之后合并而成,消除部門(mén)墻需要有清晰的組織目標(biāo),由DevOps 協(xié)調(diào)各個(gè)部門(mén),向著這個(gè)目標(biāo)協(xié)同努力,與此同時(shí),改善工作環(huán)境,使每個(gè)部門(mén)能夠更加認(rèn)同組織.在形成新的DevOps 團(tuán)隊(duì)之后,無(wú)論是Dev 團(tuán)隊(duì)成員還是Ops團(tuán)隊(duì)成員,在使用新的流水線和學(xué)習(xí)使用新的工具時(shí)都需要保持自信.而整個(gè)DevOps 流水線由新合并而成的DevOps 團(tuán)隊(duì)決定,原Dev 團(tuán)隊(duì)和原Ops 團(tuán)隊(duì)的成員都需要在這一過(guò)程中參與或者投票選出DevOps 團(tuán)隊(duì)使用的工具,軟件組織高層在整個(gè)流水線制定中和完成后起到一個(gè)監(jiān)控的作用,使整個(gè)流水線符合軟件組織的利益.在制定流水線時(shí)應(yīng)該有先后順序,最重要的3 個(gè)部分是構(gòu)建、發(fā)布和部署,DevOps 團(tuán)隊(duì)?wèi)?yīng)該從這3 個(gè)環(huán)節(jié)入手,一步步完善整個(gè)流水線.

Fig.10 DevOps paradigm for software organization圖10 軟件組織DevOps 轉(zhuǎn)型范例

4 討 論

自動(dòng)化工具是軟件組織中必不可少的部分,DevOps 也會(huì)是未來(lái)軟件組織響應(yīng)快速變化的主要手段,在引入DevOps 的初級(jí)階段,自動(dòng)化工具會(huì)是最重要的一個(gè)環(huán)節(jié),此時(shí)可以認(rèn)為使用自動(dòng)化工具即為DevOps,而隨著DevOps 的發(fā)展,當(dāng)工具不再成為阻礙時(shí),軟件組織的結(jié)構(gòu)與文化就會(huì)超越工具,成為DevOps 發(fā)展的新的核心點(diǎn).可以說(shuō),自動(dòng)化工具是DevOps 發(fā)展的基石,DevOps 的發(fā)展也為自動(dòng)化工具的發(fā)展提供新動(dòng)力.

在訪談中專家們也對(duì)未來(lái)DevOps 的發(fā)展提出了自己的期望,DevOps 的研究者們認(rèn)為,在技術(shù)層面上,產(chǎn)品的設(shè)計(jì)、開(kāi)發(fā)和運(yùn)維會(huì)越來(lái)越成為一個(gè)整體,且DevOps 會(huì)成為以后教學(xué)中的重點(diǎn),越來(lái)越多的工具也會(huì)出現(xiàn),從而推動(dòng)DevOps 的發(fā)展;DevOps 咨詢師們認(rèn)為,更多的企業(yè)會(huì)加入DevOps 轉(zhuǎn)型,不同團(tuán)隊(duì)之間的界限會(huì)越來(lái)越透明;DevOps 企業(yè)從業(yè)者則希望DevOps 有一個(gè)更細(xì)致的切入點(diǎn),可讓企業(yè)更方便、更快捷地提高軟件的交付速度.

本文復(fù)現(xiàn)了李杉杉等人在《DevOps 自動(dòng)化支持工具調(diào)研(技術(shù)報(bào)告)》中的輕量級(jí)的系統(tǒng)化文獻(xiàn)評(píng)價(jià),篩選出50 篇與DevOps 自動(dòng)化支持工具相關(guān)的文獻(xiàn)作為數(shù)據(jù)抽取的原始材料,但是,由于DevOps 是近10 年中才出現(xiàn)和發(fā)展的一個(gè)概念,很多DevOps 的支持工具也是持續(xù)交付所需要的工具,部分論文可能并不會(huì)使用DevOps 的概念,這對(duì)我們得出的在學(xué)術(shù)界關(guān)注的DevOps自動(dòng)化支持工具的排名有一定的影響.我們需要對(duì)持續(xù)交付的相關(guān)文獻(xiàn)進(jìn)行一次檢索,對(duì)于其中可能涉及DevOps 自動(dòng)化支持工具的文獻(xiàn),我們也應(yīng)該將其歸入數(shù)據(jù)抽取的材料中.

在灰色文獻(xiàn)評(píng)價(jià)部分,本文從簡(jiǎn)書(shū)上進(jìn)行了數(shù)據(jù)的摘取,在博客數(shù)量的統(tǒng)計(jì)上,本文選取簡(jiǎn)書(shū)中最熱門(mén)的5個(gè)DevOps 自動(dòng)化支持工具的專題對(duì)其中的博客進(jìn)行了統(tǒng)計(jì),這雖然有可能遺漏某些未收錄入專題中的博客,但在橫向?qū)Ρ戎?這一點(diǎn)帶來(lái)的誤差是可以忽略的,收集到的數(shù)據(jù)仍然可以反映技術(shù)論壇對(duì)于DevOps 自動(dòng)化支持工具的關(guān)注程度.另外,本文試圖探討DevOps 實(shí)踐在中國(guó)的狀況,因此選取了簡(jiǎn)書(shū)作為數(shù)據(jù)來(lái)源,簡(jiǎn)書(shū)是一個(gè)任何人均可在其上進(jìn)行創(chuàng)作的社區(qū),用戶在簡(jiǎn)書(shū)上面可以方便地創(chuàng)作自己的作品,互相交流,它是國(guó)內(nèi)優(yōu)質(zhì)原創(chuàng)內(nèi)容的輸出平臺(tái),選取簡(jiǎn)書(shū)可以保證原創(chuàng)性以及專業(yè)性,但是單純分析一個(gè)數(shù)據(jù)來(lái)源可能會(huì)帶來(lái)一些誤差,我們需要其他類似的中文數(shù)據(jù)來(lái)源對(duì)通過(guò)簡(jiǎn)書(shū)得到的結(jié)論加以驗(yàn)證.

由于地理位置的緣故,本文對(duì)部分訪談人員采用電話訪談的方式代替面對(duì)面的訪談,這會(huì)帶來(lái)一定的限制,在理解被訪談?wù)叩恼鎸?shí)意圖上會(huì)存在一些誤差.本文的訪談對(duì)象中,兩位DevOps 研究者來(lái)自同一所院校,兩位DevOps 咨詢師也來(lái)自同一家咨詢公司,相同的環(huán)境帶來(lái)的限制會(huì)使本文對(duì)DevOps 理解的廣度上有所縮小.解決這一問(wèn)題的一種方法是在中國(guó)環(huán)境下尋找典型的DevOps 實(shí)踐,進(jìn)入現(xiàn)場(chǎng)觀察研究這個(gè)實(shí)踐產(chǎn)生的原因、方式等.在對(duì)專家E6 進(jìn)行訪談時(shí),我們?cè)趯＜业膸ьI(lǐng)下了解其公司的工作流程,圖11 所示為其公司會(huì)議室墻壁上的標(biāo)語(yǔ).觀察與訪談的結(jié)合讓我們對(duì)他在訪談中提及的一些問(wèn)題有了更為深入的了解.而這兩種方法也是民族志方法中最為重要的方法[25,28],二者配合,就可以實(shí)現(xiàn)對(duì)一個(gè)DevOps 實(shí)踐的更為深入的理解.

Fig.11 Meeting room of the company expert E6 works for圖11 專家E6 公司的會(huì)議室

此外,對(duì)于文中給出的軟件組織DevOps 轉(zhuǎn)型范例(如圖10 所示),我們需要對(duì)其中涉及到的DevOps 顧問(wèn)(咨詢師)、軟件組織的高層(管理者)、開(kāi)發(fā)團(tuán)隊(duì)(Dev)和運(yùn)維團(tuán)隊(duì)(Ops)這4 個(gè)角色進(jìn)行回訪.因?yàn)樵诓煌h(huán)境下,人的行為以及人與人之間的關(guān)系是不同的[8],所以回訪有助于了解不同環(huán)境中范例的適用性,以此來(lái)進(jìn)一步完善我們的范例.

5 總結(jié)

本文從文獻(xiàn)中識(shí)別出DevOps 自動(dòng)化支持工具的集合,根據(jù)一些中文博客對(duì)DevOps 自動(dòng)化支持工具在實(shí)踐中出現(xiàn)的實(shí)際問(wèn)題進(jìn)行了總結(jié),形成了3 個(gè)層次的問(wèn)題,并對(duì)這些問(wèn)題進(jìn)行具體的闡述.最后針對(duì)3 個(gè)層次的問(wèn)題,采用民族志研究中的訪談作為調(diào)研方法,對(duì)7 位專家和從業(yè)人員進(jìn)行了半結(jié)構(gòu)式的訪談,從中歸納出對(duì)DevOps 自動(dòng)化支持工具使用的建議.

本文的主要貢獻(xiàn)如下.

首先,我們通過(guò)系統(tǒng)化文獻(xiàn)評(píng)價(jià)獲得了DevOps 實(shí)踐中常見(jiàn)的自動(dòng)化工具集合.

然后,我們通過(guò)中文博客總結(jié)出在實(shí)際的DevOps 實(shí)踐中這些自動(dòng)化工具產(chǎn)生的問(wèn)題.多樣化問(wèn)題、聯(lián)系問(wèn)題和文化問(wèn)題這3 個(gè)方面的問(wèn)題能夠很好地覆蓋問(wèn)題的每一個(gè)方面.

第三,我們通過(guò)對(duì)DevOps 實(shí)踐中3 個(gè)維度的專家進(jìn)行半結(jié)構(gòu)式的訪談來(lái)獲取他們對(duì)于3 個(gè)方面問(wèn)題的看法和建議,這些建議能夠從不同的角度為軟件組織的DevOps 轉(zhuǎn)型提供幫助.我們也從專家們的看法中歸納出自動(dòng)化工具在實(shí)際的DevOps 實(shí)踐中的地位,我們從組織引入DevOps 的時(shí)間角度,把其分為前期和后期,前期我們認(rèn)為DevOps 實(shí)踐就是對(duì)自動(dòng)化工具的使用與理解,而在后期,軟件組織需要通過(guò)建立符合DevOps 價(jià)值觀的組織文化來(lái)減少對(duì)自動(dòng)化工具的依賴.

最后,我們建立了一個(gè)企業(yè)DevOps 轉(zhuǎn)型范例,試圖在專家建議的基礎(chǔ)上,為軟件組織提供更為明晰的轉(zhuǎn)型方向.