持續集成交付的流水作業

最近和一位朋友討論持續集成、持續交付在企業的具體價值,和具體執行時的崗位要求,比較值得讓我們思考。

我看的持續交付(Continuous Delivery),主要實現一套自動化的軟件生產線,在生產線的開端,是程序員提交代碼,而生產線的產出物就是要交付的東西:

  • 如果企業是需要運營一個平臺的,交付的就是一個更新後的平臺;
  • 如果企業是交付APP的,最終交付的應該是發佈到市場上的APP;
  • 如果企業是做軟件產品的,刻錄到DVD上的,最終交付的可能是一個ISO文件。

能在整個交付的流水線的自動化,我們普遍相信能提高軟件的質量,因爲在中間的生產過程,都已經標準化了,不存在中間過程會因爲某種人爲的誤操作而導致錯誤,而往往這些錯誤都是非常嚴重而不容易發覺的。通常在開源項目裏,開發者人員流動是不能控制的,一套自動化的交付體系相當重要,它能大大降低入門的門檻。放在企業上,也應當如此。期望的結果是:一個開發者能以低成本的進入項目,能儘快爲企業創造價值。

把交付過程中一切能自動化的步驟都做到自動化,是整個持續交付的核心重點。

對於什麼崗位能完成這個自動化的生產線?因爲要完成一條自動化的軟件生產線,大概需要以下要求:

  • 在企業裏有一定權力調動資源
  • 對軟件開發流程熟悉,知道每個環節的輸入、輸出、難點
  • 熟悉產品的交付時使用的工具(maven, nexus/artifactory, scp, shell-scripting, make, msbuild之類)
  • 熟悉虛擬化技術(因爲有可能需要啓動一個虛擬環境做驗收測試後纔可以上線)
  • 熟悉配置管理工具,如puppet、chef、cfengine等
  • 對系統安全、保安方面有一定理解和執行能力(不能因爲某員工的惡意干預導致生產線出問題)

要單獨完成生產線自動化,需要有全面技術知識的全棧工程師,否則就需要一個DevOps團隊協作來完成。但是團隊協作相信沒有一個全棧工程師來做來的有效率。若要用一個團隊來做,也需要有個擁有多方面知識的協調牽頭的人領導纔會成功。

這樣涉及到另外的問題:如何找到這樣的人?在我的經驗裏,企業中人員的跨領域性是不夠的,我們通常看到的問題是 “這個不應該是我負責” 之類的迴應,內部提拔艱難重重。社會招聘,又因爲全棧工程師往往被標籤爲 “什麼都會、什麼都不會”,招聘對於面試考官的考驗更大。

面對老闆,自動化生產線沒有立即的回報,還有完成建立了自動化生產線後,這個人的價值是否就減退,甚至沒有價值了,成爲疑問。但是,工廠的生產流水線也會因着不同情況來改造,同樣我相信軟件交付會因着不同新的技術情況而有所調整,達到持續改進的境地。

以上說的是對持續交付流程建設上的人員要求。

我們也需要討論的是,是否所有系統架構都能做持續交付?怎樣的系統架構能更好的支持持續交付的模式呢?

舉個極端例子:如果系統架構是依賴關係模糊不清,一個簡單改動有可能導致系統崩潰的情況,這樣就算做了完美的持續交付流程,相信開發團隊也不會超過5人,因爲這樣造成了另外一種入門門檻,真正的創新和創造價值的部分,達不到規模效益。但是,運帷團隊就可能有幾十人,因爲要比較多的人手去救火。企業如果出現這種現象,相信距離死亡不遠了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章