使用Git版本Microsoft Dynamics NAV？

Question

我是.NET開發人員，但在我們的組織中，我們還有幾個Microsoft Dynamics NAV開發人員。 目前他們沒有使用任何源代碼控制。 我對NAV知之甚少，但據我了解，你可以編寫NAV中的對象並從腳本中導入。

既然如此，是否有人使用GIT與NAV？ 你有沒遇到任何陷阱？ 我想知道這是否是一個很好的解決方案，建議他們，以及管理是否比使用Git with .NET（我發現相當容易）更復雜。

Answer 1

是的，我們正在使用Git和Dynamics NAV取得巨大成功！

不好的是，在Git賦予意義之前，必須將所有對象導出到txt。 讓我們希望微軟能夠創建一種更簡單的方法來將對象導出到txt。 我們正在使用這個模型。 使用通用主服務器創建Git存儲庫，並為我們更改的每個對象創建一個分支。 所有源文件必須與分支頂級文件具有相同的名稱，才能使Git跟蹤差異。 以這種方式使用Git，我們永遠不會將任何東西合並到master中。 在開始使用Git之后，更容易處理共享對象並跟蹤其他NSC對代碼所做的事情。 IT-Revision很高興，因為所有代碼都有詳細記錄，並且任何后備的方式都更容易。 我將全力支持使用Git和Dynamics NAV。

石油與能源行業的Navision顧問

Answer 2

我正在使用Dynamics NAV和Git，但不是在同一時間。 讓我解釋一下原因。

Git本身很酷（ GitHub變得更好），但是Windows端口很差，除非你不喜歡堅持使用類似unix的命令行，因為它是建議使用msysGit的方法 。 不幸的是，Windows上的GUI工具並不好。

對我來說很難讓老板理解，為什么使用分布式版本控制比通常的TFS更好。 對於面向業務的人來說，一個大的中央存儲庫感覺更安全（因為它是我自己支付的服務器，我控制訪問權限）和更強大（我雇用了一個將運行維護程序的系統管理員）。

我決定不反對這種意志。 我們使用分布式版本控制作為臨時區域。 所有不穩定的更改都存儲在此區域中，我們會在團隊中進行測試。 完成穩定后，對象將合並到中央存儲庫中。 每個人都很開心。

關於Git：最近我切換到另一個分布式版本控件 - 化石由於以下原因：

• 它可以做Git所能做的一切;
• 它在Windows上的外觀，感覺和行為;
• 它有一個Web界面內置，我可以輕松地將其作為本機Windows服務運行;
• 它集成了問題跟蹤功能，因此我不再需要第三方工具;
• 存儲庫是一個單獨的文件，因此我可以隨身攜帶在我想要的任何地方的筆式驅動器上;

關於我們的NAV解決方案。 它超過1000個對象，大小超過20 MB。

編輯：經過半年多的編碼后的一些更新。

我們換回了git。 由於它的自動合並是真棒 。 為了贏得賭注，我已經在4小時內將解決方案（修改過的標准對象和新標准對象）從NAV7CTP3移動到NAV7CTP5。 雖然由四名開發人員組成的團隊取得了相同的成果，但需要將近三周的日常工作。

Git真的有所作為。 我相信其他分布式版本控制系統可以獲得相同的結果。

原因是：Git和其他分布式系統在提交期間比TFS和SVN節省了更多信息。 在常規開發過程中並不是那么重要，但是當涉及到合並時，來自Git的所有這些“冗余”信息都會產生影響。

在合並期間，Git找到啟動分支的通用修訂版，然后逐步應用來自兩個分支的更改 - 與開發人員更改代碼的方式 - 應用於解決方案中的所有文件。

如果在兩個分支中更改了相同的行，則表明存在沖突。 如果不是，它只是將文件保存到准備提交的工作文件夾中。

這里有一些統計：

• 在CTP3和CTP3代碼庫中處理的文件總數大約是四千個;
• 合並的解決方案對象的總數是1170;
• 沖突文件總數為140;
• 成功自動合並的比率約為88％（1170-140）/ 1170 * 100 = 88％;
• 大多數沖突都是對象版本的變化 - 微不足道;
• 大約20個文件中的重要沖突;
• 對所有合並對象進行了簡單的查找和替換（修復RunFormOnRec - > RunPageOnRec等）;
• 結果是一組完全可導入的基於CTP5的最新解決方案對象;
• 導入后的編譯錯誤數約為50;
• 大多數這些錯誤與從CTP3到CTP5完成的標准對象的變化有關;
• 斷層物的發生率約為4％（50/1170 * 100％= 4％）;

Answer 3

我們正在使用帶有Dynamics NAV的git並取得了巨大的成功。

但我不得不說，這並不容易。 Dynamics NAV（我們使用的是2013版）未針對git或基於文件的開發進行優化。 開發通常直接在開發環境（經典客戶端）中完成，該環境將源代碼直接保存到數據庫中。

所以我們為git提供的支持是：我們構建了許多有用的PowerShell命令，幫助開發人員將NAV數據庫與本地git文件夾同步。 我們有一個命令可以將帶有修改標志的所有對象導出到本地git文件夾中 - 或者是一個導入git提交之間所有對象的命令。 我們甚至使用它來自動更新我們的測試數據庫，在開發機器上使用git push 。

但這就是說：開發所有這些程序並構建腳本並不容易。

所以我建議你三思而后行使用git和Dynamics NAV的決定。 該軟件不適用於git，所以你必須做很多工作 - 問題是你的老板是否願意給你時間來建立必要的工具來順利工作。

另請參閱對象管理器高級版 。 這是我們以前使用過的工具。 我曾經看過idyn （公司）的預覽，他們用visual studio取代了經典的開發環境客戶端！ 我們從Object Manager Advanced切換到git作為主要開發工具，因為它不適合我們的業務案例。 但是我們仍在使用fe for Where Used功能女巫很棒！ （電影來自舊的資產凈值版本，對不起）

Answer 4

我一直在使用Git和Navision 2009（及更早版本），這非常值得。

由於沒有本機Git支持，我將ID號區域中的Navision代碼導出到一個大文本文件中。 （選擇.txt格式進行導出）。 或者在我按日期更改的所有模塊上設置分隔並導出。

我寫了一個Python腳本，它接受這個文本文件，並將它分成每個Object（Form，Table，Codeunit）的單個文件，就像你手動保存所有內容一樣。 它將它們保存到我在Git控制下的網絡文件夾中。

雖然花了幾天時間讓這個過程完全運行，但現在整個過程每次更新只需要幾分鍾。 唯一的缺點是Navision本身不會導出誰做了更改，因此Git不會反映出這一點。

仍然很好，我可以完全控制我們的Navision源代碼中的變化。 此外，如果您在一個記錄不完整的Navision環境中工作，那么您可以搜索一個表單中的完整代碼，這是一個巨大的計時器保護程序。 除了搜索代碼庫以查找錯誤消息文本之外，另一個優點是您可以編寫腳本，該腳本將告訴您允許修改特定表的代碼。 因此，如果您重構一個表，您將立即知道需要檢查哪些代碼...

對於Git本身，我使用了一些基本的命令行命令。 為了檢查更改，我使用了當前Git版本支持的visual P4MERGE工具。