This is crucial to be able to track work without unneeded hustle - needing to go to TFS after each commit and link changes to WI’s is tiresome and potentially error prone.
It also helps developers focus on the task at hand in a way that can be reviewed in retrospective. Being able to see which tasks had commits by whom eases learning process of how work is being done on a daily basis and increases transparency.
In any Automation Development it is always a good practice to create 3 sets of folders.
Each folder will have set of local/global rules defined by RPA Manager/Lead for any organization.
Development Copy- Shared : Will allow all RPA developers to deploy their code at the end of the task/day. Only Completed activities/Modules will post into Development copy by TFS/Sub-versioning or any configuration control management tool. This location all scripts will be deployed on daily basis and RPA manager will review and approve accordingly.
Running Copy - Pre-Prod - Shared : This is a shared location to all RPA development team. but always very cautious to make any modifications. it is a best practice to give only read control on this folder to all except configuration control manager.
Golden Copy - Prod - Not Shared : This is not a shared folder to any one. Only approved scripts will preset and not allowed to make any modification with out change request.
all production executable RPA scripts will preset in this location.
Team thoughts are welcome on this discussion.
We’re talking about 2 different things.
Your post would be more relevant to this topic (which is also a pain to work with, btw):
Best practice for TFS
What I’m asking about here is linking code commits to work items in TFS.
Similar to this in VS:
So that in TFS (VSTS) you get this:
(don’t mind the numbers/dates, screenshots were taken from random items just to demonstrate)
This should be added. Common practice in other version control platforms.
For example being able to close open bug items in the commit push: #123 Fixed, bla bla.