坦白的講:世界上沒有哪一種工具可以像DevOps這麼神奇(或敏捷,或精益)。DevOps在開發和運營團隊之間創建了完美的合做與溝通,所以與其說這是一種神奇的工具,不如說是一種文化的轉變。ios
然而,團隊之間也擁有支持自動化和協做的工具及技術。常常有人問咱們在Atlassian時關於支持DevOps工做方式所用到的工具(除了咱們本身)。因此,我準備擬定一份購買指南,標明購買DevOps工具時所須要的東西而且告知您咱們團隊所用到的工具。web
儘管許多工具都能以這種或那種的方式在開發週期的各個階段發揮做用,但沒有一種工具能在每一個階段起到主要做用。因此,當咱們談及DevOps工具時,將其分解到各階段是頗有幫助的。我將其分解成:規劃、構建、持續集成、部署、運營以及持續反饋。api
視覺與設計方面達成協做bash
根據敏捷手冊中的內容,咱們推薦使用在規劃中容許您的開發團隊實現迭代的工具。這樣,您就能很快地從用戶那裏獲知狀況,並經過用戶反饋優化產品。尋找可以提供sprint規劃特色的工具。服務器
另外,優先考慮爲您的開發團隊持續收集用戶反饋,並加以組織造成可執行信息。尋找能夠支持「異步討論」的工具(若是您願意)。重要的是每一個人均可以分享並發表評論:想法、策略、目標、需求、路線圖以及文檔。架構
不要忘記整合。不管您決定將功能或項目開發到多大範圍,都應當將用戶想法列入您的開發列表。併發
咱們使用的工具:Confluence, HipChat,JIRA Softwareapp
開發的階段環境運維
雖然Puppet和Chef主要受益於運維,但開發人員經過工具來提供各階段的開發環境好比Docker。虛擬編碼和可支配的產品副本能夠幫助您完成更多工做。dom
一些奇怪的類路徑?Mave安裝忽然被損壞?基礎設施自動化意味着從新配置比修復的速度更快,也更可靠,這也意味着您能夠加快升級您的開發環境。
當整個團隊在相同配置的環境中工做時,「用本身的機器工做!」別開玩笑了,這是真的(如今就是在開玩笑)。
咱們使用的工具:Docker
基礎設施自動化
開發人員建立模塊化應用,由於模塊化應用更加可靠,易於維護。因此,爲什麼不將這種想法延續至IT基礎架構之中?
這很難應用到系統之中,由於他們老是在不斷變化。所以咱們經過代碼配置加以解決。配置代碼可應用於裸機,並將服務器恢復至基線水平。
它能夠存儲在版本控制系統中。可對其進行測試。歸入CI(持續集成)中。同行評審。您能夠對其進行命名。
當在代碼中對系統知識庫編譯時,題目文件和內部文檔變得不過重要。產生可重複的流程和可靠的系統。少說話,多作事。
咱們使用的工具:Bamboo, Bitbucket, Chef,Docker, Puppet
協做編碼
不須要等待董事會批准後再部署到生產環境中,您能夠經過「拉請求」進行同行評審,以提升代碼質量和生產量。
什麼是拉請求?「拉請求」能夠將您在資源庫發佈一個開發分支的變化告知您的團隊。隨後您的團隊能夠查看這個更改,並在將它們集成到主代碼行以前進行討論修改。
持續集成
持續集成就是天天都要對共享存儲庫中的代碼進行屢次檢查,而且每次都要對其進行測試。這樣,您能及時發現問題,在最初階段修復它們,並儘量早的向你的用戶展示新的功能。
因爲分支和合並的工做流程是時下比較流行的(這是理所固然的!),因此避免在多分支環境中運行CI的工具能夠保證在不下降開發速度的狀況下進行嚴格的測試。
尋找那些能夠自動將測試結果應用到開發分支中的工具,並在分支構建成功時爲您提供是否將其推送至master的選擇。除了這一點,您能夠經過一個簡單的集成從您的團隊溝通工具中得到實時警報。
咱們使用的工具:Bamboo, HipChat
自動化測試
從長遠來看,自動化測試的回報會隨着時間的推移經過加快開發和測試周期體現。而在一個DevOps環境中,最重要的是它的另外一個緣由:意識。
對於準備和支持開發構建工做,自動化測試的操做過程透明化以及完全性是很是重要的。與手動測試不一樣,自動化測試每次均可以保證誠信地執行且遵循相同的標準。它們還會生成報告和趨勢圖,以幫助識別高風險區域。
風險在軟件中是真實存在的,但您不能忽略您沒法預料的風險。幫您的運營團隊一個忙,讓他們和您一塊兒探究幕後是如何運行的。尋找能支撐牆板的工具,讓每一個人均可以參與項目的具體構建或部署結果的評論中。工具的額外加分特色是可以使在突擊測試和探索性測試中的相關操做更加容易。
咱們使用的工具:Bamboo, Bitbucket,Capture for JIRA
發佈儀表盤
軟件交付中壓力最大的部分之一是讓全部的變化、測試以及未發佈的版本信息部署到一個地方。任何人在發佈前經歷的最後一件事情是須要一個漫長的會議來報告狀態。這就是發佈儀表盤流行的地方。
尋找一個集成了您的代碼庫和部署工具的單一儀表盤工具。在一個地方對於你想尋找的關於分支,構建,拉請求和部署警告等信息提供高可視化。
咱們使用的工具:JIRA Software
自動化部署
沒有什麼神奇的方式可讓自動化部署工做於每一個應用程序和IT環境中。可是,使用Ruby或bash將Operations’runbook轉換成一個cmd-executable腳本是一種經常使用的啓動方法。良好的工程實踐是相當重要的。使用變量分解出主機名 – 爲每一個環境提供獨特的腳本或者代碼是無趣的(至少一半是無心義的)。建立實用方法或腳本以免代碼重複。而且同行審查您的腳本,執行完整性檢查。
首先嚐試自動化部署到您的最低級別的環境中,其中您將頻繁地使用自動化,接着複製全部的方式至生產環境。若是不出意外,此次練習強調了您的環境之間的差異,並生成一個標準化的任務列表。做爲獎勵,經過自動化,標準化部署減小了環境內部和之間「服務器漂移」。
像Puppet和Chef等配置工具減小了在標準化環境中的困難。而且有負載工具協助自動化部署。Atlassian公司本身的Bamboo支持逐步協調複雜部署,併爲每一個環境的歷史提供可視性。
集成了Puppet或Chef的HipChat容許您從聊天室控制部署。經過簡單搜索,您確定可以找到一種適合您且在運算內的應用程序。
咱們使用的工具:AWS, Bamboo, HipChat,Puppet
應用程序及服務器性能監控
應該對如下兩種類型實施自動化監控:服務器監控和應用程序性能監控
手動「「topping」一個盒子或經過測試接入您的API都對現場檢查是有幫助的。可是要了解趨勢和您應用程序(和環境)的總體健康情況,您須要7X24小時能夠監聽和記錄數據的軟件。
如您所想:這樣一種應用軟件是存在的。事實上有不少這樣的軟件。New Relic,Splunk和Nagios是最受歡迎的,並且可以知足這兩種類型的監控。尋找能夠與您的羣組聊天客戶端相集成的工具,以便將提醒信息直接發送給您的團隊羣或某事件的專屬羣。
咱們使用的工具:BigPanda,HipChat,HostedGraphite,Nagios,NewRelic,PagerDuty,Pingdom,Splunk
溝通與集羣
跨團隊溝通是實現文化轉變的第一步,聊天工具可促進它的實時性。不少聊天工具都有專用的羣,在這裏專家能夠對發佈在羣裏的事件及時跟進,並快速修正。
一樣重要的還有保持警戒,這樣能夠最大限度地維持正常運行時間。尋找一個可擴展和可集成監控工具的聊天工具,讓您不會錯過任何一個重要的服務降級警報。
最受企業喜好的是拓展他們本身以外的溝通。尋找一個能夠幫您及時通知用戶的工具,讓他們實時瞭解您的動態。
咱們使用的工具:BigPanda,DataDog, HipChat,NewRelic, PagerDuty,StatusPage
事件、變動和問題跟蹤
增進團隊之間協做的關鍵是確保他們能夠查看相同的工做。當事件被報告時發生了什麼?他們是否有聯接並追蹤軟件的問題?當發生改變時,他們是否與發佈相關聯了?
沒什麼比在不一樣的系統中進行事件和軟件項目追蹤更能阻礙開發與運維間的協做了。尋找那些使事件、變化、問題和軟件項目在一個平臺上的工具,幫助您快速識別並解決問題。
咱們使用的工具:JIRA Service Desk,JIRA Software
經過用戶反饋創造更好的產品
客戶已經告訴您,您是否創造了合格的產品——您只須要傾聽便可。這包括NPS數據、流失調查、bug報告、支持文件,甚至是事件推文。在DevOps文化中,產品團隊中的每一個人都可以查看用戶評論,由於他們爲一切從發佈計劃到探索性測試提供幫助指導。
尋找應用程序將您的聊天工具與您最喜好的調查平臺及集成用於收集NPS的反饋。Twitter和/或Facebook也能夠與聊天工具集成進行實時反饋。爲了更深刻的分析來自社會化媒體的反饋,一個可使用歷史數據得出報告的社交媒體管理平臺是很值得投資的。
分析並引入反饋在短時間內會感受可能減緩了發展步伐,但從長遠來看,它比發佈沒有人想要的新功能更有效。
咱們使用的工具:GetFeedback,HipChat,JIRA Service Desk,Pendo,Surveymonkey,HootSuite
Atlassian的工具可在開發生命週期的每一個階段提供跨團隊協做支持。正如您所看到的,咱們利用同行構建的插件和單機工具加強咱們的DevOps工具集。
在小公司裏,一個團隊可能負責整個開發生命週期。在大公司裏,是被各個部門承擔的。不管如何,DevOps都可以打破僵局,使這個生命週期更快、高度自動化以及無縫協做 - 不管是跨職能團隊仍是在一個團隊中。
首先是選擇正確的DevOps工具,最重要的是認真審視當前軟件和IT操做過程,並決定須要改進的地方。我但願這個清單能夠爲您指明正確的方向。