xeam Build Definition Extension

Trial

Xeam Build Definition Extension provides an easy way for handling tasks on build definitions. - copy, merge, branch, save and restore Build Definitions from Source Control - track and rollback changes, view history for Build Definitions - import Build Definition from ...

(0) Review
Visual Studio
2012
Download (328)
6/19/2014
2.4.4206.7
View
E-mail Twitter del.icio.us Digg Facebook
Add to favorites
Description
Reviews
Q and A (1)
Sign in to write a review

Be the first to write a review.

Sign in to start a discussion


  • Compatibilty with Visual Studio 2010
    3 Posts | Last post July 22, 2014
    • Tools looks great, exactly what i was looking for but One issue I have is its compatibility. Let’s me present the scenario, we have 6 people who have permission to access and update the build definition. I installed this tool in my machine and update something, I am able to view the history and everything looks good. Now let’s say one of the other team member has Visual Studio 2010 installed and he has not installed this tool, he accessed the Build definition and modify something. Nothing is coming up in the history which defeats the purpose I am looking for i.e. any modification to build definition accidently or intentionally should be traceable. So, I believe this tool does not provide that capability, Please correct me if I am wrong?
    • I apologize for some typos and grammar above, I just realized after submitting.
    • The extension needs to be installed in all Visual Studio Versions where people changed Build Defintions to get a full traceability. There is no support for Visual Studio 2010, so if one will edit a build definition in VS 2010 you will not see the change in the history.
      But if someone does a change by accident it is possible to rollback the change to a previous state which was stored in source control. You can follow the process for rollback a change described in our knowledge base: http://www.xeam-solutions.com/knowledge-base/build-definition-extension/rollback-of-build-definition-changes.html
      
      As conclusion a process for you which can work would be, to do a necessary change on build definition within VS 2012 or VS 2013, so everything gets stored in Source Control. If someone does a change by accident in VS 2010 you can rollback the change. If you want a change done within VS 2010 to be stored in Source Control, you can open VS 2012 or VS 2013 and select "Save To Source Control" to store the changes done in VS 2010 to Source Control.
      
      I also could think of having some kind of check/compare so that it would be possible to see if there is a change that is not tracked.
      
      Kind Regards,
      Markus