DevOps 影音特餐 – 團隊開發 Speed UP!(收錄 25 項免費資源)

MSDN 小編特別整理關於 DevOps 相關的文章與影片,總共收錄超過 25 種免費學習資源供大家使用!         DevOps 是目前火紅的話題之一。這個字是由 " Development " 與 " Operations " 合併而成。目的是要透過強調溝通 ( Communication ) 、合作 ( Collaboration ) 、整合 ( Integration ) 及自動化 ( Automation ) 等方式加強開發人員與運維人員還有其他包括質量控制等人員之間的合作。

0

「突破隔閡的高牆」了解DevOps 的基本概念

在傳統的開發週期,開發團隊會將軟體版本丟過這道牆給營運團隊,營運團隊撿起這些版本構件並開始準備他們的部署,手動處理開發者提供或是他們自己建立的部署指令碼。他們也編輯配置檔案來反映生產環境,而這與開發或 QA 環境有極大的不同。最好的情況是他們正在複製之前環境中已經做好的工作,最壞的情況是他們即將引進或發現新的錯誤。

0

微軟開發部門 DevOps 經驗談 (四) – 從使用者經驗中學習

本文接續: 微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps 微軟開發部門 DevOps 經驗談 (二) – 從經驗中學習 微軟開發部門 DevOps 經驗談 (三) – 為 DevOps 量身打造的系統 今天要來談的是如何從使用者經驗中學習。 從使用者經驗中學習 我們盡可能讓所有開發的功能,都能提供良好的使用者體驗,就算這是件相當困難的事。舉例來說,我們花了很多功夫讓服務達到 99.9% 的服務可靠度 (SLA, Service-level agreement),但我們並不因此而滿足。 我們的目標並不僅僅只是 SLA,而是希望提供 100% 完全沒有缺點的服務。這也代表著我們必須要對發生機率是 0.001% 的例外狀況斤斤計較。由於異常狀況經常會隱藏在監控的數據之中,我們甚至為此改寫了三次計算 SLA 的演算法,來讓我們的監控標準更加的嚴謹。參考下圖一,在一開始,我們使用外部進入測試,來判斷服務是否正常運行,如圖表中的虛線所示,我們的第二個演算法是觀察所有使用者進行的操作指令中,失敗和執行緩慢的數量比例,來判斷是否有功能發生異常,你可以參考圖表中的失敗和緩慢指令數量。在服務成長之後,由於使用者數量過多,也可能會讓問題被隱藏在相對大的系統數字之中,目前我們的作法是計算每分鐘遇到問題的使用者數量相對於每分鐘所有使用者數量,作為判斷系統是否有異常的指標,如圖中黑色現所示。 圖一、呈現了計算SLA的三種演算法,外部進入測試沒有找到任何的異常,追蹤指令執行狀況呈現了有一小時發生執行緩慢的狀況,而在使用者異常相對比例中更反映了有三小時的執行緩慢情形發生。 如同你所看見的,在四個小時的週期中,第一條虛線顯示沒有異常,第二條線顯示大約有一小時的異常,而第三條線卻顯示了有三個小時服務的效能是十分糟糕的。其實我們沒有必要這麼嚴格的設定線上數據觀察的機制,但我們為了提供給使用者更好的服務品質,對每一個數據都會更嚴格的要求自己。 注重安全性 在我們服務的其中一個安全標準中,要求了我們必須確保服務能夠保護使用者隱私,確保資料安全,在提供穩定服務的同時維持安全品質。以前我們開發地端版本的軟體提供給客戶使用時,就曾經在軟體的安全性上下了不少苦工,甚至會假設如果服務被入侵時,要怎麼自動偵測或判斷服務的安全受到了威脅。 除此之外,我們使用擴展單元來部署服務的方式帶來了一些額外好處,SU0 除了作為我們服務的第一個部署單元之外,還可以透過它來進行安全演習,強化驗證並我們服務的安全性。我們會使用這個擴展單元來舉辦一些類似“遊戲日”的活動,例如在內部舉辦安全性比賽,看看服務是否能夠抵禦入侵,而使用 SU0 更大的好處是不會影響正在使用我們服務的使用者們! 不同的部署方式 在我們開發地端版本提供給客戶使用的軟體時,我們花了十分多的精力調整開發系統和流程,想辦法讓客戶使用軟體遇到異常的時間降低,換句話說,由於產品提供給客戶之後,萬一客戶在使用時發生任何的異常或問題,要處理的成本都會變得十分的高,所以我們必須要在提供給客戶前就盡可能的降低問題發生的機率,避免我們常常要發行修正更新給客戶來解決異常,也避免造成客戶對我們的軟體有不好的印象。 DevOps 以及服務的雲端化改變了我們的思維,我們要考慮如何盡可能降低修復問題和重新部署到線上服務的時間,這也讓我們有了不一樣的目標,同時必須還要考慮修復問題、發現問題、找到原因以及學習改善根本原因的時間。 我們還想到在設計時必須多為了彈性做考量。線上服務可能會因為周邊相關的系統中斷而導致異常,尤其是在使用量尖峰時段很容易發生,但既然是線上服務,就必須將使用上的影響降到最低,並搭配對應的重試機制,例如使用 Circuit Breaker…

0

微軟開發部門 DevOps 經驗談 (三) – 為 DevOps 量身打造的系統

本文接續: 微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps 微軟開發部門 DevOps 經驗談 (二) – 從經驗中學習 今天要來談的是如何為 DevOps 量身打造系統。 Visual Studio Online 是一個全球性的服務,必須提供 24x7x365 服務不中斷,也保證擁有 99% 的可靠度,甚至還有財務擔保。雖然這些 SLA 上的保證並不是我們產品的最終目標,但為了要讓我們的使用者更安心的使用我們的服務,我們必須至少要提供這樣的穩定性。Visual Studio Online 並不會因為需要維護而有任何的停機時間,也不會發生任何需要重新安裝設定的事情,所有的新功能都是透過更新的方式上線的,過程也是全自動化。這也代表我們服務架構必須要是低耦合性,明確定義服務與服務之間的邊界、溝通方式,以及準確的控制要更新程式碼的版本。為了能夠瞭解客戶的需求,Visual Studio Online 也是運行在 Azure 上,我們完全透過 Azure 所提供的功能來建立這項服務。 自動化部署 我們的開發部門中有一個叫做服務部署 (Service Delivery) 的小團隊,專門處理網站部署工作,以及維持我們服務穩定運行,這個團隊簡稱為 SD。在每個 Sprint 結束後的星期一,SD 會使用 Visual Studio Release Management 來進行部署 (參考圖 1)。通常我們會在上班時間進行新版本的發行,這是因為上線後我們必須要觀察線上運作是否正常,萬一有問題也能即時發現並修正。由於…

0

微軟開發部門 DevOps 經驗談 (二) – 從經驗中學習

本文接續 微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps,今天要來談的是從經驗中我們學習到什麼。 適度控管分支讓開發更快速 在 2008 年,我們開發團隊剛開始使用 Agile 時,我們認為可以透過程式碼品質控管,以及版本控制系統所提供的分支 (branch) 功能等方式,讓程式碼維持高品質。剛開始的時候,我們版本控制系統中的分支都是經過精心規劃設計的,工程師開發完成後,必須要從主幹 (trunk) 取得最新的程式碼,將自己所開發的程式碼與主幹的程式碼合併,透過系統建置並且通過所有程式碼品質的檢查,確保開發的程式碼符合我們的規範之後,才能算是開發完成,可以把程式碼簽入 (check in) 到版本控制系統中。 但我們沒有預料到的是,過度的使用分支可能會造成開發流程上無謂的浪費。我們進行新功能的開發時,可能會因為在開發上遇到阻礙開發的事情,所花費的時間超過原本預期,導致開發中程式碼與主幹 (trunk) 太久沒有進行合併 (merge),讓程式碼落差越來越大。這個現象也產生了相當嚴重的合併 (merge) 債務,我們在不同分支的工作好不容易完成之後,卻發現原本主幹中的程式碼與建立分支時有相當大的落差,這是由於其他人在我們的工作進行時,也不斷的把所開發的程式碼加入到主幹之中,所以當我們開發完成要合併程式碼回主幹的時候,就會有大量的合併衝突 (merge conflics) 必須要解決。隨著我們的組織越龐大,分支越繁雜,這樣的情況也會越來越嚴重。 因此在 2010 年時,我們開始針對程式碼分支的規劃進行了改變,我們大量刪減了原本過於繁瑣的程式碼分支架構,只留下了少數幾個分支,而這些分支通常也只是暫時存在。我們同時明確的針對程式碼開發流程進行了改善,減少程式碼從主幹切出分支進行開發到合併回主幹讓其他人可以使用的時間。接著我們嘗試轉換目前所使用的版本控制系統,雖然我們大部分的客戶和合作伙伴都是使用中央化的版本控制系統,但我們仍然決定改為使用分散式的版本控制系統 (例如 Git),當然,Visual Studio Online 和 TFS 都有支援這兩種版本控制系統。使用 Git 的好處是它相當的輕量,並且由於分散式系統的特性,可以很輕鬆的在本地端建立暫時性的分支結構,不會影響原本遠端的分支,所以我們可以在任何需要的時候開啟新的分支,當完成工作並將程式碼合併回主幹後就把這個分支刪除,讓分支不會過多,管理起來更容易。 同時再搭配發送 pull-request 的工作流程,讓 Code Review 和程式碼品質控管可以同時完成,當 pull-request 中的程式碼內容被審核人員確認無誤之後,就會立即的合併回主要分支 (Master Branch),也就是原本的主幹之中,這讓我們程式碼開發流程是順暢且嚴謹的,而且由於每一個分支相當輕量,就比較不容易發生因為在分支上開發過久,開發人員必須花費相當大的精力保持與主幹的程式碼同步。 搭配這套流程可以把開發人員的工作週期相對的縮短,由原本冗長的開發時程,轉變為一個一個短週期的工作項目,也讓完成工作項目變得更加容易,並且隨時可以合併回主要分支中,達到一個更容易持續整合的循環,分支也不會因為離開主要分支過久,而有許多合併衝突要解決,一旦我們完成工作合併回主要分支後,所建立出來的分支隨時都可以刪除,讓分支的管理工作更容易進行。…

0

微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps

在 2013 年 11 月 13 日,我們正式發行了 Visual Studio 2013,以及全新的 Visual Studio Online 服務。但在服務發表之後,Visual Studio Online 卻發⽣了異常,造成七個小時服務中斷,這是因為在服務上線時,我們沒有預想到它會⾯臨如此大的流量衝擊,所以僅使⽤⼀個擴展單元(Scale Unit)來運行我們的服務,但在歐洲和美國的服務上線時,我們的系統遭遇了流量的頂峰,必須要同時提供服務給上百萬的使⽤者,系統不足以乘載這麼大量的使用者導致服務中斷。在技術上來說,這次的上線過程可說是⼀個⾎淋淋的慘痛經驗,就算我們擁有許多已經開發完成,但暫時透過功能開關(Feature flag)隱藏,等待著推出給使⽤者的新功能,卻無法監控服務與服務的網路層級問題,才會造成線上服務中斷,這些監控機制其實對我們來說才是最重要的,也因為這次的教訓,這些機制馬上被我們列入接下來的主要開發項目中。 圖一、 Visual Studio 2013 發表時, Visual Studio Online 因為過⼤流量造成的服務中斷,但在市場層⾯來說,這次的服務發表其實是非常成功的,因為 Visual Studio Online 的使⽤者每個月以成倍速度成⻑。(而且在接下來的一年中,使⽤服務的⼈數持續成⻑,已擁有超過兩百萬名使⽤者) 在新功能開發與線上維運中取得平衡 ⼀開始,Visual Studio Online 只有使⽤芝加哥資料中心的⼀個擴展單元(Scale Unit)提供服務。我們當然知道服務如果要能夠穩定運行,必須具備橫向擴展 (Scale out)到多個地區的能力,也要讓每個地區的部署可以獨⽴進⾏不互相干擾,但總是有更多重要的新功能等著我們開發,讓我們不得不將這些事情往後排。⽽在經過了 Visual Studio Online 上線時慘痛的教訓之後,我們決定推遲新功能開發,優先專注在提供穩定的服務上,我們調整了 Visual Studio Online 部署更新流程,改為使⽤循序漸進部署(Canary Release)⽅式。不變部署到芝加哥資料中心的動作,⽽是在部署到芝加哥資料中心之前,增加⼀個部署階段,稱之為 SU0 (Scale Unit 0)。 在新的流程中,每⼀個 Sprint…

0