All developers in our companies teams can put a build to retain indefinitely. We use TFS 2017.
In the history of a build, you can see that the build has been set to retain indefinitely, but NOT, WHO did this. We want to know this, because this helps us when months later we can ask this person if it still needs to be retained.
How can you find out who put the build to retain indefinitely?
There is no way to find who asked to switch retain indefinitely as I see, because the history of build changes is not being stored. However you can see who changed the build previously using Rest API - will be a guess work.
https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}?api-version=2.0
lastChangedDate and lastChangedBy are the objects.
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
We moved to TFS 2017 (from TFS 2013 XAML builds) and the new build & release, but we mainly do windows apps. Q&A and some people are complaining about some functionality missing, for example, there is no way to specify to Keep All builds. I find it extremely strange this would not be possible. How can we do this?
I also looked into the Release part of it, but I don't see anything for Windows app. Besides, it seems that cannot keep releases indefinitely either...?
XAML and vNext are totally two different build system. The behavior is different for the new build system, there is no keep all option. You definitely couldn't use the old retention policy on XAML build for vNext.
If I mark a build or a release to be retained indefinitely, does the retention policy still apply?
No. Neither the definition's retention policy nor the maximum limits
set by the administrator are applied when you mark an individual build
or release to be retained indefinitely. It will remain until you stop
retaining it indefinitely.
More detail about the policy please refer this tutorial: Build and release retention policies
Every time I've coded a new feature (about once a day), I create a shelve set containing my changes and request a code review of my team lead (of the changes in the shelve set). He's pretty busy and it takes him half a day to a day to do the review. Meanwhile, I've continued coding the next feature, on top of the changes that I asked him to review.
My problem is: How do I then check in the changes that he approved, but not the (unreviewed) changes that I made after I created the shelve set?
As MrHinsh says you need to park what your working on and progress the code review check in and then return to what you are doing.
If you are using the the TFS code review then you will be using VS Premium or above, you can therefore use the My work tab to handle this process for you. You can Suspend what you are working on, revert back to your reviewed code, and when that is completed you can then restart the work that you were on.
TFS will shelve your changes and work items for the Suspend, when you then restart the work all of the source and work items will be restored back to the IDE and the IDE will revert back to the state it was in when you paused.
Information on the My Work can be found http://msdn.microsoft.com/en-gb/library/hh543900.aspx
There are really two main options for this:
You can shelve your new changes and revert. Then retrieve the shelve for the review and checkin. Then retrieve the new work.
You can have a seperate workspace that you keep clean of new development for checking in the reviews. Switch to it, get latest, and retrieve the reviewed code. Then check in.
We have been using TFS 2010 to manage work items and sprints for a while now and have recently added on a dedicated QA person. What I need to be able to do is to either create a build definition that I can run on a scheduled basis (Tuesdays at 9pm for instance) that will only build and/or deploy the Work Items that are in a State of "ReadyToDeploy". Or a way to get a list of files to push based on the TFS API.
My end goal is to have a way to automate the release process so that only the items that have passed QA are sent to our staging environment weekly. Then the customer or QA can approve that the items work in staging which is a mirror of production, and another process or build definition will deploy those items which will be in a different state.
I have modified the work items and work flows to accomplish the different states, but I am having an issue getting either a build of just the fixes or a list of all the files to push based on the state of the work item.
I am open to any ideas or solutions for this, the alternative is that I have to manage the list of files and manually push files every week and I am trying to get away from that.
Thanks,
Edit: The way we have it setup now, is that each developer has their own branch and own website, our software is server based and has to be run on a particular server. Our Trunk is linked to the main dev website. This is where QA initially does their testing to move an item to the ready to deploy status. When a dev is ready for QA they check in their changes in their branch and merge into the trunk. The builds are created off of the trunk at the moment. On our deployment nights I open up the trunk website in VS and do a publish then take those files compared against a list the developers have given me and ftp the compiled files to our production server.
I could be wrong, but I am not aware of a way to tell a build to avoid certain changesets based on the state of an attached work item.
I think the only way you could achieve this would be to create a Release branch and perform a daily merge of changesets that are in the "ReadyToDeploy" state. When you merge, you are able to cherry pick changesets, but they must be contiguous. This means that you would have to perform multiple merges to get the Release branch into the appropriate condition.
We have operated something similar for many years and it works well for us. Many people will tell you that it's bad practice, and it probably is, but that is for you to decide.
As for automating this for a build, I don't think it would be a trivial job. The hardest part will be the merge. You might think that there will be no conflicts as it is a one-way merge, but having done this for a number of years, I can tell you that conflicts do arise.
Step By Step Explanation
Create a branch off the trunk called release
When you want to do a deploy, merge from the trunk into release, but only cherry pick the ReadyToDeploy changesets. This may take several merges as the changesets must be contiguous.
Fire off a build / deploy of the release branch.
Repeat steps 2 - 3 as your release schedule allows.
You could do something automatic, it would require an extensive bit of coding. It would also require a branching strategy so that, Dev, Staging, and Production all come from their own branches.
Set up a process that uses the TFS API to scan for items in that state
Use API to Traverse Items to get check ins attached
Use API to Get latest of source and target branch
Use API to Merge by change set (identified in #2) (this is non trivial, have to handle lots of cases, but merging should all be 1 way with no conflicts, so doable)
Use API to Check In
Kick off Compile Build
If Compile Build Successful kick off Publish Build
To the best of my knowledge there is a major issue with this approach. Say you have two changesets: # 1 and 2. Both of them containing modification for the same file. Now changeset #2 contains its own changes plus changes from #1.
If you decide to pull in changeset 2 and skip #1 guess what's gonna happen. You are going to suck in changes from #1. This is obviously a problem.
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.