Our build process on Team Foundation Server 2010 does several check-ins. I don't want these check-ins to generate automatic e-mails et cetera.
I know there is a magical incantation to make this happen (if I recall correctly, a special naming convention for the check-in), but I cannot find it in the documentation to save my life.
So please, save my life.
Try using ***NO_CI*** as a checkin comment, that will prevent another build being triggered. Not sure if it does what you need though.
Related
I'm housekeeping the TFS Server and have 40,000 shelvesets of which 6,500 are for the Build Service Accounts.
I assume i can simple remove these as i don't think the builds will refer to old shelvesets.
I exported all current shelvesets.
Can someone confirm if we can just delete all of these? Or will we run into trouble if we want to run an old build
We are running TFS 2017.2
I don’t see any reason to keep them. Since commits should be occurring therefore giving you code history and reproducible builds.
If you delete a shelve set you cannot retrieve it latter for any old builds.
Shelve sets are not the same as code commits
Reference the MSDN documentation which applies to TFS 2017 and shelve sets for use cases.
the purpose is not to be a version history of code changes or
associate code with builds.Thats what commits are used for.
Shelve sets are temporary. However, no rule stopping you from keeping forever. Unlikely any value would be gained from so many
though.
there is not a need to reproduce a build with a shelf set that is older then your code release cycle because commits our occurring making the shelve sets moot.
#NOTE: I do not know why you would have the build agent doing code shelve sets. I would look at your build definition and take out anything automatically creating shelve sets.
Its always advised to find the details of shelveset unless you know its old enough to delete. You must be a shelveset owner, or your Administer shelved changes permission must be set to Allow as explained here. Shelveset commands to delete/find/list/... are listed here
TFS Sidekicks tool provides a dedicated UI for a number of clean-up actions, including old shelvesets till TFS2015. Not sure about its working in 2017
My development team is using TFS for source control. My current plan is to have a new shared branch created each sprint for the developers to use for all their tasks.
What is the best way to ensure that the developers are performing forward and reverse integration every day for that branch? In other words, how do I make sure they are constantly getting the latest code set from the sprint branch and checking their code in as well?
There is no such VS extension can force developers to get code from TFS and check in frequently and continuously.
If which you want is to "get the latest " and avoid TFS force you/colleagues to resolve conflicts before checking in.
However, TFS redefined what "Get Latest" does. In TFS terms, Get Latest means get the latest version of the files, but ignore the ones that the server thinks is already in your workspace. Moreover, doing a get latest is good practice, but not mandatory. There is no such settings.
There has been some similar questions in SO and got an amazing answer, below links for your reference:
Is performing a Get Latest mandatory before checking in in TFS so you do not overwrite/lose code?
Why doesn't TFS get latest get the latest?
As a workaround, if you really need this feature in your team, you could set up a reminder such as meeting reminder in outlook 4:00PM to remind your colleagues, they should merge their work in the branch at the end of day. Just couldn't force them to do this.
This is a people problem, not a tooling problem. There's no way the tool can force their behavior when it comes to committing their code or merging branches. It's just part of workflow discipline, which will come with time.
In TFS there is an option in Visual Studio to "Keep Items checked out when checking in" what is the purpose of giving such an option?
I am trying to build a reporting tool to find out the list of files that are checked out, so in the case the user has set the above option would my report be accurate, since the developer can always claim that "Hey, all my changes are checked in"
How do i reflect those kind of checkout in my report?
I use this feature when part of what I'm working on is needed by another developer, but I haven't actually finished the whole task.
Your report would still be accurate, as it's a true reflection of the system - the code really is checked out, and the developer is probably still working on the file. The only way you can truly know if all changes are checked in is by comparing the current version from source control with each developer's locally checked out copy, which isn't going to be feasible for reporting purposes, and is probably of limited value.
In a modern CI environment it's very common to commit changes and simply keep changing the very same modules.On the other hand, once a milestone is reached, the developer will simply commit the changes & start working on something else.So, I think it's very natural for TFS to provide with this configurable flag.Another major feature in the TFS ecosystem is gated-checkin: is this mode the commit is shelved, built & committed once all that has succeeded. If it weren't for this option, the developer would have to stand still & wait until the process has finished.I would disagree with a developer stating "Hey, all my changes are checked in": our principle in the team is that everything that is checked out is being developed, anything else is/should be either shelved or committed.You could consider a rule that all pending changes of each developer get shelved at the end of the working day. I am personally against any such measures, but would surely examine them as a option if my devs wouldn't adapt to the principle.If you would agree to the above, your second question would become rather obsolete: In my opinion there aren't several 'kinds' of checkouts.
If I create a bug in TFS, is it possible to associate it with a unit test and be notified if this bug is fixed/broken?
Not exactly, but the workflow can go the other way: instead of creating a bug up-front, you can let Team Foundation Server handle the work item creation for you. If you create a continuous integration build that runs your unit tests, you can create a bug assigned to the user who submitted the changeset if that build fails (including because the unit tests fail.)
A good article on configuring continuous integration to do this is in MSDN Magazine.
A new feature in TFS 2010 is Gated Check-in, which will prevent this failing code from getting checked-in by requiring the build and test steps to complete successfully before they get committed.
There is, currently, no mechanism to do what you desire. You can force users to check in changes tagged with a work item, which you can then manually examine. Provided the user either alters a test class or creates a new one, and checks in with the fix, you can see whether it is done or not. But, there is no automagic "if this test is changed, alert me".
If you need some type of "change and alert" functionality, I would examine CodePlex and see if there are any tools of this type. It could be facilitated at the database layer, as well, but I am not sure what kind of monkeying that would take. I have not looked at the service endpoints for the latest TFS, so there may be a way to poll to see if there are changes.
Wish I had a better answer, but this is an interesting ASK, so I would consider going to Microsoft Connect for TFS and requesting the feature. It could be included in a future rev if enough people are interested in this feature.
Does anyone know how to enforce that all tests pass before a TFS check in?
TFS provides so-called Gated check-ins. That means: the complete build (which includes the test runs) is run and has to pass, otherwise the check-in is rejected. It's quite performance-demanding and somewhat time-consuming, when working in a larger team, but otherwise works like a charm.
HTH.
You can use the default "Testing checkin policy".
If you want to create your own testing policy, you can use this.