閱讀指南
開發環境的追求
部署方案的要求
大廠環境因素
整合環境因素,導出方案
展望未來
QA
首先我們強調一點,任何公司的技術基建都是隨時間推移去不斷改進和建設的,任何純技術輸出都必然存在它的邊界。而業務拓展、組織架構變遷、新興技術迭代等都是不斷發生的,這意味著技術基建必然也是不斷改進的。
拿整個互聯網來說,也是由“石器時代”不斷演變而來。
而一切解決方案都是為了針對某類需求。
開發環境的追求
作為團隊中的開發者一員,無疑要追求美好的開發體驗,具體可以列舉為:
高效的編譯速度
屏蔽環境搭建與配置,專注內容開發
團隊編碼規范的顯式約束
編碼質量的保障
各種運行環境的快速切換
與對應需求的綁定與關聯
部署方案的要求
部署成果的質量與穩定性保障
部署流程的快捷
高時效性的容災處理
整合環境因素,導出方案
除開以上普遍意義的需求,大廠本身的環境更是決定了解決方案的重要因素。 如阿里:
人員方面: 項目組眾多(開發者數量多)、分內勤和外包(開發成員之間代碼力差距相對較大);
技術方面:技術棧相對統一(主要是業務方面: JAVA-SpringCloud,JS-react,veex… ), 技術輸出明確劃分內網和開源。
資源方面:有錢任性,相對寬松。
結合以上,我們將需求映射成需要解決的問題:
在云IDE之前的年代里(包括現在大多項目組還是使用本地編譯器), 如何統一開發者的開發環境和規范?如何統一生產變量?(即如何確保本地打包環境統一,不會出現不同版本依賴或者丟包等打出預期之外的包)
說白了,這個問題可以簡化為: 如何抹平不同開發、生產環境的差異。
做部署流程的整合,提效。
來自阿里的答案
拿阿里的DEF工具舉例:
1、“研發套件”集成式腳手架
無論哪個項目組的業務開發,他們對于環境本身的配置其實大都是無感知的,以下圖為例
阿里的DEF工具,是通過對本地研發過程中進行總結收斂,抽象出初始化、編譯預覽、構建、測試、發布 這五個本地工具的通用功能節點。將原有的插件能力根據項目研發類型進行分類后,總結沉淀出每一類研發類型的標準本地工具 --研發套件。
借助套件概念的封裝,用戶在不同項目之間研發的時候直接通過統一的命令,就能完成項目研發對應工具服務的啟動使用。
門神
在DEF中集成門神(相當于提交代碼前后的鉤子,可類比git-hooks的功能),負責團隊開發規范的約束(lint,cr,其他插件任務等)。
云端IDE
而在這兩年里,云IDE開始嶄露頭角,整個開發環境遷移至云端,更是直接從根本上解決了開發環境差異的問題。
2、統一的研發部署平臺
說白了就是對于不同的項目,基于它們的技術選型進行宏觀的分類,枚舉出每一種類型的最佳部署體驗,集成到一個平臺。
讓用戶可以體驗“一鍵發布”的功能,而不用關心具體的部署細節配置。
3、DEVOPS平臺
比如上圖云效平臺,打通自產品需求-設計-開發-測試-發布-運維一條鏈路的流程管理平臺,高效提升效率。 關于DEVOPS的介紹這里就不再做其他贅述,不太了解的同學可以自行搜索一下。
4、展望未來
近年來,上云成了一種潮流,以云服務為核心擴展出的解決方案比比皆是。目前來看,云依然面向未來。 而隨著對AI領域的不斷探索,各大廠也大多有相關建樹。
但無論如何,基建方案與規模的決定因素,永遠在于業務與環境。
5、QA
Q: 大廠開發時和部署時類庫的引用和存放是一致還是不同?
A: 一般而言,我們要保障開發和生產環境的統一,以確保產出與預期一致。當然也有其他情況,這個要看項目本身有沒有不同的需求。 一句話,不要脫離業務講技術,更不要蓋棺定論。
Q: 模塊是放在項目中還是放在CDN之類的服務器?
A: 這個問題中“模塊”這個概念可能不太清晰。這里指的是前端吧,前后端分離的模式下,前端生產出的包都是靜態資源包,一般都是扔到CDN里嘛。
Q: 渲染網頁用的是nginx還是其他動態web服務器?
A: 還是那句話,不要脫離業務講技術,更不要蓋棺定論。舉個例子,某項目純node服務+SSR輸出網頁,本身就是一個web服務的項目何必再需要web服務器?
Q: 會選擇自己寫模塊還是在社區里找模塊?
A: 理論上來講,要盡可能的避免重復造輪子。在已有可信任的滿足當前需求的輪子的條件下,盡量不要自己造嘛,因為大家的工時都是很珍貴的。在保障不耽誤生產并且保障產品質量的情況下,為了能優化項目本身,也可以自己做嘛。
提倡做有意義的事,而不是多做事。
PASS: 對于以上所有問題哈————無論什么技術方案,其本身都不是絕對的,技術是為了服務業務的。
更多關于html5培訓的問題,歡迎咨詢千鋒教育在線名師,如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問,獲取試聽資格來試聽我們的課程,在線零距離接觸千鋒教育大咖名師,讓你輕松從入門到精通。