DevOps and Business Central

In this post we will cover how to get started with using Azure DevOps for our Business Central development. We will take a look at how to use Azure DevOps as your task managing system, how to start using source control and how to use Azure pipelines for setting up automatic deployment.

First I will start with a disclaimer, I will only go through the very basic features of DevOps, one because I am not an expert and second trying to cover all of DevOps in one blog post would not be possible. So you should see this more as a quick taste of what you can do in DevOps, but I would highly recommend that you look into all the tools available in this awesome system. 😁

Getting Started

To get started you need to create a free account for your Azure DevOps which you can do here https://azure.microsoft.com/da-dk/services/devops/ you are allowed to add 5 free users to your DevOps and besides these 5 users then you can add infinite amount of free MSDN users, and then you also have a speciale user type called stakeholders, which are free but also has limited rights. And this is where you have to make your first choice. As I see it there are two ways of using Azure DevOps, the first is that you create one DevOps for your company and inside this company you create an organization for each of your customers giving your customers a stakeholder user for their organization, the upside to this is that you have everything collected in one place, so you do not need to remember different url's for different customers, the downsides are that you will have to buy a license for each developer that does not have an MSDN subscription, and if your customer chooses to leave you and they want their code you will have to export it for them. The second option is to let each customer have their own DevOps, and only adding the developers that works on the customer, the upside to this model is that it would be cheaper in most cases since you would be able to get by with the free 5 users plus stakeholders; and it will allow your customers to make a clean cut from their NAV/BC partner since it is their own DevOps; the down side is that you will have many different url's to keep track of and you will also have to help your customers in using DevOps. Whatever version you choose is up to you, I personally like the one where the customer has their own DevOps because in that way the customer owns their own code, and can always change partner without fearing that they will loose the possibility to make changes to their Extensions. 🤓

In DevOps you have the possibility to create projects under each for your organizations, so every time you start a new development project your can create a new project in DevOps. Must of us do not only work on projects but also on normal day to day production taks. So my idea would be to create a project called Production where all theses taks lives.

Once you have created your project then go to Boards -> Work Items -> New Work Item

From the drop down choose Product Backlog Item. This will open op a Card on which you can create a task description. Everything here is pretty much self explanatory, the one thing I would like you to notice is in the right side you have the possibility to add Development and Related Work. The Development will allow you to link your task with a given commit or branch in your Repo, making it easy to keep track of what code solves which task. The Related Work will allow you to add new tasks to your backlog item, this could be if you need to do some setup for example and you can even add a test case to your backlog item, giving a step by step guide on how to test your task, a tool which is great for letting the developer know how to test their code. 😉

You will notice that there are to tekst boxes in which you can write, a Description and Acceptance Criteria. In the description you can write well the task description 😝 now you can write it any way you want but I like the user story arppoche where you have the customer write the description using the As a ... I want .. So that ... the reason why I like this arppoche is because it gets the customer involved and there by committed. An example of a user story could be:

As a Bookkeeper 
I want to be able to post an order
So that I can send an invoice

Looking at the Acceptance Criteria this is where the customer would write what they expect to happen when you do something, here I personally like to use the Gherkin syntax which is GIVEN..WHEN..THEN so a test case could be.

GIVEN I have created an vaild order
AND I have the correct permissions
WHEN I press the Post action
THEN an Invoice should be created

Using this syntax will make it very easy to write your Unit Tests to test the given scenario.

That is all I going to talk about tasks in Azure DevOps like I said earlier, I am only scratching the surface of what you can do with DevOps, but that is beyond the scope of this post. 😵

Source Control / GIT

The next thing that we are going to take a look at is GIT, and this is one of the things that I hear that confuses most people, so I will try to keep it simple and start of with some theory befor moving on to how to do this in DevOps and VS Code. You can run GIT locally not needing DevOps or any other remote repository, however everything below is going to talk about the setup of having a remote repository that you work against.

Clone Repository

When starting a new project, using source control you would normally start by cloning a repository and this is even if you starting a blank project or if you are joining an exesting project. What cloning means is that you will copy the newest code to your local pc, and more importantly it will create the connection to your remote repository.

Commit and Push

When we talk about commit in GIT, we are talking about making your code part of the branch (we will get back to what a branch is). Now it is important that we do not confuse commit with a push, even though they are tightly tired together, when you commit you "only" commit your changes to your local repository, once your code has been committed you can push your commit to your online repository and this is where you might have to merge your changes into the existing branch and where you can setup rules for code review, before letting your changes be part of the official branch.

Branches

The concept of branches is one of the most power full things about GIT but it is also one of the hardest concepts for many people to understand. But I will give it a try, and I hope that will all make sense afterwards. 😊

You can view branches as different versions of your code, where your master branche is you "main" and working code, you should always be able to pull your master branche and get the latest stable version of your code. And since you master should always be a stable version of your code, that means that we need a way to add code to our source control that either is not finished yet or that has not been tested, and this is where branches comes into play. So every time you start a new task, you would create a new branch which in turn will isolate your code from the master branch, meaning that is also easy to delete your code, without having to worry about breaking anyone else code. The flow to create a new branch would be as follows:

1. You check out the master branch
2. You make your changes as you would normally do
3. Before you commit your code you should create a new branch, and commit your code to the new branch

Pull

A pull request is used to get the latest code from the server from any given branch, it is always a good idea to make a pull request before you try to push your code.

Merge

Merge is pretty much what you would expect, once you are done with your task, you will have to merge your code back into the master branch, because remember once you create your own branch, you are no longer concerned with what everyone else is working on, but once you are done, other people could have changed the master. Merging is done with a good old text compare tool of your choice. 😉

GIT in DevOps

Now Let us take a look at how we use GIT in DevOps, before you can start using GIT you have to install GIT for Windows which can be downloaded here https://git-scm.com/download/win when installing GIT for Windows just leave everything how the installer recommends. Once GIT for Windows is installed you are ready to start using GIT, now go to your DevOps project and choose Repos here you will find a link that you can use to clone your repository copy this link.

Now go to your Visual Studio Code and press F1 and type Git: Clone

And past your Repo url form DevOps into the command when it asks for it, then choose a location on your pc, where you wish your code to be stored, it will then ask you for your credentials, where you just enter the account that you use for DevOps. When it has cloned your repository, it will ask you if you wish to open it, and to this you answer yes.

You have now created your repository and everything that you place in this folder will be under source control. 😃

To keep everything simple we will just work with a single text file, so let us create a new text file and call it MyTextFile.txt and add some text to it and save it. You might notice that now you see a 1 marked on one of the icons in the side bare, this tells you that you have made a change to a file that has not been committed.

This icon is your entry to your source control, now click the icon a you will see a list of which files has been changed in my case, I have only changed one file, now let us commit it to our GIT and push it to DevOps, the first thing you have to do is add message, this is what will be displayed in GIT to tell people what you have made, I will just write Init, next stage you will have to commit your changes.

This will commit your changes to your local GIT, now let us push this change to our DevOps, this is done by choosing Push.

And that is it, you have now added your file to your DevOps Repo.

Now let us create a new branch, so go back to your VS Code, press F1 and write git Create Branch. And giv your branch a name.

Then add a new line to your text document and save it, then commit it and push it, you will notice that VS Code will come with a warning saying that the branch that your are trying to commit does not exist in your DevOps, and this is because your have only created it locally, but if you answer yes to this warning it will create the branch in DevOps for you.

Now if you go to your DevOps and go to Repos and this time to Branches you will see that you now have a new branch.

Now let us say that you are done with your task and you wish to merge your branch back into your master, you have to go back to your VS Code and press F1 and type Git Check out to.. and choose your master branch, this will change your pointer back to the master (remember to make a pull request, to make sure you have the newest master), then press F1 and type merge Branch, and choose your New-Branch.

And this will merge your branches locally, if you then go to your Source Control tab in VS Code and choose push, you will notice that the text file in your master branch on DevOps has been updated with the new line.

Now this all went pretty smoothly but what if there is a conflict 🤔

Well let us try go back to your VS Code and change your pointer back to your New-Branch (the same way as we changed the pointer to the master) and make some changes to the file, my file now has the following lines:

This is my old 2222 text file 
XXXXX
Text line number three 

Commit and push the change (you do not have to push the change in our example) Then change the pointer back to your master branch, and make som changes to the file in your master branch, commit and push them, my changes look like this:

This is my old text file 
Text line number two 
text XXX

Try to merge the New-Branch into your master again and you will see the following output showing you the conflicts:

And then you can just start merging 😉now I would recommend you setting up another tool to handle the merging, I prefer using Win-Merge http://winmerge.org/?lang=en install the VS Code extension Run git difftool https://marketplace.visualstudio.com/items?itemName=narekmal.vscode-run-git-difftool and follow the setup guide. And that is it for GIT 😃 now I know there are many things that I did not cover but hopefully this will help you get started with using GIT.

Azure Pipe Lines

I am not going to go much into Azure pipelines since I already wrote a post on this topic earlier CI/CD in Business Central and NAV using Azure Dev Ops All I am going to say is that since Azure Pipe Lines let us execute PowerShell on our local server, your can use it to automatically setup a Docker install your extensions, run your unit tests, and tell DevOps if your tests pass or failed. But this will be a post for different time, since the setup might seem a bit complex because we will have to write some PowerShell, and I feel that this post is already long enough 😉

Now I hope you have enjoyed this post, and hopefully I will soon be ready with the last post in this series which will be about writing unit tests. If you have not read my last post your can do so here Modern Development with Business Central