2020年2月29日 星期六

Azure DevOps in Action - 專案的相依性管理與套件的使用


近代軟體開發大多以套件或框架為基礎,不管你採用哪一個語言。最近這五年,我們在專案的相依性管理上已經有了很大的成熟度和改變。如果你回憶十幾年前的軟體開發,可能常常看到專案中有底下這樣充滿相依性的設計:

說明一下,在上圖中,WebBMI.sln內共有三個專案,HealthMgr(上圖A)它是一個類別庫(Class Library),而HealthMrgTests是該類別庫的UnitTest,WebBMI則是Web UI的主程式(上圖B)。

由於主程式中使用到了HealthMgr,因此它是相依於HealthMgr的,也就是說,主程式在建置時,必須要參考到HealthMgr內的一些類別與方法。

如果你開啟Visual Studio來看會更清楚:

Visual Studio 2019本身有著很好的相依性檢視工具,你可以看到主程式WebBMI相依於同一個.sln中的HealthMgr,而且是以專案形式相依,這點是我們不喜歡的。

目前,WebBMI以『加入參考』的方式:

把同一個.sln中的HealthMgr給加入到WebBMI當中:

這雖然讓WebBMI可以輕鬆的使用到撰寫於HealthMgr內的類別和方法,但這是很古典的作法,不能說不好(如果把HealthMgr內的類別直接全寫在WebBMI主程式中可能更不好),但最近幾年我們已經不再鼓勵開發人員這樣作了。

最主要的原因有幾點:

第一, 這使得WebBMI這個Project在Build的時候,非得跟HealthMrg專案綁在一起,兩者無法分割,形成高相依性。兩三個專案你看起來還好,但我就看過.sln的solutions中有近百個專案的。

第二, 如果HealthMrg專案又被另一個B專案所參考使用,未來很可能造成潛在的版本衝突。例如,當WebBMI專案因為某些理由,必須修改HealthMrg專案中某個類別的運算邏輯,但因為除了WebBMI專案之外,B專案同時也在使用HealthMrg中同一個類別,導致若修改了HealthMrg就會與B專案不相容,不改又不符合WebBMI新的需求,進入兩難的狀況。

砍斷針對專案的相依

因為前述的原因,近代在我們作軟體開發時,幾乎都已經不會再如同過去這樣,直接對某一個專案作參考(reference),造成專案之間的潛在相依性衝突,而是改為針對套件(Package)的相依。

砍斷對專案的相依,改成對套件相依有許多好處,我們可以把前面講到的HealthMrg專案,建立成一個副檔名為HealthMrg.nupkg這樣的套件,然後把主程式(WebBMI.csproj)對HealthMgr專案的參考,改為對HealthMrg.nupkg套件的參考。

由於HealthMrg.nupkg套件本身可以有多重的版本機制(例如HealthMrg.1.0.1.nupkg , HealthMrg.1.0.2.nupkg這樣),每一次當套件需要修改,我們只需要增加版號即可。

如此一來,就算同時有多個專案參考到同一個套件,因為套件有版本可以區分差異,所以無須擔心A, B兩個專案同時參考了HealthMrg這個套件後,HealthMrg需要更新時該怎麼辦的問題。

也因此,近代軟體設計中,只要可能被其他專案參考使用的類別,我們幾乎都會設計成套件的形式,這也讓套件庫這樣的機制開始盛行,Node.js開發有NPM、python有pip、.net開發則是Nuget。

為了確保使用到套件的應用程式可以正確執行,所有的套件都必須維持恆定性,也就是套件一但上架後是不能修改、不能刪除(只能下架隱藏)的,如果有修改,就必須對套件作版號上的增添。這也是你會看到套件都有這樣的版號的原因:

HealthMrg.1.0.1.nupkg

HealthMrg.1.0.2.nupkg

HealthMrg.2.1.1.nupkg

HealthMrg.2.2.1.nupkg

一般來說,版號會遵循著業界的規則。

例如,HealthMrg.3.2.5.nupkg這個套件其中的3是Major, 2是Minor, 5是Patch:

舉凡Major版號有所變更,例如從2升到3,大多表示新版(3.x.x)將與舊版(2.x.x)有相當大(大到不相容)的改變。因此,當我們看到自己專案中所採用到的套件升級了Major版號的時候,一般也意味著必須留意升級後相容性的議題。

而Minor版號的變更,則大多是在維持相容性的前提下,所作的套件功能擴充或修改。而Patch則多是bug fix,或是某些與新功能無關的套件修正或調整。

這個版號是業界對於套件建立與開發的習慣,遵循這樣的版號機制,可以讓套件的開發者與使用者在同一個基礎上順暢的合作。

在.net core專案中建立nuget套件

對於套件有一定的認識之後,我們就實際來建立一個套件。打開Visual Studio 2019建立一個.net core的類別庫:

或乾脆使用我在Azure DevOps上公開的Repo,其Clone位置如下:

https://mytestaz400@dev.azure.com/mytestaz400/SampleCode/_git/dotNetCoreBMISample

你可以直接建立一個Azure DevOps專案,然後在repo中Clone上面這個現有的Project。

開啟後,你會發現,其中有一個HealthMrg專案:

這個類別有一個Calculate方法(上圖A)我們會在WebBMI的主程式中使用到:

參考上圖A,你會看到這是以.net core的razor page所撰寫的主程式,其中呼叫到了HealthMgr類別中的Calculate方法,用來計算BMI。這是因為在這個主專案中我們透過『加入參考』的方式,參考了同一個.sln方案中的HealthMgr專案,之前說過,這是傳統的作法,而現在我們要改成以Nuget Package的方式參考。

我們來到了HealthMgr專案的屬性視窗:

你會發現,在.net core/.net standard的類別庫(Class Library)專案上,想要讓某一個類別庫專案建置為nuget套件非常、非常容易,只需要在上圖的畫面中打一個勾即可。

當專案勾選了『建置Nuget套件』後,在Build這個類別庫時,就會自動建置出該組件(.dll)的nuget套件。

若你開啟產生出的nuget套件,可以看到:

包含該.dll的nuget套件就這樣被自動的建立出來了。

將套件上傳到Nuget.Org

建立好Nuget套件之後,我們得讓原本主程式WebBMI改為對套件參考,而非對專案參考。因此,我們必須先把建置好的套件發佈到套件庫裡面。

套件內的程式碼常常會被視為企業資產的一部分,所以一般來說,企業應該要針對自己開發的套件作為一個Private的套件庫,而非上傳到開放存取的Nuget.Org[1],以避免全世界都來共享你的開發成果。

要建立一個Private Nuget也不是太難,但更方便的是Azure DevOps裡面已經具有內建的套件庫,位於Artifacts:

不過,我們後面再來談這個部分。我們先來看,如果要把套件上傳到Public的Nuget.org該如何作?

開發人員只需要具有Microsoft Account,就可以透過Single Sign On的方式,登入Nuget.org(人人可開發套件的概念):

登入後,最簡單的方式,是透過Upload Package選單來上傳你開發好的套件:

在右上角登入的個人選單底下,選取Upload Package(上圖A),就可以進入上傳畫面,然後選取你要上傳的組件直接Upload即可。

不過要請留意,你的套件ID不能跟其他人的相同,且每一個套件的同一個版本,也只能上傳一次,否則就會出現底下的錯誤訊息(下圖A):

所以,如果你是Clone本文中前面提到的專案,你必須修改套件名稱和版號,才能夠上傳的上去nuget。由於我是HealthMgr這個套件的作者,因此我可以上傳id為HealthMgr的套件,只需要修改版號即可:

在上圖中我們把版號改成1.1.10,Visual Studio會自動建置出名稱為『HealthMgr.1.1.10.nupkg』的套件。

取得套件後我們將其上傳:

上傳後你會看到該套件會先被自動檢查,並且nuget會為其建置索引,一段時間後(大概十幾分鐘到一小時),該套件的狀態(Status)就會變成Listed,這意味著剛才我們上傳的套件已經上架,這時候你在開發工具中,就能夠使用該套件了。

改為針對套件的相依

在套件上架後,我們可以透過Visual Studio的方案總管,先移除WebBMI主專案原本對HealthMrg專案的相依。

您可以在專案名稱上按下滑鼠右鍵,選擇加入參考,就會出現底下畫面。然後直接把原本打勾的HealthMgr勾選取消:

移除後,你會發現,方案總管中相依性的部分也看不到『專案』了。

接著,我們再對主專案加入Nuget套件:

我們可以透過專案的『管理nuget套件』選單,開啟Nuget套件管理員,接著選擇『瀏覽』頁標籤,透過關鍵字搜尋套件名稱。

你會發現我們剛才上傳的套件果然有列在清單中,點選該套件選擇『安裝』即可:

成功安裝後,你可以建置(Build)主專案,你會發現主專案由於使用了這個套件,既便沒有直接對HealthMrg專案的相依,依舊是可以建置與執行的:

就是這樣,我們將主專案中針對Project的相依,改成針對Package的相依,過程並非相當困難,但對於系統相依性的管理則大大的提升了便利性。


[1] 當然,如果企業覺得該套件沒有敏感性,也沒有商業考量,想要上傳到nuget.org和全世界一起分享也並無不可。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps敏捷開發與專案管理實戰

2020年2月28日 星期五

凡事都可行,但不都有益處…

凡事都可行,但不都有益處:凡事都可行,但不都造就人。(林前 10:23)

前陣子有位好友特別到我辦公室,跟我討論他最近想要做的某個軟體產品。他知道我過去這幾年有非常多產品開發(我想估計是失敗的)經驗,所以他說想跟我請益一番。

一如既往,只要人到了我辦公室,我肯定熱情接待、滔滔不絕、知無不言。談過了他的想法與企圖,也給了一些建議,茶過三巡,我也就不客氣地分享了我最近想做的另一個資訊服務,話還沒講完,他拍案大讚,說到:『David你這個案子會成,要不要做? 我有興趣。』

他的熱情讓我愣了一下,我有點猶豫地說,我還在思考一些問題,像是…為什麼我目前沒看到市場上有類似的服務? 台灣那家知名的網路商城P公司,該是最有資格做這個案子的,不管是倉儲、物流、和我這個案子最關鍵的庫存品,都一應俱全,我不太懂他們為什麼不做?

朋友說了一句話:『P公司太大了,他們什麼都能做。什麼都能做,就代表什麼都做不了。』

他話才說完,我就明白了。
(有時候跟頻道接近的朋友聊天就是有意思,話不用講太多,彼此一點就懂。)

我明白了朋友說的意思,但也看到了我自己的限制。

這一直以來是我的問題,我意識到這個問題,但卻始終沒有去面對。

前陣子流行『斜槓青年』,你可以在網路上找到這個字的意思。但我慢慢發現自己實在斜槓太多的領域了(而且也不是青年了)。過去這幾年,我寫書(手上正在寫一本),做企業顧問(目前一家進行中,一家洽談中),同時也帶人做軟體專案(目前三個案子進行中,好在差不多都是結案階段了),我也喜歡上課(下個月開始預計有兩個排定的課程),另外每周我給自己的目標是產出三到五篇的貼文、blog文章和數個教學影片檔,為了提供給線上課程和電子書…

然後,我還一直很想做產品。

雖然盡全力把每一個手上的任務做好,但很明顯的,我發現瓶頸在哪裡了。的確,瓶頸就在自己身上。

問題來了,我要割捨掉哪一塊? 我太明白多工與多重目標所帶來的陷阱和限制。回頭翻自己的貼文,還有底下這兩張照片呢:

但怎麼當要去面對這些問題的時候,自己也變得難以割捨了?

管理方法的道理和邏輯永遠是那麼鮮明,但執行的困難卻往往不是不懂這些,而是在情感上的拉扯和限制。

剛開始工作的第一年我就發現,除非自己選擇放下,否則手上的工作永遠不會有作完的那一天的。而當人(企業)能做的事情看似愈來愈多,就愈是得克制每一件事情(每一個目標)都想去做的衝動。

我記得從某本談管理的書上看到這麼一段話:『這世界上根本沒有時間管理這回事,你要管理的不是時間,而是你自己。』

我喝了口手上的咖啡,抬頭跟朋友說:『這個案子我真的很有興趣,但我得再放一陣子。對我來說,現在不是最好的時機。』

這世上有許多很有趣的事情等著我們去做,不過,我們始終得把優先序排好才行,畢竟,管理好自己,是成就所有事情的第一步。

自由不只是去做所有自己想做的,更是有能力放下自己不該做的。工作是這樣、專案是這樣、其實生活也是。

2020年2月26日 星期三

Azure DevOps in Action - 透過 Fork 實現 InnerSource

Fork在Github中是常見的功能,使用的情境大多是我們想修改或學習他人的程式碼時。只要我們有權限,就可以Fork他人的Repos到自己的帳號底下。Fork和Clone不同,Fork可以追朔到來源的Repo,讓新建立的Repo與來源之間有所連結。

對於開源的open source專案來說,Fork是很有意義的功能,但對於企業來說也有需要嗎? 有的。

這幾年企業內部盛行InnerSource[1]的觀念,過去企業常常把source code視為不可觸碰的機密,甚至要求source code不可離開Lab(或特定部門)。在那個年代,你可能在某大型軟體公司工作了好幾年,卻還是看不到與自己部門(所開發的產品)無關的其他系統的任何一行程式碼。

但,現在時代不同了。

近年來,開發人員(和他們的主管)明顯地發現了open source所帶來的價值。同時,對於程式碼的安全性與開發規範也日漸成熟(如今,上道的程式設計師幾乎都懂得機密資料不該寫死在程式碼中),這使得企業也開始對於程式碼的開放不再感到懼怕。因此也在對企業內部員工開放程式碼後,獲取了很多前所未有的好處。

最顯著的好處是,員工可以透過檢視同事的程式碼進而學習和成長,回顧你自己過去的學習經驗,你會發現,其實大部分的程式設計師,都是透過看別人的程式碼來學習的(而非單單只是看書、上課、或是自學)。一旦停止觀摩,開發人員的成長就遇到瓶頸了,也就是說,觀摩其他人寫的程式碼,可以說是最好的學習方式(沒有之一)。

如果你覺得這沒什麼,認為讓員工成長這種事情對企業也沒啥好處,那你可以再反過來想。當企業內的所有開發人員,都知道自己的程式碼有可能會被其他人檢視(review)時,對於一個稍有廉恥心的開發人員來說,這是一個很大的提醒。當企業內培養出這個文化之後,大部分有自尊心的開發人員,都會在簽入程式碼之前,再看一下有沒有不該出現的code,以及是否有因為偷懶或取巧而品質不佳的程式碼。這使得軟體開發人員無形中更加的謹慎,對程式碼的自我要求將提高,而不只是讓程式能動就好。久而久之一旦養成習慣,在無形之間也提升了程式碼品質。

還有另一個典型的情境,也非常有價值。

近代的軟體開發往往是基於組件或套件的重用,在企業內也是,我們常常會用到他人所撰寫的套件或工具,這可以讓開發速度和時程加快,同時也提高重用性(提高重用性就是意謂著降低成本,切記)。

但,如果你同事所開發的套件有bug呢?怎麼辦?反映給他,等對方處理? 又或者,你需要在某一個套件上增加一些新功能,那又該怎麼辦呢? 等對方修改恐怕會曠日廢時,且對方也不見得有空花時間跟你討論需求…

更好的方式是,直接fork對方所撰寫的這個套件的Repo,直接幫對方修改,改完後只需要發個PR給對方即可。這讓企業內的合作自然且順暢的發生。身為Developer的你可能並不知道,『合作』這件事要想在企業的其他部門或領域推動有多困難,而軟體開發部門的宅宅們,卻只需要透過Fork + PR就可以自然的實現跨團隊的合作了。

資訊工具的進步,讓團隊合作可以在遠端順暢且自然的發生,這恐怕是過去沒有資訊工具的時代所無法想像的。如今,多人同時在wiki或HackMd等工具上一起撰寫會議紀錄,開發人員透過線上code review和協同開發,都已經慢慢變成像喝水一樣自然。

有了InnerSource的觀念之後,我們來看看怎麼在企業內透過Azure DevOps進行Fork與合作。

在Azure DevOps中使用Fork

好,在前面知道了Fork在企業內的價值之後,我們來看具體怎麼實現。

一般來說,只要你有權限檢視某個repo,就會看到右上角的選單中有一個Fork選項:

當你點選該選項,就會出現底下畫面,可以讓你把特定repo複製到你自己已經建立好的Azure DevOps Project[2]當中(下圖B):

複製過去的時候,會帶出原本此Repo的名字(上圖A),當你確定無誤按下Fork鈕,就會看到該repo被複製到你的專案中了:

從上圖中你會看見,該Repo被複製到newProject2(上圖A)這個Project底下,Repo名稱變成了myFirst.twdeveloper(上圖B),myFirst是原先的Repo名稱,twdeveloper則是你的帳號名稱。

就這樣,你可以開始修改或檢視程式碼了。所有的操作都跟你原本操作Repo的方式完全一樣。

前面說過,Fork和Clone某一個Repo有一個很大的不同,就是Fork之後,新產生的Repo和來源的Repo之間是有關聯的。因此你會發現,當你修改了這個Repo中的程式碼,並且Commit/Push之後,Azure DevOps一樣會建議你開立PR單,但仔細看PR單的內容,你是可以把PR的Merge給送回到來源Repo的:

你會發現,(上圖A)的選項,不僅可以選到 Fork過來後新建立的Repo,也可以選到來源原始Repo,當你選到原始Repo的時候,就可以把你的貢獻,反饋給最初該套件(或系統)的開發人員,達成企業內資訊共享與跨部門協同合作的成效,讓InnerSource真的發生。

這很不錯吧? 過去要在企業內實現這樣的程式碼協同運作,或是跨團隊之間的合作,有著一定程度的困難,要培養這樣的文化更是難事,但透過Fork機制讓InnerSource很自然地在企業內發生了,這是一個很值得推廣的功能。


[1] InnerSource這個字眼是Tim O'Reilly在2000年發明的,意指在企業內,對內部開發人員進行組織內的開源文化。相對於過去很多企業把source code保護的死死的,如經已有不少企業開始風行這個概念。

[2] 請留意,即便你的帳號跨多個組織,也是不能把Repo給Fork到另一個組織底下的。Fork這個行為在Azure DevOps中,只能在單一一個組織底下運作。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps敏捷開發與專案管理實戰

2020年2月24日 星期一

Azure DevOps in Action - 從VS Code連上Azure DevOps Repo

除了使用Visual Studio,.net core開發人員也可以採用VS Code,它是跨平台的開發工具,在開發.net core程式的時候頗為好用。事實上,現在也頗多Python、Node.js開發人員使用它。

由於是跨平台的,所以你可以在MAC或Linux環境執行,而無須一定要使用windows環境。

從VS Code上連結Azure DevOps也非常簡單,前面的步驟都相同:

你可以在(上圖D)的地方先完成初始化,然後透過(上圖A)直接在右方選擇『Clone in VS Code』即可。你可能會發現,按下(上圖D)的Initialize之後,畫面就變了,別擔心,你可以點選右上角的Clone來進行一樣的功能:

點選後,會出現底下視窗:

請點選『Clone in VS Code』即可,接著系統會試圖開啟VS Code,請選擇開啟:

如果出現底下畫面,依舊選擇『開啟』:

VS Code被開啟之後,會出現底下畫面,讓你選擇要把Clone下來的檔案放在哪個資料夾:

請自行選擇,完成後,你會看到底下視窗(一般出現在VS Code右下角):

這時候就在複製Azure DevOps上的Repos了,完成後,請選擇:

開啟新視窗之後,你會看到果然整個專案已經被Clone下來:

你一樣可以在VS Code環境中進行所有版控相關的工作。

例如,你可以透過F1或ctrl+shift+P,即可開啟命列選擇視窗:

其中有『Git:Sync』指令,點選後,會出現底下視窗:

當你選擇確定,會發現果然把伺服器端其他開發人員最新簽入的程式碼給同步回來了(下圖A):

同樣的,如果你改了一些程式碼,也會發現:

已變更的檔案數量會被顯示出來(上圖C),被修改過的檔案也會被標記為M(上圖B)。

這時,你一樣可以透過『Git:Sync』指令,把你修改過的異動更新回伺服器端。你可以先點選下圖A的地方,會出現讓你輸入comment的畫面(上圖B),請輸入後,按下Ctrl+Enter:

如果出現底下畫面,請選擇『是』:

完成後,表示程式碼已經committed到用戶端,接著可以sync到伺服器端,這時VS Code的左下角(下圖A)會出現已committed但尚未push/sync的change:

這時候你一樣可以透過F1或Ctrl+Shift+P,開啟(上圖B)的選單,進行同步(Sync),完成後,你會發現伺服器端的檔案果然被更新了(下圖A):

就這樣,其實使用VS Code來配合Azure DevOps Repos也是非常方便的。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps in Action』

2020年2月23日 星期日

Azure DevOps in Action - 從VS2019連結Azure DevOps Repo

Azure DevOps是微軟自家的雲端服務,那使用號稱地表最強的微軟開發工具Visual Studio 2019連上Azure DevOps自然沒什麼問題。

開啟Visual Studio 2019,輸入你的帳號,在Team Explorer頁簽的位置 (下圖1),點選管理連線(下圖2,3,4),即可連結到Azure DevOps的Repos,不管你是用哪一個版本的Visual Studio(免費或付費的)都行:

連結時會出現底下畫面:

在(上圖1)的地方,請選擇正確的帳號,該帳號必須是你要連接的Azure DevOps專案的Owner或Member(總之必須是團隊成員),Visual Studio會列出所有你有權限存取的專案。

然後,請點選你要連接的專案(上圖3),將其展開,會看到該專案底下所有Repos,如果是Git Repos會以紅色Git符號呈現(上圖4),如果是TFVC Repos(上圖5,未來我不建議在新的專案中使用)版控,則會是灰色符號呈現。

點選好你要連接的Repos之後,請在路徑(上圖6)的地方輸入該專案你想要Clone到本機的哪個路徑,設定完成後按下『複製』鈕即可。

成功Clone專案之後,你會看到類似底下這樣的畫面:

由於一開始剛初始化的專案中,並沒有.sln, .*proj之類的專案檔,因此會先以上圖這樣的資料夾檢視模式來顯示,你會看到剛才我們建立好的README.md和.gitignore檔案都已經在其中(上圖1)。

這時,你可以點選(上圖2)的Team Explorer,會切換到底下畫面:

你可以在這個畫面中,透過『新增…』連結(上圖1),來建立一個新的專案(或方案),當你的專案建立好之後,可以透過『同步』(上圖2)功能,將用戶端的檔案同步到Azure DevOps雲端的Git Repo中。

例如,底下我們隨意建了一個.net專案(project):

這是一個基本的console專案,建立好之後,你可以看到,在方案總管中,有新建立的程式碼(上圖1),而上圖右下角的地方,你會看到目前有哪些尚未Commit的檔案(上圖2),以及當前連結的repo(上圖3)和目前正在使用的分支(Branch, 上圖4)。

你可以透過點選上圖2,3,4這些圖示,來進行相關的操作。例如可以點選上圖2進行Commit,當您點選之後,會出現底下畫面:

你可以在上圖B的地方填寫Comment,然後選擇Commit:

上面是中文版的翻譯,認可是Commit,推送是Push,同步是Sync(他會先拉再推,這樣可以避免衝突),我們可以試著選擇『全部認可並同步』,結果會把所有程式碼同步到Azure DevOps雲端的Git Repos:

你會發現在原本站台的Repos中,出現了我們剛才簽入的檔案。如此這般,基本上,所有操作跟一般的Git版控使用原則完全相同。

當我們在本機的開發環境,修改了某一段程式碼之後,你會看到Visual Studio的畫面有些許變動:

你應該不難發現,那隻被改過的程式碼檔案的前面,多了一個紅色小勾勾(上圖A),同時右下角出現了尚未Committed檔案的數量(上圖B),這是提醒你,你的程式碼尚未簽入。

而未Committed檔案數量左邊的『↑0』,則是已經committed卻尚未推上雲端repo的change數量(目前是零)。

有時候我們不會每commit幾個檔案,就立刻push/sync到雲端的repo,而是多幾次commit之後,才一口氣sync到雲端,特別是離線開發的時候。

好了,如果你平時有在使用版控,這些應該相當熟悉。若過去你完全沒有使用任何版本控制軟體的經驗,我建議你可以針對這個主題,在坊間找1-2本有關的書籍參考,畢竟目前版控已經是軟體開發的基本功。

當你讓團隊中所有開發人員都連上同一個Azure DevOps的Git Repo之後,即便是團隊成員在遠端,大夥兒一起開發軟體也不是問題。更重要的是,所有團隊中的開發人員,大夥有一個一致的基準點,只要頻繁地(每天數次最好,最差也得一兩天一次)把個人開發環境的程式碼與伺服器端的Git Repos同步,如此一來,即便是多人合作,程式碼也不會發生衝突。(當然最好是不要同時兩個人改同一支程式碼,如果真有必要,可以考慮利用partial class把同一個類別切成兩個檔案。)

而未來的幾篇文章中,我們馬上會進入到CI(continuous integration)/自動建置(Auto Build),也就是說,當團隊中有任何開發人員,把寫完的功能(程式碼)簽入系統,並成功推入程式碼儲存庫(Repo)之後,Azure DevOps會自動觸發一個自動化的CI流程,把雲端上(Azure DevOps Repo)內的程式碼拉出來,自動在雲端上進行Build的動作(甚至Build完可以自動佈署,如果你願意的話),一周(甚至一天)數次。

如此一來,即便開發團隊中有多位開發人員(就算根本是在遠端而非在同一個辦公室一起工作),我們也可以頻繁的整合,提早發現程式碼中可能的潛在問題與衝突。

而非像是過去,直到準備把系統交付給客戶的時候,大家才把各自手上的模組拿出來整合,結果跟本兜不起來,更罔論想要正確的執行了。

如今,對於許多新創團隊或是企業而言,CI(continuous integration, 持續整合)、頻繁交付..這些個概念已經跟喝水一樣自然。但誰能想像,也不過才10幾年前,沒有CI工具的時候,軟體開發完全不是現在這麼一回事。每當開發團隊要把所有成員分別開發的程式碼,合併在一起執行的時候,屢屢都像是作戰一樣,每個人的程式碼跟一大串攪成一坨的粽子線一般、模組衝突的一堆、套件不合的一堆、版本錯亂的一堆…剪不斷理還亂。當年,每次要進行整合都是噩夢一場。

對了,我們也可以透過Visual Studio建立或管理分支(Branch):

點選上圖中A的部分,你會看到管理分支、新增分支的選單,你可以在用戶端新增分支,然後同步到雲端。也可以透過管理分支切換到其他團隊成員所建立的分支上開發或檢視。

分支是Git版控中相當重要的機制,你使用Git,幾乎沒有任何理由不使用分支,因此開發人員對於分支要有一定的基本概念(我們後面會找機會更多的介紹)。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps in Action』

Related Posts Plugin for WordPress, Blogger...

熱門文章