All around NAV dev and test
After our exploratory talk a couple of weeks ago, I was booked for yesterday by a Dutch NAV partner to help them out on their first steps 'into' TFS. Using Visual Studio Online we did setup a collection and a team project, drafted and implemented a branch structure and discussed the use of work items in relation to code check-ins and scrum methodology.
And among this all these basic questions recurred: what does it basically mean to be a NAV developer in a TFS environment? What are the specific task to be executed?
So here we go for a typical day in the life of … Luc, NAV developer happily using TFS.
Having had our stand-up with my team, I pour myself another cup of tea - yes, tea, as after half a century I still abhor coffee - and start up my laptop. I open my Visual Studio client and in the Team Explorer Home pane I click My Work to see what tasks are desperately waiting for me to get finished.
Nearing the end of our sprint unsurprisingly not very much. Some unfinished work (suspended work > participants) and two development tasks.
As one of my colleagues had pointed out during the stand-up that the … error when adding seminars … issue needs to be finished first to allow it to be tested, it's clear what I need to pick up. So I drag and drop 109 from available work items to in progress work
But before I can start I need to make sure that my local development environment is in sync with TFS.
So I right click on the add-on node in the Source Explorer and select Get Latest Version. Any code change that has been checked into TFS by others will also now reside in workspace.
If we are using a branching strategy with separate branches for each developer, like in the DTAP setup in my branching strategy post, I might also need to perform a forward integration (FI) - and check-in - to incorporate the latest changes in the beta/test branch into your own.
Now that I have updated my TFS workspace I need to make sure that my NAV "workspace" is synced too; i.e. import the updated objects into my local NAV development database.
I can do this per object, which makes sense when it concerns only a handful of objects. Or I could use some tricks to get this done more efficiently. I will dive into this in another post.
Now I can go ahead to do my "thing". Looking at the info the already resides on work item 109 (and the accompanying bug) I see that it's a simple issue due to an incomplete table relation definition, fix it in a couple of minutes and verify the fix with some straightforward unit tests.
As the change has been implemented, it has to be exported to my TFS workspace.
As I overwrite the existing version of the object in my TFS workspace TFS automatically checks it out for me appending it to the pending changes list to which I already have added the work item.
But before I will check-in this change I make sure I provide (1) some useful description of this change, (2) add the bug work item and (3) …
…, last but not least, will inspect the changes I made. This is one of these TFS features that makes me feel happy every time I am using it. I just have to right click on a changed object and select Compare with Latest Version to get a comparison between the current version on the server and the (changed) version in my workspace:
A simple, efficient and powerful way to check whether the changed objects do contain the fix or feature I implemented. Or did I forget to export the latest version from NAV?
Now that check, double-check proved me that all changes reside in my workspace I can check it in.
Using a branching strategy, like in the DTAP setup in my branching strategy post, I probably should propagate my changes to the consolidation branch beta/test. For this I need to perform:
… you might say as this seems typically more actions than you might be used in a traditional NAV setup where all devs code in a centralized database. You might be right, but we should not forget the broader picture of the setup we are in now.
Christmas Eve. Rain outside and moderate temperature. Cosy inside, having set the tree and decorated it with silver, red and gold, and the old electric candles that I inherited from days gone. Haven't used them for ages and still shining bright. Preparing our Kerststol with the dough to rise and now waiting for it. Wife and children gathering in our kitchen for some bread and setting up Smallworld. And urging me to join them.
So have to keep it short and thus remains to wish you all a merry Xmas!
Did you see this communication on PartnerSource/CustomerSource?
Having been harsh on MS various times with respect to PartnerSource I must admit I was quite astounded by this news. I really had to overcome some disbelief and force myself to read the article and let go of my prejudice. Yes, I still have to wait to January 11 before I will be able to believe my eyes. And yes, I will do my utmost best to be positively surprised and fiercely hope this promise will stand.
And as the Microsoft Dynamics Community Team writes:
Let us know your thoughts!
Again, this is just the first step in a longer journey. At launch in January, we’ll provide a detailed 2014/2015 roadmap and show you a list of the capabilities we’re shooting for, not just in PartnerSource, but also in how we evolve the customer journey. We also recommend reviewing the Next Generation PartnerSource and CustomerSource FAQ to help alleviate some general questions you may have. If you’d like to submit questions or comments prior to launch, please contact us at mbsexp@microsoft.com and we’ll get back to you quickly.