今年三月微軟全球開發平臺事業部資深副總裁潘正磊訪臺,剛好有個空檔讓我跟她訪談。由於她是軟體工程師出身,在微軟總部帶領成員多達4千多位開發者的Visual Studio產品開發團隊,而且又是領導整個團隊實踐敏捷開發與DevOps流程的核心人物,有這個機會,我當然不會放過,於是,請教她當今最熱門的DevOps議題。

這幾年來,微軟的開發團隊已從傳統瀑布式開發模式轉為敏捷開發,以潘正磊帶領的Visual Studio團隊來說,開發步調從過去產品三年一次大改版的周期,加快為每三周就是一個Sprint周期,也就是一個小改版,而每個月的軟體組建(Build)次數亦高達22萬次。在這樣的規模與速度之下,潘正磊說,只有開發團隊自己做維運,也承擔維運的責任,才能交付高品質的軟體,而這就是DevOps的精神所在。

我接著問她一個問題:如果不是像微軟這麼大型的公司,特別是IT團隊成員普遍只有個位數的中小型企業,還適合做DevOps嗎?她卻回答我:就是像微軟這樣的大型企業,要推動DevOps才困難,小團隊反而容易得多。

這倒提醒了我,DevOps其實是源於新創網路公司。DevOps一詞可追溯到2009年歐萊禮Velocity大會上,網路相簿公司Flickr兩位工程師的講題:「10+ Deploys per Day:Dev and Ops Cooperation at Flickr」,他們分享如何在一天內執行10次以上的軟體部署,而其中一張簡報把Dev與Ops放在一顆愛心裏,觸動了開發者心弦,吹響DevOps的號角。(相關報導請參考:DevOps 2015大會專題報導)

一般來說,新創開發團隊的規模都不大,開發人員往往身兼多重角色,而網路服務的軟體更新又相當頻繁,在這樣的局勢下,自然而然,發展出對開發人員最方便也最快的作法:以程式做自動化測試、持續整合、自動化部署與持續交付等等,而且,他們也比其他開發團隊更早意識到,在敏捷開發的步調下,開發工程師(Dev)與維運工程師(Ops)緊密合作的必要性。

至於一般的企業,往往伴隨著公司業務成長,需要更多不同職能的人才,於是部門逐漸增加,分工日漸明細,這雖然是各司其職,卻也衍生出一些無形的阻礙,不知不覺中溝通效率變差了,本位主義作祟了,公司開始出現一道道隱形的高牆。

這種情況也會發生在IT部門,使得軟體開發的效率無法從源頭貫徹到服務上線。過去這幾年,有些企業已經開始採用敏捷開發方法,縮短開發周期,提升開發的速度與靈活度,並打掉開發團隊與需求端的高牆;不過,IT部門內還有一道立在開發與維運之間的高牆,使得在軟體開發至部署上線之間,仍有諸多障礙,大大影響軟體交付的速度與品質,而從新創網路公司濫觴的DevOps,就是打破這道牆的武器。

簡而言之,DevOps有兩大武器,分別是持續整合(Continuous Integration)與Infrastructure as Code,其中持續整合工具讓軟體開發、測試、組建(Build)等作業自動化,而如Puppet、Chef、Ansible這類自動化組態管理工具,則讓軟體部署作業自動化;兩者連貫起來,就打通了軟體開發以至上線的整串流程。

至於臺灣為數眾多的中小企業IT人員,往往也是開發與維運都得做,既要寫程式,也得架伺服器、設定網路,唯獨手上握有的資源可能不如網路新創公司。不過,中小企業的IT人員倒也不必絕望,最起碼你沒有大型企業難以處理的團隊問題,而現在又有許多如上述一流的開源工具,只要你學會善用DevOps的作法,站在巨人的肩膀上,小團隊說不定更容易出線。

作者簡介


Advertisement

更多 iThome相關內容