We currently use TFS to deploy builds to our servers in different environments such as QA, PreProd and Prod. In the current method, the build agent gets all latest from TFS, builds and publishes to whichever environment specified.
I know that you can actually just publish just to a drop folder where it creates PublishedWebsites folder, but how can you publish to servers from drop folder mentioning specific build? For example, there may be build #7, which our QA team has certified. We want to make sure that that is the build that is going to production and not latest content which might have some check ins from other team members.
Any help would be appreciated. I referred this link, but it is mentioning about overriding OutputRoot directory in publish.proj file, which is not created in the solution that we created using Visual Studio 2012.
http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build
You have multiple way of solving the needs.
The best option is to use LabManagement; it will take care of computing the correct Drop folder. See Using a Lab Environment for Your Application Lifecycle for details. The idea is to use the build-deploy-test workflow to deploy and run tests on a group of machines running Test Agent.
You can setup a more sophisticated process using Release Management, a new feature of TFS 2013 that you can add to 2012 as well. It offers to design your promotion process and control who authorizes deployments.
You should neither use Build or Lab Management to do deployments. Both are poor solutions for this as this is not what they were designed for.
Microsoft added a dedicated release management tool with visual studio 2013. I have configured and used it with both 2012 & 2013.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
This will be much easier than either of the other tools.
Related
I'm publishing my application to two separate IIS servers. The problem I have is when publishing to profile01 it builds the project and then publishes successfully. I then Publish again but switch to profile02. Upon doing this it builds the solution again (changing assembly version #) and publishes to the other server.
Now I have mismatched versions between server 01 and server02.
I'm assuming that when I change Profiles it makes a change somewhere to the project, once that change is made VS assumes a new build is required.
Any thoughts, suggestions, references would be greatly appreciated.
You can create a Web Deployment package & deploy this package to multiple servers. Documentation on how to create and deploy using the package is available here - https://msdn.microsoft.com/en-us/library/dd465323(v=vs.110).aspx
My VSTS Repository contains 50+ Visual Studio projects of Azure Web Apps and I was requested to get an automated build and release process in place for one of them. I went thru and selected a Visual Studio template and on the build solution I selected only the one project I wanted to do a build and release on but when I queue the build to run it starts doing a get latest on every project in the repository. This is unacceptable because it would take hours to get latest on all the projects just to compile and publish one website. This makes no sense to me. Is there a way to limit what the build does a get latest on?
Depends on the repository type you're using. In case you're using TFVC, you can go to the Repositories tab and configure your workspace mappings to match exactly what you need for your project.
If you're using Git, then you're out of luck, the way git repositories are synced, the whole repository is always fetched when a build is initiated.
If you're using your own build agent, you can configure it to retain the sources directory, in which case only the differences are synced when a build runs.
Is there a way or a tool to force users to write a comment to TFS every time a release of a project is created?
I am searching for something similar to the comments that are input when a file has been checked in to TFS, only for releases instead.
We are having a hard time keeping track of the changes made each time a new release is deployed and I imagine this would be a huge help in keeping track. I am currently using Visual Studio 2012.
What you're looking for is a release management solution, so you can automate and track your software as it's delivered through a pipeline from your dev environments up through to production environments.
You didn't specify what version of TFS you're using, but if you're using TFS 2013 or earlier, you can use the Release Management server. This software is being deprecated, however, so I wouldn't recommend starting out with it now unless you have absolutely no other choice.
In TFS 2015 Update 2, there is a fully integrated release management hub in TFS. This would be the recommended approach.
I am have built an MSBuild project that has
the main .proj file with several Targets inside,
several .targets files
and several .rsp response files to run this project in several ways. Such as
Build, Clean/Build/Deploy, Clean/Build/Test/Deploy.. You get the idea.
What I now want to do is take this MSBuild and run it in TFS scheduler after I pull the source code. So the workflow should be
1. Pull the source code in TFS
2. Run MSBuild project in the scheduler so I might set up tasks to run hourly and nightly.
The MSBuild will take care of Deploying to IIS, unless someone has a more efficient way of deploying after an hourly build.
How can I accomplish this in TFS?
Thank you
You can use the Team Explorer UI in Visual Studio to define a "scheduled" build definition.
http://visualstudiomagazine.com/articles/2012/04/11/creating-a-build-definition-in-tfs.aspx
If you want to take this to the next level, research "continuous integration" which is also a built in capability.
I am new to sharepoint and installshield. My responsiblity is to build and deploy the sharepoint solution as a package using istallsheild. Previously I was using solution package wsp and content database restoration. But now the client wants to deliver the total solution i.e. dlls, ascx files, xml files, servce files(.cs), feature files using installsjield from development server to another (test and/or client) server.
Can any body help me on this: how to do the sharepoint deployment using installshield?
thanks in advance.
I presume you are using SharePoint solutions to package dll's, ascx and xml files for deployment to a sharepoint server. These solutions are built using a tool like WSPBuilder.
If not: YOU SHOULD!
If so: Why not use SharePoint Installer? It is an installer wrapper around a .wsp (SharePoint solution) file. It will check for the existence of a sharepoint installation, if the required services are started etc.
For deployment to a test machine: Why would you need the .cs files? If you want to test (debug) code on a test machine, I suggest you use either continuous integration using a tool like CruiseControl.NET, or just install Visual Studio on the test machine (which I presume to be a dev test, not a client test machine) and get the latest version, do a build, then roll out the solution.
And what do you mean with "client" server? is there some windows app that's communicating with sharepoint included in the installer? If so, I suggest separating the SharePoint solution from the actual windows app. They might share DLL's but are not supposed to be in the same installer.
We are using a tool (open source - saf.codeplex.com) to automate the Sharepoint components using MSBuild/Features/STSADM etc. Recently they have upgraded this to use WIX so that we can deploy any SharePoint components.
saf.codeplex.com
It has got an very good documentation and also we got a good support in fixing and implementing the SharePoint automated deployment in our premise.
Thanks
BalamuruganK