How to use a recurring Integration Endpoint for importing data
You are here
"Git"ing Started with Git in D365F&O and Other Puns
Getting started with Git and D365F&O is easier than you think.
Let's Git Started.... I'm sorry
We'll setup a simple project from start to finish to show you how easy it is. For sake of transparency in this article, we'll be using Github but using Azure DevOps is also an option. I'll do a follow up article on that experience. We'll also need the GitHub tools. This is a great article on how to configure this for VS 2017 but the same steps are required for VS 2015.
First, create an account on Github and create a project. We'll be using https://github.com/NathanClouseAX/AAXPOCloseHelper.
Next, clone it locally into your LocalPackages directory such as K:\AosService\PackagesLocalDirectory\AAXPOCloseHelper.
Next, we'll have to make some changes to our VS settings. This is were it gets little ugly as we'd have to manually change these settings for each package in Git where each package is a project. Go to Tools then Options, Find the Projects and Solutions node and set your projects location to a folder inside your newly created local repo, like Projects.
I'm Not Touching You! I'm Not Touching You!
Next, we'll need to create a .gitIgnore file. This will let Git know what to ignore. An example of what we want to ignore is compiled code in the XppMetaData folder. We don't specifically care about the compiled code for source control. To do this, go to the Team Explorer tab, click on settings then repository settings. From here you should have the option to create a .gitIgnore file. This will create a standard .gitIgnore file for lots of different languages. We'll want to tack this onto the end of the file. alternatively, you can create a file manually and Git will pick up it.
# D365 specific
bin/
resources/
XppMetadata/
BPCheck.xml
BuildModelResult.xml
BuildProjectResult.err.xml
BuildProjectResult.xml
CompileLabels.xml
*.xref
Here we are telling Git to ignore the entire bin, resources, and XppMetadata folders from the project root (K:\AosService\PackagesLocalDirectory\AAXPOCloseHelper) as well as some specific files that are standard artifacts we'll see during and from normal development activities.
From here, we just develop as normal. Create a package and model in this directory, add some code, test it, and get ready to commit it. This specific project was requested at User Group Summit last week while I was at the medic desk.
Let's Git Committing
Now, we're ready to commit. Let's look at our pending changes. To do this, go to the Team Explorer tab, click home then click changes.
As you can see, we have several changes pending and it's all for artifacts we want. You may have noticed the axpp and DeployablePackage folders. We'll cover those at the end of the article. Next, let's add a comment and hit the commit staged button. After this, we should have a commit ID we can review. For this, it is https://github.com/NathanClouseAX/AAXPOCloseHelper/commit/7dcb4d03d98f23db684e86eb14e9ac73f5fa167d. Let's review what happened.
We commit our staged changed but we only had the .gitIgnore file in that area so we only committed that rather than everything in the project folder. Also, if you're used to using TFVC, you'll notice this commit didn't actually make it to the server yet. It is staged locally and we have to select sync then push to get it to the server. Also, I want to call out that Git recorded the state of the .gitIgnore file when it was added to staged changes and ignored our changes so if you review the commit ID above, its missing our D365 specific changes. Those will be added in the next commit. Now that we've done that, let's stage everything so we can commit it.
Yeah, You Push It
Click the plus sign next to "Changes" to move everything to staging, like so, and confirm we have no items in the Changes section.
Next, let's add a comment and commit.
And that's it but we're not quite done. We still have to sync to server. This isn't a require step always but for the sake of this article, it's required so you can review the result. Next to the commit ID, click Sync.
You'll see our commit in Outgoing Commits. Let's go ahead and do as Static-X has suggested and Push It.
and we're done!
We can review the result here: https://github.com/NathanClouseAX/AAXPOCloseHelper/commit/de9a4c9474eff8f3f53c947433849b57afe04cea. As called out above, this commit ID has our .gitIgnore changes for D365 so the order of operations in Git vs TFVC are a little different, in a good way I would say.
Deployable Package
I also created a deployable package for this. This isn't required, or advised, but since this is also something others may want to check out in a demo environment, it's nice to have a deployable package available for this so it doesn't have to go through the entire build process for someone to see what it does. This is simply for convenience as this is as community project. I would have to manually create this package each time there is a change that I commit.
AXPP
I also included an AXPP to ease uptake of the code for users still using TFVC, the supported source control system, hosted in Azure DevOps. Again, just a convenience thing and I would have to remember to manually create this for each commit if any code changed.
Uptake, Consumption and Modification
We'll cover this in greater detail in a different a different article but feel free to try to clone this locally, or fork it and create a pull request (PR). This code is free to use for nearly anything.