【51CTO.com快譯】在我們開始下面的討論之前，首先通過一張總圖來了解一下不同的工具，在DevOps生命周期中所處的位置。

DevOps生命周期階段

我敢斷言長期從事開發(fā)工作的您，一定對上述圖片并不陌生。那么，這是否意味著您能夠自如地使用各個階段的各種工具，而不會碰到任何問題呢?

本文將通過引導(dǎo)您遍歷DevOps生命周期中的各個階段，并向您介紹如何綜合使用多種DevOps工具，來解決各種現(xiàn)實問題。總的說來，我們在采用DevOps模式進行軟件與應(yīng)用程序開發(fā)時，通常會經(jīng)歷如下五個不同的階段：

• 持續(xù)開發(fā)
• 持續(xù)測試
• 持續(xù)集成
• 持續(xù)部署
• 持續(xù)監(jiān)控

1.持續(xù)開發(fā)

此階段涉及到對于軟件應(yīng)用程序基本功能的計劃與編碼。雖然對于計劃而言，并沒有什么可選的工具，但是可用于代碼維護的工具卻有不少。

通常情況下，項目的實現(xiàn)目標是在計劃階段被確定的。而當項目組成員開始著手編寫代碼時，就進入了所謂的編碼階段。

程序代碼可以用任何一種語言來編寫，但是我們需要配備相應(yīng)的版本控制工具予以維護。如今，在此類持續(xù)開發(fā)的DevOps工具中，受用戶歡迎的莫過于：Git、SVN、Mercurial、CVS和JIRA了。

那么，您是否真正理解保留代碼主要版本的重要性呢?讓我們從如下兩個方面來討論它對于開發(fā)與運營的影響吧：

• 只有各種版本(特別是存儲在中央存儲庫中)得到了管控，我們才能確保統(tǒng)一的可信代碼來源。在此基礎(chǔ)上，所有的開發(fā)人員都可以針對最新提交的代碼開展協(xié)作。同時，在計劃發(fā)布最新版本時，運營人員可以確保訪問到一致的代碼。
• 在發(fā)布過程中，如果出現(xiàn)各種意外，或是發(fā)現(xiàn)程序代碼中存在著嚴重的缺陷，以及功能性故障，那么運營人員就能夠從容且快速地回滾或恢復(fù)到，先前部署過的、已處于穩(wěn)定狀態(tài)的代碼版本上。

目前，大家普遍認可的工具是Git和GitHub(https://dzone.com/articles/git-vs-github-demystifying-the-differences)。其中，Git允許開發(fā)人員在分布式的VCS(版本控制系統(tǒng))上開展彼此協(xié)作。

另外，由于并不依賴于中心服務(wù)器，因此運營人員可以從遠程位置，對存儲庫進行各種拉和推式的操作。此處用于維護代碼的中央存儲庫，便是GitHub。可見，Git可謂是世界領(lǐng)先的版本控制系統(tǒng)之一。

2.持續(xù)測試

眾所周知，開發(fā)好的代碼是不能夠直接部署或發(fā)布到生產(chǎn)系統(tǒng)上的。我們應(yīng)當充分測試代碼的潛在錯誤和性能瓶頸。

通常，執(zhí)行測試的方式有兩種：效率低下的手動測試和高效快捷的自動化測試。如今業(yè)界普遍使用的便是自動化的方式，其中具有代表性的包括：Selenium、TestNG、JUnit/NUnit等工具，它們可以自動執(zhí)行各種用戶定義的測試用例。下面我們來看看此類工具的基本特點：

• 自動化測試節(jié)省了手動執(zhí)行各類測試的大量時間、精力和成本。
• 此外，生成報告是它們的一大優(yōu)勢。通過評估測試套件中有哪些測試用例失敗了，運營人員能夠更直觀地執(zhí)行各項任務(wù)。
• 此類測試也可以安排在預(yù)先指定的時刻被執(zhí)行。

顯然，我們應(yīng)該在DevOps生命周期中不斷嘗試各種工具，形成持續(xù)測試階段的習(xí)慣。如果您要問哪一款是我的最愛?我會告訴你：我會將它們組合起來使用。例如：我會用Selenium進行自動化測試，由TestNG生成報告，進而使用Jenkins觸發(fā)持續(xù)集成。

3.持續(xù)集成

這個階段可謂DevOps最為出彩的部分。它在第一次發(fā)布過程中，就發(fā)揮了重要的作用。它能夠最大限度地促進持續(xù)集成工具與配置管理工具的聯(lián)合部署。

毫無疑問，如今市面上最受歡迎的持續(xù)集成工具便是Jenkins。當然，其他流行的CI工具還是Bamboo和Hudson。

持續(xù)集成工具的主要功效在于：它能夠通過協(xié)調(diào)其他DevOps生命周期階段的自動化工具，將整個DevOps結(jié)構(gòu)完整地保持在一起。也就是說：無論是持續(xù)開發(fā)、測試或部署工具，還是持續(xù)監(jiān)視工具，或是持續(xù)集成工具，都可以與CI工具全面集成。

• 在與Git/SVN集成后，Jenkins可以自動化地安排諸如：從共享存儲庫中提取代碼之類的作業(yè)，并使其為構(gòu)建和測試做好準備(即持續(xù)開發(fā))。Jenkins可以被設(shè)置為在某個預(yù)定的時刻，或是有提交被推送到中央存儲庫時，觸發(fā)構(gòu)建作業(yè)。
• 與Selenium等測試工具集成后，我們可以實現(xiàn)持續(xù)測試。通常，我們可以使用Maven/Ant/Gradle之類的工具，來對已開發(fā)的代碼進行構(gòu)建。此后，Selenium可以通過創(chuàng)建一組測試用例，以及逐個執(zhí)行這些測試用例，來自動執(zhí)行各種代碼。在整個過程中，Jenkins/Hudson/Bamboo的角色就是自動化計劃。
• 與持續(xù)部署工具集成后，Jenkins/Hudson/Bamboo可以通過配置管理，以及容器化工具來觸發(fā)部署計劃。
• 另外，Jenkins/Hudson可以與Splunk、ELK、Nagios或NewRelic等監(jiān)控工具相集成，進而對那些已部署的服務(wù)器狀態(tài)和性能提供持續(xù)監(jiān)控。

4.持續(xù)部署

在討論了從頭開始構(gòu)建代碼的工具、以及測試類工具之后，我們現(xiàn)在來一起看看配置管理工具或容器化工具。這兩套工具都有助于在DevOps中實現(xiàn)持續(xù)部署(CD)。實際上，持續(xù)部署是軟件項目的實際落地階段。

目前，配置管理工具具有如下特點：

• 通常，配置管理需要在應(yīng)用程序的功能需求和性能中，建立和維護一致性的行為。簡而言之，它是將部署發(fā)布到服務(wù)器上，調(diào)度所有服務(wù)器上的更新，以及保持所有服務(wù)器上一致性配置的行為。
• 業(yè)界常用的此類工具有：Puppet、Chef、Ansible、以及SaltStack，其中最好的當屬Puppet。這些工具都是基于主-從(master-slave)架構(gòu)的。當有新的部署被發(fā)送到主服務(wù)器時，這臺主服務(wù)器負責在所有從服務(wù)器之間復(fù)制此類變更。

下面我們看看容器化工具：

作為一套工具集，容器化工具可以協(xié)助運營人員在開發(fā)、測試和部署應(yīng)用程序的環(huán)境中，保持一致性。通過對那些在開發(fā)/測試/階段性環(huán)境中頻繁使用到的相同依賴項和程序包進行打包與復(fù)制，容器化工具大幅消除了生產(chǎn)環(huán)境中各種錯誤與故障的可能。

Docker是最早也是久負盛名的容器化工具之一。過去，由于開發(fā)人員使用到了各種虛擬機與服務(wù)器，因此他們必須通過手動管理，才能保持生產(chǎn)環(huán)境狀態(tài)的一致性。如今，有了Docker容器的協(xié)助，大家能夠輕松地實現(xiàn)一致性的自動化保持。

近年來，許多云端應(yīng)用的解決方案，都開始為容器服務(wù)提供支持了。其中，Amazon ECS、Azure容器服務(wù)和Google容器引擎，都能夠?qū)ocker容器提供原生的云服務(wù)支持。這也就是Docker能夠廣為普及的原因之一。當然，其他類型的容器化工具還有：Vagrant。

5.持續(xù)監(jiān)控

如果我們不對應(yīng)用程序的性能進行監(jiān)視，那么開發(fā)和部署應(yīng)用還有什么意義呢?就算是再全面的測試，也難免疏漏掉一些潛在的錯誤或性能問題，因此，持續(xù)監(jiān)控與應(yīng)用開發(fā)同等重要。

目前，屬于此階段的流行監(jiān)控工具有：Splunk、ELK Stack、Nagios，Sensu、NewRelic。它們與Jenkins結(jié)合使用，可以讓運營人員達到持續(xù)監(jiān)控的目的。總的說來，持續(xù)監(jiān)控工具的必要性在于如下兩個方面：

• 由于程序的缺陷會給服務(wù)提供方造成財務(wù)上的損失，因此我們需要通過持續(xù)監(jiān)控，來最大程度地減少功能性錯誤所出現(xiàn)的頻率和帶來的后果。
• 監(jiān)控工具可以在用戶普遍碰到故障，并產(chǎn)生不良使用體驗之前，及時報告故障或服務(wù)水平的驟降。

Splunk和ELK堆棧是該領(lǐng)域的兩大工具，它們之間有著競爭關(guān)系。它們雖然能夠提供幾乎相近的功能，但是具體提供的方式卻不盡相同。

Splunk是一款非常容易上手的商業(yè)工具。而ELK堆棧則是由ElasticSearch、LogStash和Kibana三種開源工具組合而成。雖然可以免費使用，但是ELK設(shè)置起來卻不像Splunk那么容易。我建議您親自試用一下這兩款工具，以選擇更適合自己項目的一款。

原文標題：How To Combine DevOps Tools Together To Solve Our Problems，作者：Sahiti Kappagantula

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】