前面的文章中介紹了，Devops的概念以及企業(yè)應(yīng)用Devops能夠帶來(lái)的好處，請(qǐng)參考文章：

DevOps究竟能給企業(yè)解決什么問(wèn)題

接下來(lái)我來(lái)介紹一下Devops要想實(shí)際落地，那么我們需要解決的問(wèn)題有哪些。我將從產(chǎn)品需求、開(kāi)發(fā)、測(cè)試、運(yùn)維的角度來(lái)分享Devops落地的實(shí)際經(jīng)驗(yàn)。

核心

部署流水線核心軟件開(kāi)發(fā)過(guò)程是一個(gè)將客戶或用戶的想法變成一個(gè)真實(shí)可用的特性的過(guò)程。部署流水線是這個(gè)過(guò)程中的一部分，是指軟件從版本控制庫(kù)到用戶手中這一過(guò)程自動(dòng)化的展現(xiàn)形式。這一過(guò)程包括編譯構(gòu)建、代碼檢查、上傳制品庫(kù)、測(cè)試和部署等，并且這些階段的執(zhí)行都應(yīng)該是自動(dòng)執(zhí)行的。自動(dòng)化帶來(lái)的好處是這個(gè)流程變得更快、可重復(fù)且更加可靠。部署流水線的核心是使用jenkins作為各個(gè)節(jié)點(diǎn)的串聯(lián)，然后在各個(gè)流程節(jié)點(diǎn)中使用一系列的工具來(lái)實(shí)現(xiàn)流水線的自動(dòng)化!如下圖所示：

13條經(jīng)驗(yàn)

產(chǎn)品需求

1.產(chǎn)品定義、里程碑規(guī)劃和用戶需求分析

可以使用影響地圖、用戶故事、看板等方法。

開(kāi)發(fā)

2.代碼預(yù)檢查

代碼預(yù)檢查就是在代碼提交到代碼庫(kù)之前對(duì)代碼進(jìn)行檢查，包括靜態(tài)檢查、Code Review、測(cè)試、編譯等多種方式。

3.技術(shù)債務(wù)管理

主要的技術(shù)債務(wù)包括：

沒(méi)有文檔或者跟版本不同步;

過(guò)時(shí)的架構(gòu)設(shè)計(jì);

需要重構(gòu)的代碼;

遺留代碼缺乏文檔和單元測(cè)試，無(wú)人能改，無(wú)人敢改。

注意：未實(shí)現(xiàn)的功能需求不屬于技術(shù)債務(wù)。

技術(shù)債務(wù)管理的核心是：在技術(shù)債務(wù)產(chǎn)生之前能避免則避免，不能避免的可以借助工具提前發(fā)現(xiàn)，對(duì)于發(fā)現(xiàn)的技術(shù)債務(wù)盡可能早的償還掉。

4.第三方組件管理

使用第三方組件，可以不必“重復(fù)造輪子”，節(jié)約了時(shí)間和精力，加快了軟件開(kāi)發(fā)的過(guò)程。第三方組件已經(jīng)是軟件開(kāi)發(fā)不可或缺的組成部分。然而，使用第三方組件并非易事。主要有以下幾方面的問(wèn)題：

組件會(huì)存在缺陷或安全漏洞;

組件的版本會(huì)過(guò)時(shí);

組件需要額外的維護(hù)成本。

通常對(duì)第三方組件管理需要關(guān)注以下兩個(gè)方面：

依賴掃描：能夠掃描出依賴存在的問(wèn)題，包括是否存在安全漏洞以及版本是否過(guò)時(shí)。

依賴管理：制定黑白名單，控制策略和影響范圍。黑名單指不允許使用的組件。白名單是可以使用的組件?？刂撇呗灾傅氖钱?dāng)發(fā)現(xiàn)組件有問(wèn)題時(shí)采取的措施，如阻斷，警告。影響范圍指的該控制策略的應(yīng)用范圍，如當(dāng)前系統(tǒng)，所有系統(tǒng)等。當(dāng)檢測(cè)到依賴組件中包含了黑名單中的組件，按照設(shè)置好的控制策略對(duì)該組件進(jìn)行處理，比如編譯失敗，郵件通知負(fù)責(zé)人等。

5.非功能需求的管理

非功能需求的實(shí)現(xiàn)是有成本的，而且它們之間可能彼此排斥，因此我們必須權(quán)衡利弊。比如，對(duì)安全性要求高的系統(tǒng)往往易用性就不會(huì)太好。在實(shí)際開(kāi)發(fā)中，考慮到系統(tǒng)的交付時(shí)間，系統(tǒng)的總成本，往往會(huì)根據(jù)非功能需求的實(shí)現(xiàn)難度，做出權(quán)衡。

6.API管理

API 管理就是有效管理企業(yè)內(nèi)部各服務(wù)提供的API 接口和對(duì)外暴露的共有接口，管理 API 接口的創(chuàng)建、測(cè)試、發(fā)布等生命周期，以及 API 接口的版本、并提供 API 開(kāi)發(fā)者門(mén)戶供開(kāi)發(fā)人員查看。服務(wù)的 API 接口在構(gòu)建時(shí)自動(dòng)地注冊(cè)到 API 管理平臺(tái)的 API Gateway 中，其他調(diào)用方可以通過(guò) API Gateway 訪問(wèn)這些接口提供的服務(wù)，并基于 API Gateway 進(jìn)行 API 的自動(dòng)化測(cè)試，保證 API 的正確性和健壯性。

7.配置管理

配置管理是指一個(gè)過(guò)程，通過(guò)該過(guò)程，所有與項(xiàng)目相關(guān)的產(chǎn)物，以及它們之間的關(guān)系都被唯一定義、修改、存儲(chǔ)和檢索。例如，可以基于 Git 的方式，在應(yīng)用程序部署時(shí)提供特定環(huán)境的配置文件，實(shí)現(xiàn)了代碼與配置的隔離，保證了代碼的唯一性。

8.持續(xù)集成

這里持續(xù)的意思并不是“始終，一直”，它的意思是“隨時(shí)”。比較恰當(dāng)?shù)念l率是：每當(dāng)有人提交代碼，同時(shí)集成一次。通常分為即時(shí)集成和定時(shí)集成。

即時(shí)集成：是指團(tuán)隊(duì)成員每次提交之后就進(jìn)行集成，并執(zhí)行編譯、構(gòu)建、自動(dòng)化測(cè)試等任務(wù)來(lái)檢查個(gè)人提交的代碼是否可用。這種集成方式要求執(zhí)行的時(shí)間要短，要快速反饋結(jié)果，因此只能執(zhí)行一些簡(jiǎn)單的測(cè)試。

定時(shí)集成：類似每日構(gòu)建(Daily Build)，是指每天定時(shí)(一般為晚上)自動(dòng)執(zhí)行一次集成過(guò)程，第二天將執(zhí)行結(jié)果發(fā)送給關(guān)系人。這種集成方式注重的是檢測(cè)的全面性和徹底性，對(duì)執(zhí)行時(shí)長(zhǎng)要求不高。

測(cè)試

9.測(cè)試數(shù)據(jù)管理

測(cè)試數(shù)據(jù)管理指對(duì)測(cè)試數(shù)據(jù)的自動(dòng)創(chuàng)建以及銷毀。主要包括驗(yàn)證業(yè)務(wù)基礎(chǔ)功能的少量測(cè)試數(shù)據(jù)和驗(yàn)證核心業(yè)務(wù)性能所需要的大規(guī)模測(cè)試數(shù)據(jù)。

10.自動(dòng)化測(cè)試

指對(duì)產(chǎn)品的UI測(cè)試、服務(wù)的接口測(cè)試以及代碼的單元測(cè)試通過(guò)測(cè)試代碼來(lái)實(shí)現(xiàn)。

運(yùn)維

11.實(shí)時(shí)監(jiān)控

將所有主機(jī)加入監(jiān)控，時(shí)刻掌握他們的狀態(tài)，一旦有指標(biāo)不正常，觸發(fā)器觸發(fā)告警，可通過(guò)微信、釘釘、郵件方式進(jìn)行告警.

12 日志收集

當(dāng)集群環(huán)境壯大之后，某一個(gè)模塊可能會(huì)部署多個(gè)節(jié)點(diǎn)，再登錄到機(jī)器上查看某一模塊的日志就變得很困難，通常可以通過(guò)elk來(lái)建立集中式日志收集系統(tǒng)，將所有節(jié)點(diǎn)上的日志統(tǒng)一收集，管理，訪問(wèn)。

13 環(huán)境管理

環(huán)境管理就是準(zhǔn)備部署環(huán)境的過(guò)程以及部署之后對(duì)環(huán)境的管控。既能保證準(zhǔn)備環(huán)境的快速和一致性，又使得部署后的環(huán)境能夠有效利用。一般環(huán)境分為，集成環(huán)境、測(cè)試環(huán)境\類生產(chǎn)環(huán)境和生產(chǎn)環(huán)境。如果想要高效管理各種環(huán)境，必須通過(guò)腳本實(shí)現(xiàn)環(huán)境的創(chuàng)建與部署工作，即一鍵部署。