logo头像

Edward.K Thinking

(學習DevOps系列 3) 為了DevOps的改變?

DevOpsDevOpsDevOps這一個詞大家現在越來越會講,市面上也越來越多關於這個名詞的書籍發表,但是,要做到DevOps是真的有這樣簡單嗎?早期,大多企業或是團隊要轉型成Scrum的敏捷式開發團隊,就已經是一件不易的事情,我認為要朝向DevOps之路邁進,這更是一條更不簡單的事情,況且,就如下圖,何謂DevOps,相信在不同場景或是企業,對這個詞也不一定相同。


是整個組織或團隊文化要轉向DevOps,是一件非常困難的事情。必須要有人或小組先行作為變革的推動者,引導組織DevOps成功之路。這樣的組織或人,必須對於企業組織的業務或是商業模式有一定程度的了解,並且連結可以解決這些問題的技術或是解決方案,並且搭配追蹤的一些量測指標進行驗證以及符合商業邏輯成果的方案,來逐步推進DevOps。


像是如果我們想要開始做一些自動化的流程或是模式,我們不應該對對我們的用戶或是老闆說

我們想要針對我們的佈署流程做自動化程式

基本這樣子的說法,對於一些stakeholders或是主管可能效益不大,甚至會被拒絕做此動作。或許可以從商業角度的方式去引導他們,讓我們開始做這樣的事情,或許改變說法引導它們,會讓DevOps觀念更容易落實。像是

當我們可以開始關注如何加快我們的佈署速度,我們將可以有更多或更快的時間減少問題或是完成商業需求,更快提供商業價值給你們。同時,若是,進行小批量項目的完成,我們可以快速測試便且進行驗證,並且從驗證中得到相對應知識和反饋,來推動下一次的業務進行。所以,借助DevOps,我們不僅可以更快的工作,了解我們正在開發的功能正確性或是可以在必要時候進行調整。最後,透過不斷反饋資訊進行修改來符合商業需求


通常要導入一個流程或是一個方式,尤其在一些企業內,必須把要執行的行動和最重要的需求建立某種程度關係,這樣要說服對方買單,將會是比較容易。像是,如果可以把技術架構和商業需求或是策略綁定,那樣將有助於克服其他人對於要推動DevOps的反對程度

Microsoft轉型DevOps


在先前一篇文章中借鏡微軟DevOps的轉型旅程 ,提到微軟轉型的一些做法,讓微軟從早期的Agile擴展到DevOps,在DevOps中,Backlog會來自一些實驗性的假設和產品的反饋,並透過這些持續性的反饋意見,持續改善。在微軟的DevOps中,藉由Agile發展過來的四個趨勢


以VSTS和TFS為例,在微軟的開發團隊,每次的Check In程式碼,將會驅動持續整合的流程,每三個Sprint後,將會把新功能發佈到VSTS上面,後面第四到第五的Sprint,將更新TFS。如下圖


這也就是為什麼TFS更新速度遠比VSTS慢的原因。


因此,當有了文化和組織的變革後,後續就是要怎樣採用相關技術和模式,讓DevOps落地和推動。最終,我們因該要知道為什麼需要推動DevOpsDevOps是為了解決甚麼問題而生。確定了這些方向和目的,才有DevOps有價值,不然最後只會徒增更過繁雜手續以及更多的技術債,反而對於組織並不好。最後,文化的改變才是DevOps起手式。

上一篇