自動化工具對中國DevOps實(shí)踐的影響*

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

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

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

1 研究背景

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

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

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

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

Fig.1 Knowledge system of DevOps圖1 DevOps 知識體系

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

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

2 研究方法

2.1 研究問題

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

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

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

研究問題2:目前的自動化工具在中國的DevOps 實(shí)踐中存在哪些問題?

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

研究問題3:自動化工具在中國的DevOps 實(shí)踐中存在的問題有哪些解決辦法?

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

2.2 研究方法

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

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

自2004 年Kitchenham 等人首次將系統(tǒng)化文獻(xiàn)評價(SLR)引入軟件工程以來[17],SLR 已成為軟件工程中一種重要的研究方法[18],在《DevOps 自動化支持工具調(diào)研》[19]中,李杉杉等人對DevOps 實(shí)踐中的自動化支持工具做出了系統(tǒng)化文獻(xiàn)評價,對DevOps 自動化支持工具的相關(guān)文獻(xiàn)進(jìn)行了檢索,本文按照報(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)注自動化工具在DevOps 實(shí)踐中的影響,只需要獲取學(xué)術(shù)界常見的工具集合,因此,我們對于文獻(xiàn)的選擇做出了更加嚴(yán)格的限制,在標(biāo)題、摘要和關(guān)鍵字中出現(xiàn)DevOps 和Tool 相關(guān)詞匯的文獻(xiàn)被篩選出來進(jìn)行數(shù)據(jù)抽取.最終,本文得到了50 篇DevOps 自動化支持工具的相關(guān)文獻(xiàn),對這50 篇文獻(xiàn)中提到的工具進(jìn)行抽取,得到一個DevOps 自動化支持工具的集合.

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

2.2.2 灰色文獻(xiàn)評價

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

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

2.2.3 民族志:訪談

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

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

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

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

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

Table 2 Outline of interview questions表2 訪談問題大綱

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

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

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

3 結(jié)果分析

3.1 針對研究問題1

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

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

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

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

3.2 針對研究問題2

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

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

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

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

3.2.1 DevOps 實(shí)踐中自動化工具的多樣性問題

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

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

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

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

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

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

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

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

3.3 針對研究問題3

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

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

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

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

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

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

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

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

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

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

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

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

Table 4 Recommendations for three dimensions of automation tools in support of DevOps表4 對DevOps 自動化支持工具3 個層次問題的建議

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

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

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

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

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

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

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

4 討 論

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

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

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

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

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

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

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

5 總結(jié)

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

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

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

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

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

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