Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
For us, Dynamics NAV/Business Central people, Git is something which we never used before – of course with some exceptions. However for version control and storing the objects we had either some customized solution directly in NAV or we used Development Environment.
I was really impressed of Kamil Sacek’s presentation on Direction EMEA last year about Git Branching Strategy. And because I was saying about it in my company (maybe even too loudly) some time ago my manager asked me to consume this knowledge for one of our product. And since he agreed I would like to share with you how I solved the problem called:
We will have new release of our product – how would you set Git branches for that?
First of all I must say: there are multiple ways to solve this. Second: The solution below works for us but, that doesn’t mean it will work for you – all depends onsituation and complexity which you would like to have.
For whom which are not familiar what is for example Repository, Branch, Pull, Push etc. I really strongly advise to check tutorial on this page https://www.atlassian.com/git/tutorials and go thru basics. Those terms are really needed!
To understand the branching strategy presented in the next points I owe you some explanation first. We release the product (hurray!!!) which is already installed in the customers’ databases and now we working on next release of the product (even more hurray!!!).
Means we do not want to have yet in the product the modifications which are still not tested and approved. So any new customer still would got the product in the version which is now treated as final.
That’s also mean we cannot merge our objects to the main branch until all will agree that we have new extension version but we still need to be able to do the fixes if something was wrong and propagate them to existing customers.
First let’s have a look on a diagram and below you will find detailed description of each of branches which we need.
The master branch is used as a production branch. Code from this branch is taken as a base for installation of the extension to the customer’s database. It is good to setup it this way that only authorized people for example Product Owners can merge code to this branch. Then they will decide when new release is done.
There are two cases when the code should be merged to the master branch. First one is when the new release is done and customers should be updated with the new version of the application (Point Z on the diagram).
Second is when there is a need to prepare hot fix which is discovered by customers or testers (Point AA on the diagram) and should be installed as soon as possible in the customers’ databases (Point AB on the diagram).
From the master branch, when there is decision to start working on new release, should be created the develop branch (Point A on the diagram).
The develop branch is used as a branch where all finished modifications (requirements) are stored – other words this is what will be in new release ready for deployment to the master branch. From this branch the testing environment is prepared. Also it is good but not mandatory (up to you) who should be able to merge code to this branch. I prefer to have at least one code reviewer.
This branch should be taken by developers as a parent branch for all new modifications which should be prepared (Point A or C on the diagram). After the changes (requirement) are done then the code should be merged to the develop branch (Point B, D or E on the diagram).
Small hint: to create a branch from the master using Git you can use the below commands – you will end up with to exactly the same branches master and develop
git branch develop
git push -u origin develop
If it is needed to prepare new functionality, developer should create a new branch from the develop branch (Point A or C on the diagram) – not from the master branch. The requirement branch is used only by a developer. After the code will be approved and merged to the develop branch (Point B, D or E on the diagram) the requirement branch should be deleted from the repository because it is no longer needed.
Very important is that developer is fully responsible to have all objects up to date in this branch. Means she or he need to avoid conflicts when merging it back to the develop branch.
Ok if we have something to be fixed really quickly we need this kind of branches. If the hot fix needs to be installed to the customers’ database then developer should create a new branch from the master branch (Point AA on the diagram) (not from developer branch!).
The hot fix branch, unlikely to the requirements branches, need to be merged to two branches. First to master branch, that it will be possible to prepare new application for the customers, and then to the develop branch (Point AB on the diagram). In both branches it should be tested to check if the bug had been fixed.
If you like the idea of branching policy presented above and want to know more then here is link which helped me preparing this: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Business Applications communities