We've got a project with a test, dev and production release. The test and production releases are set to manual. I want to manually run the release, but don't know how to do that unless I edit the release, change the environment variables from "No automated deployment" to either "After release creation" or "After successful deployment on another environment", then run the build. Then change it all back again. The build makes all of the artifacts available, for all of the releases.
But I figure there must be a way of running the manually release, manually. I just can't find how nor where to do that in TFS's web interface. How do I do this? (Please forgive me if I've stated something wrong. Hopefully, I've made myself clear.)
We're using TFS 2015, on-premise.
Once you create a release, open it up. The release has a "Deploy" button. Clicking that will show you a list of the available environments, and you can choose one to deploy.
I don't have an instance of TFS 2015 readily available otherwise I'd post a screenshot. Here's a screenshot showing the general location of the Deploy button from Microsoft's documentation:
Related
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.
Quick question: If I were to set up my build server to publish to a test environment after every check-in, wouldn't that constantly interrupt the testers if the ASP.Net site they are testing would come down periodically as developers check in their changes?
We are looking to ensure the bugs we have marked as resolved are always available for testing, but we also don't want our testers to have the site come down in the middle of their tests.
Thanks!
Chris
My suggestion is to have a dedicated environment for each tester (TFS Lab is a great way to achieve this). Then allow each tester to manually kick off a build that updates their environment with the latest build whenever they desire.
If you must do a shared test environment, then I suggest not updating every build for specifically this reason, but instead doing a nightly build that updates it (and/or using a manual build that testers can run on demand).
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.
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.
I have a Team Foundation Server 2008 Installation and a separate machine with the Team Build service.
I can create team builds and trigger them manually in Visual Studio or via the command line (where they complete successfully). However check ins to the source tree do not cause a build to trigger despite the option to build every check in being ticked on the build definition. Update: To be clear I had a fully working build definition with the CI option enabled.
The source tree is configured is a pretty straight forward manner with code either under a Main folder or under a Branch\branchName folder. Each branch of code (including main) has a standard Team Build definition relating to the solution file contained within. The only thing that is slightly changed from default settings is that the build server working folder; i.e. for main this is Server:"$\main" Local:"c:\build\main" due to path length.
The only thing I've been able to guess at (possible red herring) is that there might be some oddity with the developer workspaces. Currently each developer maps Server:"$\" to local:"c:\tfs\" so that there is only one workspace for all branches. This is mainly to avoid re-mapping problems that some of the developers had previously gotten themselves into. But I can't see how this would affect CI.
UPDATE: Ifound the answer indirectly; please read below
Ok I have found the answer myself after several dead ends. In the end I fixed this unintentionally while fixing another issue. Basically we had just turned on the automatic execution of unit tests for our builds. The test would run sucessfully but then immediately the build would bomb out with a message saying it was unable to report to the build drop folder.
What was happening was that while the Build service runs under one account and has a set of rights; some of the functionality is actually driven through the TFSService account. fter wading a heap of permissions I had my tests being reported. Then I noticed that builds had started to trigger on check-ins; I can't tell you exactly which permission fixed this but hopefully this answer will at least set people down the right path.
One other note a few of the builds started failing due to conflicting workspace mappings - this was a separate issue that I resolved by deleting some obsolete workspaces using the Attrice Sidekicks for Team Foundation tool.
Hope this helps somebody else.
Select your team project from team explorer, then right click on the Builds folder. Select a new build definition and then select the trigger tab. Move the radio button to "Build each check-in (more builds)"
More info can be found here
MSDN How to: Create a Build Definition
Are there any errors in the log on the TFS application server? Anything that indicates that it tried to fire but failed?