近年來(lái)，得益于容器技術(shù)與微服務(wù)架構(gòu)的蓬勃發(fā)展，在敏捷模型基礎(chǔ)之上，開(kāi)發(fā)和運(yùn)維協(xié)同工作的 DevOps 模式應(yīng)運(yùn)而生。
事實(shí)上，DevOps 這個(gè)理念并不是憑空出現(xiàn)的，它來(lái)自于傳統(tǒng)制造業(yè)的 “精益” 思想，最早出自豐田汽車(chē)企業(yè)文化中的 “精益制造” 理念。早于 DevOps 出現(xiàn)的敏捷開(kāi)發(fā)，也借鑒了這種精益制造的思想。
雖然二者都來(lái)源于精益思想，但敏捷開(kāi)發(fā)和 DevOps 的側(cè)重點(diǎn)各有不同。敏捷開(kāi)發(fā)更偏向于解決開(kāi)發(fā)側(cè)，即研發(fā)過(guò)程中的問(wèn)題；而 DevOps 則在敏捷開(kāi)發(fā)的基礎(chǔ)上延伸到了運(yùn)維的領(lǐng)域，且隨著行業(yè)理解的加深，DevOps 覆蓋的范圍在不斷擴(kuò)展。
DevOps 是一系列軟件開(kāi)發(fā)實(shí)踐，強(qiáng)調(diào)開(kāi)發(fā)人員（Dev）和運(yùn)維人員（Ops）之間的溝通合作，通過(guò)自動(dòng)化流程，使軟件構(gòu)建、測(cè)試、交付更加快捷、頻繁和可靠。這種開(kāi)發(fā)模式的特點(diǎn)是可以把產(chǎn)品的每個(gè)迭代，或者每修復(fù)一個(gè)線上缺陷就立即部署到生產(chǎn)環(huán)境，這樣一來(lái)，開(kāi)發(fā)者就能夠迅速?gòu)挠脩籼帿@得反饋并且快速做出響應(yīng)。
持續(xù)集成、持續(xù)交付和持續(xù)運(yùn)營(yíng)
DevOps 強(qiáng)調(diào)持續(xù)集成和持續(xù)交付，也就是我們常說(shuō)的 CI/CD。近年來(lái)還興起了持續(xù)運(yùn)營(yíng) CO 的概念。
持續(xù)集成早在 DevOps 概念誕生之前就已經(jīng)存在。當(dāng)時(shí)人們所說(shuō)的持續(xù)集成主要是指代碼的集成，因?yàn)樵诙嗳碎_(kāi)發(fā)的場(chǎng)景下，每個(gè)人對(duì)代碼的改動(dòng)都會(huì)對(duì)主線產(chǎn)生影響，解決代碼集成問(wèn)題成為了很多代碼版本管理工具關(guān)注的重點(diǎn)。
持續(xù)交付在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到更貼近真實(shí)運(yùn)行環(huán)境的「類(lèi)生產(chǎn)環(huán)境」中進(jìn)行更多的測(cè)試，如果代碼沒(méi)有問(wèn)題，則可以繼續(xù)部署到生產(chǎn)環(huán)境中，實(shí)現(xiàn)持續(xù)部署。
持續(xù)運(yùn)營(yíng)則是 DevOps 理念進(jìn)一步從研發(fā)、運(yùn)維延伸到業(yè)務(wù)領(lǐng)域的概念。當(dāng)我們給客戶交付的價(jià)值需要衡量體現(xiàn)時(shí)，例如一款 ToC 的軟件產(chǎn)品，衡量它的點(diǎn)擊率、用戶使用率、用戶粘性等數(shù)據(jù)，將這些來(lái)自用戶側(cè)的反饋與研發(fā)、運(yùn)維流程結(jié)合起來(lái)，就是 DevOps 延伸到運(yùn)營(yíng)階段的體現(xiàn)。
變更管理和配置管理
通俗地說(shuō)，DevOps 實(shí)際上是一種新的研發(fā)管理方法論。無(wú)論是在傳統(tǒng)開(kāi)發(fā)模式還是 DevOps 模式中，人們最關(guān)注的是變更管理和配置管理。
變更管理囊括了公司架構(gòu)層面對(duì)整個(gè) IT 部門(mén)的變更請(qǐng)求管理，例如員工的軟件需要重新安裝、域名指向變更、服務(wù)器配置變更、增加新的服務(wù)器等等，這些都屬于變更管理需要考慮到的。在 DevOps 流程中，提倡將傳統(tǒng)流程里需要人工處理的變更請(qǐng)求改為自助服務(wù)，即建立一套完整的自動(dòng)化流程來(lái)處理這些變更請(qǐng)求。
配置管理則是對(duì)變更管理在技術(shù)層面的支撐。當(dāng)變更管理涉及到配置項(xiàng)的變更時(shí)，在技術(shù)層面就涉及到配置項(xiàng)的識(shí)別，然后對(duì)配置項(xiàng)的版本進(jìn)行管理，并在變更的過(guò)程中進(jìn)行審查，確保整個(gè)系統(tǒng)配置版本的統(tǒng)一。
綜上所述，我們也可以說(shuō) DevOps 是應(yīng)對(duì) “變化” 的藝術(shù)。如今的市場(chǎng)要求研發(fā)團(tuán)隊(duì)進(jìn)行快速迭代、快速上線，這就涉及到軟件版本的頻繁變更，變更管理和配置管理在其中的重要作用不言而喻。這就引出了我們衡量一個(gè) DevOps 實(shí)踐是否成熟的四大核心度量指標(biāo)，即部署頻率、服務(wù)恢復(fù)時(shí)間、變更失敗率和變更前置時(shí)間。
當(dāng)我們?cè)谔暨x合適的 DevOps 工具時(shí)，就要結(jié)合這些工具能否提升以上指標(biāo)來(lái)做出選擇。
如何選擇合適的 DevOps 工具
面對(duì)如此之多的工具，研發(fā)團(tuán)隊(duì)在進(jìn)行技術(shù)選型時(shí)往往會(huì)面臨一些困擾。那么我們究竟應(yīng)該如何選擇這些琳瑯滿目的開(kāi)發(fā)工具，從而組成一個(gè)高效的 DevOps 工具鏈呢？
根據(jù)企業(yè)的投入和研發(fā)實(shí)力，目前在業(yè)內(nèi)部署 DevOps 工作流的方式可以分為兩種類(lèi)型。一種是 DIY DevOps，即企業(yè)自研或基于開(kāi)源的 DevOps 基礎(chǔ)設(shè)施工具進(jìn)行私有化部署，再根據(jù)自身需求研發(fā)相應(yīng)的擴(kuò)展組件。
這種方式能夠根據(jù)復(fù)雜的業(yè)務(wù)需要定制更符合企業(yè)自身需求的開(kāi)發(fā)環(huán)境，但需要企業(yè)具備一定的研發(fā)實(shí)力，擁有熟悉 DevOps 建設(shè)方法論和實(shí)踐經(jīng)驗(yàn)的高端人才，投入的人力成本較高。
另一種是采用市面上較為成熟的一體化 DevOps 平臺(tái)，適合研發(fā)資源不足、業(yè)務(wù)場(chǎng)景不那么復(fù)雜的企業(yè)用戶。這種模式的好處是不需要企業(yè)從零自建 DevOps 團(tuán)隊(duì)，可以快速體驗(yàn)平臺(tái)工具自帶的優(yōu)秀 DevOps 實(shí)踐，降低人力成本的投入。
其中，由飛算自主研發(fā)的 SoFlu 軟件機(jī)器人作為輔助開(kāi)發(fā)工具，從后端、前端、測(cè)試到運(yùn)維等環(huán)節(jié)幫助企業(yè)研發(fā)團(tuán)隊(duì)落地 DevOps，實(shí)現(xiàn)自動(dòng)化開(kāi)發(fā)，對(duì)于業(yè)務(wù)主要采用 Java 技術(shù)棧的團(tuán)隊(duì)來(lái)說(shuō)具有極高的性價(jià)比。
SoFlu 軟件機(jī)器人首發(fā)于 2020 年 11 月，通過(guò)后端全自動(dòng)開(kāi)發(fā)平臺(tái)，率先實(shí)現(xiàn)了 Java 后端的全自動(dòng)開(kāi)發(fā)。用戶只需輸入流程圖，平臺(tái)就能夠自動(dòng)生成通過(guò)實(shí)踐驗(yàn)證的微服務(wù)打包文件，并可直接部署到服務(wù)器上，大大降低微服務(wù)部署運(yùn)維的門(mén)檻，由此節(jié)省大量時(shí)間和人力。工具的屬性也意味著用戶可以將 SoFlu 軟件機(jī)器人生成的代碼部署在任何平臺(tái)。
產(chǎn)品發(fā)布后，為了更全面地滿足軟件自動(dòng)化開(kāi)發(fā)需求，SoFlu 軟件機(jī)器人還上線了前端全自動(dòng)開(kāi)發(fā)平臺(tái)，提供可視化開(kāi)發(fā)模式，通過(guò)豐富的頁(yè)面控件和對(duì)后端接口聯(lián)調(diào)的簡(jiǎn)化，極大地提高了前端開(kāi)發(fā)效率。
除了為開(kāi)發(fā)者提供前后端自動(dòng)化開(kāi)發(fā)工具外， SoFlu 軟件機(jī)器人還推出了全自動(dòng)測(cè)試平臺(tái)和全自動(dòng)運(yùn)維平臺(tái)，為企業(yè)研發(fā)團(tuán)隊(duì)提供覆蓋軟件研發(fā)全流程的自動(dòng)化工具，更高效地應(yīng)對(duì)頻繁迭代、頻繁部署的 DevOps 研發(fā)模式。
當(dāng)然，以上兩種類(lèi)型的 DevOps 部署方式并沒(méi)有好壞之分，不同企業(yè)還是應(yīng)該根據(jù)自身的業(yè)務(wù)場(chǎng)景和需求采用適合自己的 DevOps 部署方式。
最后值得一提的是，技術(shù)沒(méi)有銀彈。DevOps 并不是解決所有問(wèn)題的萬(wàn)能鑰匙。總而言之，為了 DevOps 而 DevOps 并不可取，大而全的框架不一定適合每一個(gè)團(tuán)隊(duì)，貼合自身需求的工具和模式才是最好的。
