SharePoint Framework 基於團隊的開發(一)
部落格地址:http://blog.csdn.net/FoxDave
SharePoint Framework是新的用來構建SharePoint自定製的開發模型,它專注於客戶端開發並用熱門的開源工具gulp、webpack等進行編譯。這帶來的最大優勢是任何開發平臺的開發者都可以參與SharePoint自定製的開發。
SharePoint Framework由一些不同的包組成,這些包有各自的版本。例如GA版的SPFx由以下包組成:
- @microsoft/sp-client-base v1.0.0
- @microsoft/sp-core-library v1.0.0
- @microsoft/sp-webpart-base v1.0.0
- @microsoft/sp-build-web v1.0.0
- @microsoft/sp-module-interfaces v1.0.0
- @microsoft/sp-webpart-workbench v1.0.0
所以在專案開發中我們需要注意這些包是否引用到了我們要使用的正確的版本。在搭建新專案時,Yeoman生成器會從當前SPFx釋出版本中自動向包新增必要的引用,主要需要注意的是在更新時,每個包的版本是否有變化。
準備開發環境
關於開發環境的搭建部分,前面的文章已經介紹了,在此不再贅述。
構建SPFx開發環境
這裡所說的環境不包含之前提到的安裝元件部分,而是從整體上闡述開發環境應該是什麼樣子的,可以在哪些地方進行開發。
在過去,SharePoint開發者經常使用虛擬機器作為他們的開發環境,他們在上面進行開發除錯工作,以確保解決方案可以為特定的組織使用。開發者們會在他們的虛擬機器上搭建SharePoint環境,安裝SharePoint和補丁以保持和生產環境的一致。有些時候他們也會安裝額外的軟體來儘可能地匹配目標環境。
轉到開發雲解決方案之後,開發者不再需要在他們的開發機上執行SharePoint場環境,只需要雲環境的賬號並瞭解如何跟SharePoint互動就可以了。
SPFx專注於客戶端開發,再也不需要在開發機上安裝SharePoint環境了。專案需要的依賴框架和包都包含在了專案資料夾中,由專案指定。需要說明的是,SPFx更新很快,開發者必須確保使用的工具鏈和SPFx的版本是相一致的,上一篇也強調過這個問題。
共享的或個人的開發環境
SharePoint自定製範圍從直接向頁面新增簡單的指令碼到複雜的解決方案包。SPFx是專注於結構化和可複用的SharePoint自定製開發模型。在構建SPFx解決方案時,團隊裡的每名開發者使用他們自己的環境,通過原始碼控制系統進行程式碼共享以協同開發互不影響。
同時,進行SPFx開發降低了成本,可開發者可以使用市場標準的開發機器來構建SharePoint自定製解決方案;而不像傳統的方式可能需要有跟生產環境一樣消耗的開發機。
在宿主機器上開發
可能最簡單的選項就是在宿主機器上配置SPFx開發環境,即直接在宿主機器上安裝所有的工具和元件。如果你的團隊只開發SPFx相關的專案,他們可以在自己的機器上安裝Node.js;如果他們也開發其他的Node.js專案,那麼他們可以使用第三方解決方案如nvm來執行多版本的Node.js。
在進行SPFx開發時,開發者會安裝Yeoman和SharePoint Framework Yeoman generator,通常這兩個工具是全域性安裝的,且隨著SPFx的更新而更新。這樣在更新SPFx時,他們不得不解除安裝當前版本去安裝新的版本。更可行的方法是全域性安裝Yeoman,但是在本地既定的專案上安裝generator。
在宿主機器上開發的好處是軟體直接在上面執行,可以直接訪問CPU、記憶體和磁碟I/O,得到了更好的效能。
在虛擬機器中開發
在過去最常見的SharePoint開發者開發SharePoint相關解決方案的方式就是使用虛擬機器,開發SPFx解決方案時也可以採用這種方式。但是使用虛擬機器並不是沒有弊端。虛擬機器一般都很大,且需要使用強大的機器進行承載以達到期望的效能。而且,維護的成本也很高,開發者必須對自己的虛擬機器進行持續的系統更新,安裝不要的補丁。在一個團隊中,很難保證團隊所有成員的所有虛擬機器是一致的。從這個角度考慮的話,使用虛擬機器來開發SPFx解決方案很昂貴,開銷大且時間長。
使用Docker開發
介於在宿主機器開發和在虛擬機器開發的中間地帶,我們也可以使用Docker進行開發。這裡筆者不會過多地對Docker進行解釋,它是一個跟虛擬機器類似的軟體虛擬化技術,但是有一些區別。使用Docker映象最大的優勢是它比虛擬機器更容易建立、維護和分發,它們更加輕量級(一般只有幾百M),並且開發者可以在Docker中使用宿主機器中安裝的工具。
Docker容器執行了一個作業系統的虛擬例項(基於Linux)。用映象建立的容器中的所有軟體都是在容器中獨立執行的,只能夠訪問宿主機器共享給容器的檔案系統。在容器關閉時,所有在容器內對檔案系統的更改都會被丟棄。
更多資訊可以戳這裡。
相關文章
- 中小團隊基於Docker的devops實踐Dockerdev
- 4.20團隊開發第一天
- 團隊開發sprint 第一天
- git團隊開發流程Git
- 關於大搜車「無線開發中心」團隊
- 2024/5/21團隊開發
- Git 團隊協同開發Git
- 【Java】基礎_14_開發團隊排程系統Java
- 推薦一個基於.Net Framework開發的Windows右鍵選單管理工具FrameworkWindows
- core_framework —— 基於libev的輕量級lua網路開發框架Framework框架
- 敏捷開發團隊,最喜歡的開發工具 CORNERSTONE敏捷
- 敏捷開發團隊,最喜歡的開發工具CORNERSTONE敏捷
- Sharepoint 開啟發布功能的PowerShell
- 軟體工程團隊的基於領域的結構 - snaptravel軟體工程APT
- 【團隊建設】如何做好團隊開發中的 CodeReview(程式碼評審)?View
- 2024/4/19日團隊開發
- 2024/6/3日團隊開發
- 一杯茶的時間,上手 Git 團隊協作開發Git
- 前端資料模型Model,適用於多人團隊協作的開發模式前端模型模式
- 如何快速為團隊打造自己的元件庫(下)—— 基於 element-ui 為團隊打造自己的元件庫元件UI
- eBPF Cilium實戰(1) - 基於團隊的網路隔離eBPF
- Rust語言的核心開發團隊有毒 - HackMDRust
- 零基礎ASP.NET Core WebAPI團隊協作開發ASP.NETWebAPI
- 遊戲開發原理——手遊開發團隊與成本遊戲開發
- 如何有效地提升開發團隊的水平? - bravenewgeek
- [小團隊自動化] 基於Gitea打造一個屬於你自己的程式碼託管平臺Git
- 《新美妙世界》開發團隊訪談:「開啟一段全新的《美妙世界》之旅」
- 不再開發統一的定製化作業系統 Meta解散XROS團隊作業系統ROS
- 4.25日團隊開發第六天
- 4.26 團隊開發第七天
- 一個軟體開發團隊多少人合適? 大型團隊失敗是由於缺乏共識和溝通帶來的技術債務 -mfeather
- 區塊鏈dapp開發公司 | dapp開發技術團隊區塊鏈APP
- 《蔚藍》開發團隊公開遊戲新作《Earthblade》遊戲
- 如何用研發效能搞垮一個團隊
- 團隊專案一
- 團隊作業一
- 計算效率提升100倍以上,上交李金金團隊開發基於Transformer的大模型用於從頭算分子動力學ORM大模型
- 基於NET 6.0 封裝的 Fast.Framework封裝ASTFramework
- 團隊動力之團隊發展階段理論