I have been using the Build-Deploy-Test build workflow for TFS 2010 (see here http://msdn.microsoft.com/en-us/vstudio/gg131922.aspx) and would just like to know if there is a way you can queue one or more of these to run on the same lab environment?
I have come up with a brittle but (mostly) working solution to this by modifying the Build Template. I set the 'environment in use' flag whenever the workflow starts, and any subsequent workflows loop and wait for the flag to be cleared.
My solution works most of the time, but occasionally I experience race conditions and both workflows try to start at the same time, one 'winning' and reverting the environment to a test-ready snapshot first.
As you can tell, this is a poor solution but a quick one! Is there a proper way to queue Build-Deploy-Test workflows on an environment?
There is no way to do this out-of-the-box with TFS 2010; this confirmed by allen from Microsoft (see comments).
I solved this issue more satisfactorily by implementing a custom build activity that maintains an in-memory register of all builds using a particular lab environment. I interact with this activity using a modified version of the DefaultLabTemplate, waiting to start the build until the configured lab environment becomes available.
The solution is by no-means perfect, as it does not scale beyond a single build controller but works sufficiently for the needs of my organisation!
Related
We are using Microsoft Team foundation server for version control where multiple developers are working on a branch and check in and check out the code.
How can a developer A be notified via email or SMS that his code got overwritten during the checkin by developer B.
Developer A needs to know this ASAP because the code changes of developer A will not work when its deployed into QA.
We are tring to save time in a fast paced development environment and trying to avoid code overwrite issues.
The easiest way to allow continuous parallel development and prevent a checkin from one person breaking the code of others, is to use a CI server. TFS supports this through Team Build.
Though it's preferred to run team build on a dedicated build server, it can be installed side-by-side on your main TFS server and it's possible to install the Controller component centrally and use your developer's workstations as agents.
There are two types of build triggers that can help you out here:
Continuous Integration - this triggers a build of all code directly after every checkin. It will tell you quickly that something did not compile. If you are doing unit tests it can even run these and tell you that a test is failing.
Gated - this will force a developer to shelve his code and will only check in the code when the build of the latest version plus the changes in the shelveset succeed. This may seem even better, as the code in source control will never be in a broken state, but in reality I prefer the ci trigger. The main reason for that us that Gated builds can't happen in parallel (due to their nature) and can actually delay the notification that the code is broken.
You can easily configure email alerts through webaccess on specific build outcomes. You can also configure alerts on source changes, but there is no option to only warn people who have edited these specific files before.
You can also run the Build Notification tool from the task tray to show a notification in Windows.
Though this will not tell the person whose code has just been overwritten that it's no longer working, it will tell the person I rewriting that code that he should pay more attention when checking in ;).
Of course you can configure a team alert that notifies everyone when the build breaks (as that's generally called), and there are funny ways to show the build status through small apps like "siren of shame", which provides a build monitor service that can be connected to a USB alarm-light that turns on and provides noise whenever someone does something stupid.
If you need to avoid this problem during check-in & merge, then I would recommend disabling multiple check-out. This allows file to only be checked out one-at-a-time and can prevent confusion on team projects.
If you need to do farther down the line, you can create TFS Alerts when any code is checked in and sent out to a distribution list, but it would not notify when specific contributions from a specific developer is altered - only a list of altered files during the check-in.
When I queue my builds in VS 2013 using the "Hosted Build Controller"(Visual studio online) my build keeps saying:
![enter image description here][1]
Position In Queue = 1 (Waits in the Queue for more than half an hour)
It is not starting my builds inspite that fact that I have no other builds in queue or or running.
Sometimes it gives me the message saying the connection to the build server was lost.
Not Sure why this is happening because earlier when I initiated my builds using VS 2010, my builds used to start immediately.
Any help is greatly appreciated.
You're dealing with what can be a painful issue. Have you tried creating another agent? You can specify which agent to use when queuing the build. If other agents work and not this once, you may have encountered a bug that requires updates to your current version of TFS.
If new agents consistently fail or don't fail always, then you're dealing with a bigger issue that can be due to performance, cross-geography issues, or with too much latency loading your template. I believe one thing that can cause issues with this is having too many agents. I would also try clearing your build caches out. C:\users[user]\appdata\local\temp (i.e. BuildAgent/Controller). Also, definitely make sure your build software matches your TFS version (including the update). Slight differences there can cause issues.
I'm trying to work out an automated Build-Deploy-Test workflow using Lab Management/VS 2010 and everything is working ok... except for one small thing.
In my build definition, within the process>environment I set a snapshot that I want the environment to be reverted to before deploying, and this works fine, but when the snapshot is reverted to, the environment is stopped but not restarted.
What results is that the build waits indefinitely for the workflow capability to be available on the environment.
A temporary fix is to just watch and wait for the enivonment to be stopped, and then to start it manually and everything will proceed as expected... but this is hardly ideal.
This is happening to everyone on my team, and none of us have come across a solution. Has anyone else seen this and solved it?
You'll want to take the "Initial Snapshot" when the VM is actually turned on. You can do that, or you can customize the Lab default build process template and include a StartEnvironment workflow activity after the restore snapshot phase.
My suggestion would be to just take the snapshot when the VMs are turned on though. That's the way I have always ended up doing it.
I'm trying to create a C++ CI environment by using CDash.
I've got CDash running on my computer and I can send some results to it from the CDash clients, by running the ctest manually.
I'm a bit lost on how to setup a client to automatically compile and test the code when the source code changes in the version control system (subversion), or at specific times.
I have the Mastering CMake book, but it doesn't seem to say much on that topic.
Is there any way to do the continuous build without hacking around with scheduled tasks / cron?
Is there any good example that would be useful to check out?
Can I somehow order to run a build on some site from the Dashboard? I kinda remember seeing this somewhere but I'm unable to find it now.
Is CDash any good for CI environments? (use comments to answer this one)
CDas#Home might be the solution. Generally I have my continuous machines run a script on a nightly cron job that polls the repository every couple of minutes for ~24 hours.
I just discovered (the hard way) that if you deploy your application to a device after doing a "Rebuild" or a "Clean -> Build" from Visual Studio your app is first uninstalled and then reinstalled resulting in the isolated storage files being wiped.
The Application Deployment Tool always seems to do uninstall - reinstall irrespective of whether it was an incremental build or not.
Has anybody found a workaround to this? Of course, the most obvious one is never to rebuild your application, but what if you accidentally do? Currently, I don't have all the generated files under source control, so if I were to try to build the app on another computer it would be a rebuild (maybe I will add all the generated junk into source control if no one has a workaround)
If I can suggest an alternative appraoch.. I think you will find it beneficial in other situations as well if you can introduce a little process to the generation of your test data so that it is easier to either a) restore or b) generate.
You could for example have a debug build only feature to upload/download the files on the device to a wcf service running locally on your PC (a simplified version of what Rongchaua did here).
Or, more work, if you are willing, but offering even more additional benefits would be to develop some automated testing capability into your app.. starting with generation of initial test data. Here's something you could look at to get started on that path.
Claus Konrad Blog: WP7: How to unit test a MVVM Light WP7-application
Granted these would take a bit of effort, but it's an approach that gives you some independence from manually generated test data, which in my experience invariably turns out to be a hassle at various times. And once solved, you find all sorts of reasons to thank yourself for doing it later.. whether it be saved time, or more robust testing because you can afford to be more aggresive with your test data/test execution and manage multiple test data configurations.
There is a a workaround:
open the solution configuration manager
next to build is a deploy column, uncheck your project
press F5
This will launch the app that is already on the device without overwriting it (and deleting its storage).