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.
- My Work
- Sync my TFS workspace
- Sync my NAV “workspace” – Import
- Do my “thing”
- From NAV to TFS workspace – Export
- Inspect pending changes
- Check-in change
1. My Work
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
2. Sync my TFS workspace
But before I can start I need to make sure that my local development environment is in sync with TFS.
Get Latest
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.
Forward integrate (optional)
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.
3. Sync my NAV “workspace” – Import
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.
4. Do my “thing”
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.
5. From NAV to TFS workspace – Export
As the change has been implemented, it has to be exported to my TFS workspace.
6. Inspect pending changes
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?
7. Check-in change
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:
- forward integration (FI), including a check-in, to incorporate the latest changes in the beta/test branch into my branch
note that this is needed to make the next action simpler as it will first handle any changes in beta/test separate from mine - a backward integration (BI), also including a check-in, to incorporate my change in the beta/test branch
Ouch …
… 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.
- Linking each check-in to the relevant work items ensures that code changes and information like requirements and design decisions are bounded
- Each changeset can be propagated in a controlled way from one branch to another
- I have current and previous versions of each objects at hand that can help me to easily check my changes against
- …