No – there is no UI way to delete builds

I feel stupid saying this but...we *don't* have a way to delete builds through UI in Team Build. We only provide a command line option to do this as Hemant describes in his blog. Yes - we have a UI way to kick off a build, create a build type and even change build directory or build machine for a particular build, but no - we don't have a UI way to delete a build. Before you start rolling your eyes and handing out books on UI consistency, lemme try and explain why we did this.

1. Deleting builds is in no way as common an operation as the other operations we have listed. So there is really no compelling need to provide an easy UI way to do this. Perhaps, the build admin did kick off trial builds while configuring, but then, that is just an initial hiccup. You might argue that there are continuous integration scenarios where builds might be needed to be deleted at a stretch. I agree that is a valid scenario, but not a mainline scenario we would want to design for.

2. Deleting builds is a kind of power operation. You don't expect your developers and testers to do this everyday. Providing a delete feature in the UI only opens ways to inadvertently perform an undesirable operation perhaps by novice users who do not really intend to do that. I can almost hear you saying "Duh! Have you heard of something called permissions?" Yes - we can certainly restrict permissions to do that operation, but you would be amazed at the kind of usability feedback you get when some option is grayed out most of the time and it appears to be a really easy option ( I mean, how difficult would it be to delete a build šŸ˜Ž

Now, you tell me - were we right in not providing a UI way to delete builds?


Comments (8)
  1. Hi,

    That’s fine by me – provided that the UI makes it clear that it can be done from the command line, and for some people an easy way to find out that there even is a command line.

    I find that I assume that if it’s not in the UI then it’s not possible.



  2. Hi,

    I don’t think that you’re right.

    Perhaps a GUI with a lot of warnings, red buttons and so on, but I really don’t like the command line!!!

  3. AndrewSeven says:


    I don’t think that being a "power operation" is justification for not having a UI, it only justifies moving the UI access off into an advanced options/tab/window and putting a couple confirmations. If you thought this was a extreem edge case then no-UI could be considered.

    The quatity of feedback related to a greyed out menu option has a very strong relationship to how easy it is for the user to find out how to enable the item and why it is disabled.

    If they can open the help, type the text of the menu item and find the relevant entry in the list of things and understand it then there is no problem at all. "Delete build is a complex administrative action" is enough for all the non-admins

    "Perhaps, the build admin did kick off trial builds while configuring, but then, that is just an initial hiccup."

    Just an initial hiccup, but surely not an unusual one and not an extreme edge case.

    If the build admin prepares on project after annother, then this will be a common operation. In the end though, the build admin is probably just as comfortable with the command line as with a UI so it becomes moot.

  4. I’d say it is very non-intuitive. The thing that ticks me about this a little is that once you create the build, there is no way to "edit" it (for example, I forgot to check the enable code analysis option and would like to).

    Now, you’ll say, of course there is! You can edit the build file directly. True, but nonintuive.

    And, for new people trying to use the build tools, you know what they’ll do? They’ll just think that there is no way to edit a build, so they’ll do the next best thing: Delete it and create it again from scratch. But oh my god! there’s no way to delete it either, what am I supposed to do? šŸ™‚

    So, it would’ve been useful.

  5. Thanks for all the views folks.

    Steve – You are right about cmd line discoverability, but I guess build admins will know about cmd line.

    Lorenzo – Personally even I would have preferred that. But there is one thing that I did not mention in the post. That was cost šŸ˜€

    Andrew – I totally concur on that one

    Tomas – A small thing to mention here – the scenario you describe is the scenario of deleting a build type not a build itself. For instance, if you want to enable code analysis on a build type already created, you can edit it as described and deletion of a build type is just deletion of a folder in source control. More on that in the coming posts.

  6. Chris Kinsman says:

    I think it being a power operation means you secure it based on user roles not relegate it to a CMD line. Deleting built types is fairly common due to the difficulty of editing them.

    You typically want to delete old builds while you are looking at the build report screen. Perhaps clean up a number of test builds, etc.

    Overall however the issue is just symptomatic of TFS as a whole. It tends to rely on a number of command line tools. Great for the developers of TFS who are undoubtedly power users but most of the folks on my corporate teams will be lost. They need UI and the UI in TFS is pretty thin.

  7. Paul says:

    Obscurity is a ridicules means of providing functionality. Rather than "dim" the Delete menuitem (when you get smart enough to realize there should be a Delete menuitem for those with appropriate permission), don’t even add it to the context menu if the current user does not have permission to delete. Sorry to vent, but there are SOOO many places where you guys think you know what I need to do better than I do (kinda like the government); Please please please please please make it intuitive and easy to delete things from TFS for those with the appropriate permission. Iā€™m on my 4th remove/re-install of TFS BECAUSE I CANT DELETE THINGS!!!!!

  8. Hi Paul – you sound like one disgruntled user! šŸ™‚ Sorry about the installation issues though – we have seen a lot of them on the forum and we are working hard to address those and improve the setup experience. But both you and Chris seem to be unhappy with the entire TFS UI experience and not TB in particular. I’d be happy to work on your suggestions if you offer specific examples on what you’d like to see being better. Thanks for the feedback!

Comments are closed.

Skip to main content