Today faced a challenge, due to some infrastructure issue our TFS and MTM was down and the whole testing team was sitting idle as they can't access their test scripts. Is there a way that we can export/download test scripts from MTM to local machine (as we do for codebase i.e. local machine copy) so as to avoid this type of problem.
I know this will be a common problem but somehow unable to find a answer to this.
You can export an entire test plan from the web interface and you have the possibility to choose if the test cases with steps are included or not in the export.
You cant export for offline access. You can create static report of all of the test cases and steps in the web access. There is however no easy to get the data back in.
To be honest this is not a common ask as most folks TFS servers do not randomly go offline. As TFS is a production system you should get at least four nines SLA. If you don't then I would recommend that you move your TFS to VSO.
Related
I am working on an integration approach for integrating Rational (IBM Jazz) Quality Manager (RQM) and Requirement Composer (RRC) with TFS.
As the teams are moving from ClearCase to TFS, what we are looking at is still being able to manage the requirements in RRC and manage testing using RQM.
The flow will be something like:
Requirements are planned and detailed in RRC
Create work items in TFS connected to the Requirements in RRC
Create design and code using VS2010 and managing the version control in TFS
Creating test plans and test cases in RQM (connected to requirements in RRC)
Run test against builds in TFS
Publish test results in RQM against builds in TFS
Run reports in RRC, RQM and TFS that links up the items across the platforms.
I have started looking at TFS Integration platform. But shall like to have your guidance for an early resolution and better solution approach and how to achieve this.
UPDATE:
As I was not getting good response here, I put this on MSDN and I really got good response there. I am not deleting this post here, but give the link here:
http://social.msdn.microsoft.com/Forums/en-US/tfsintegration/thread/fcb20f89-6801-4ad1-8f46-3df68325ca8d
Please follow this.
I'm new to TFS and we're trying to automate the test / build / deploy process for our builds.
The problem I'm experiencing is that when I try to start a build with automatic deployment (for a webpage) using the MSBuild Arguments it complains that it doesn't have the necessary DLLs and I've figured out so far that they get installed with Visual Studio Premium or Ultimate, but then other people complained that something like Visual Studio shouldn't get installed on a Server =)
The TFS is also the build server for now and I'd like the know if there are any known requirements for these things to work:
Automated UI Testing
Automated deployment
Automated publish
Code Analysis
I'm working with TFS 2010 and Visual Studio 2010 (Premium). Any help, comments or different approaches are welcome =)
The way we handle that on my team is to actually check all the references needed to build the product in to source control. Anything beyond the .NET framework itself, and whatever you get for installing a build controller/build agent, gets checked in..
Positive bits:
Setting up a build agent is trivial (just "Install Server 2K8R2, install build agent, start building").
Don't have to worry about complicated SDK installation to match people's dev boxes.. References are all the exact version checked in to source control.
You get binary version control, which means if you need to do a maintenance release and build against last year's version of a particular API, it's super easy.
Negative bits:
Bloats your source control a bit
Feels weird checking binaries in to source control
Need to be very vigilant about maintaining structure and cleanliness of how you check in the binaries, otherwise it can easily get out of control
Beyond that, as far as making the test bits work from your build agent.. Probably the easiest way would be to install the test agent. The UI automation stuff in VS2010 is the "CodedUI Test" framework.. It extends the normal VS Unit Test framework, but requires some additional registrations to work.
More complicated, but super useful longer term is to set up the full "Visual Studio Lab Management" platform. Downside is, to fully leverage it you'll need to hook up a System Center Virtual Machine Manager server and at least one Hyper-V host, and build out a virtual machine with a "Clean" VM snapshot (everything except the product you're testing installed). Once all that's in place you get a really slick end-to-end build-deploy-test experience.. You trigger the product build via the build system, once that completes your environment is restored to that absolutely clean state (no worries about leftover bits from last version corrupting your testing, etc), the product gets published to this test environment, and then it executes your tests.
Not sure if you're using TFS for workitem tracking, testcase management, project planning, and whatnot.. If not, the lab management stuff may be too heavy-weight to mess with. More info here if you're interested in messing with that part. :)
Your build server needs the appropriate versions of Visual Studio. For instance, if you want to do database unit tests, then the build server needs VS Ultimate to be installed.
If there's an issue with having "client" software installed on a server, then use a separate build server. It makes perfect sense for a build server to have the necessary tools installed to perform builds.
So, we're using continuous integration in our current Team Foundation Server 2010 setup, and so far it's working great. We're doing shelvesets, the build is running on the Build Manager in TFS, and it's also running our MSTest unit tests for us.
My question is, and I can't seem to find any information on this, is how to move the "build unit" that is created by the Build Manager on TFS to another server?
Aka, how do I "promote" this build to our QA, staging, etc... environments?
Before, we've were using VS2010's Publish Web feature, which allows us to set up publish "profiles", and each profile can have a different web.config related to it. This is really useful for anything we keep in our config files, like db connection strings, paths to app servers, etc... changing automatically based on our Publish Profile. We choose the profile, build locally, then use the "Publish" button to move the entire app to another server.
This setup worked great for when there were two of us working, and we were using TFS for just its source repository, but now the builds are happening on the TFS server.
What I'm looking for is a way for when TFS does the build for us (it's no longer being done locally on our machine, but by TFS Build Manager) to:
take into account which "publish profile" to use. This will effect what web.config is used and other items you can associate with a profile in your IDE.
once the build is created, to find a way to "push" the build to one of our other servers (QA, Staging, production) FROM TFS.
I don't even know if that is possible or not. Maybe it's still a manual job to take the build created on TFS, and copy it over by hand, and unzip the project/files into the correct file path on the deployed server? Or maybe it's part of the workflow in TFS, and I still have yet to find it.
This is surely possible already from TFS. Read the posts from Vishal Joshi on this topic, starting with: http://vishaljoshi.blogspot.com/2011/07/documenting-key-end-to-end-deployment.html
The solution I came up with is I wrote my own build handler for TFS, and use that code to push builds to our different environments. Here is the link I used to help me: http://geekswithblogs.net/jakob/archive/2010/10/27/devleoping-and-debugging-server-side-event-handlers-in-tfs-2010.aspx.
If anyone wants more specifics, just contact me and I'll be glad to help you.
Currently our build solution is set up using TFS + MS Build scripts.
TFS is also being used as a CI server.
I've seen several posts on this site telling people about other CI solutions.
Are there any compelling options to move to another Solution for our build system?
Or in other words what are we missing out on by using TFS?
EDIT
We are using TFS for source control / issue tracking and I think this is a good solution, im just wondering about the other options for build server / CI server integrating with TFS.
The main problem with TFS is that if you have a server crash, restoring your source code is non-trivial. This is unbelievably bad since the most important aspect of any source control system must be to be fail-resistent, at least if you perform all backups as you should.
IMHO the greatest benefit of TFS is that everything is integrated in the IDE: work items, bug tracking, CI, Code analysis, ...
I have used TFS in the past but my current company use SubVersion/Team City/FogBugz to implement the same functionality provided in the TFS solution.
I would say that from a technical implementation perspective, you can gain additional features from a non-TFS system that TFS would be a nightmare to configure.
However, that said, one of the biggest reasons for not going for TFS is the cost of running such a system. The big advantage of TFS is the integration of everything which makes people use it more as the more you put in, the more you get out. The worst case scenario is a system that people can’t be bothered using which adds no value to the company’s development.
In my opinion, if you are already on TFS and can afford to stick with do, do just that!
This seems like it should be obvious so maybe I am not understanding something. I have TFS setup. My web apps code is in source control. I can check-in/out and create builds but I don't quite understand what the recommended method for publishing the code to the production environment is? I was looking for something like "publish release to web server" but can't find anything. I think my larger problem is that I can't find a good work-flow diagram for how a team is supposed to move from editing code to testing and then to deploying to the production servers all within the TFS system. If anyone has any thoughts or links to good walkthroughs on publishing a website from within TFS that would be fantastic.
For the workflow I would suggest the code promotion model.
Within TFS you have the idea of build quality. SO when you initially check code in the build will kick off with a quality of say "ready for test" if the build passes the testers can decide when they want to take a build for testing, when they have tested a build they can mark it as "ready for deployment", you can then use that realeas to deploy.
Unless things have changed in TFS 2010 you have to roll your own implementation for deployment. We used MS build to build MSIs using Wix, then had the testers test the deployment process for us.
Have a look at the following msbuild extensions to help with deploying to test/live environments:
http://msbuildtasks.tigris.org/
http://msbuildextensionpack.codeplex.com/
I would really recommend you spend a little time on your build process and get it water tight, there is nothing more embarrassing that deploying a release to live that doesn't work and the client loosing faith over it.
I don't believe there is a built-in mechanism in Team Build to publish websites, however this can be achieved by overriding AfterDropBuild or AfterEndToEndIteration in your build definition to include necessary tasks for copying the build output to your web servers.