We recently upgraded to TFS2012 and now we have an MVC app and a WCF Service both built in VS2012 that WILL compile and build but will NOT deploy. Any ideas on what I should research? I read that MS now only allows deployment of certain types of files and web files are not of that type. Thanks so much for your time.
The default build processes in a standard on-premises TFS2012 installation do not do any deployment out of the box. Therefore in answer to your question I would personally look at the custom deployment steps that are happening and maybe put some additional logging in to identify the problem.
Often being able to remote desktop into the build server and then perform the steps that your build process would have taken is a good way to check things like this.
As the upgrade process usually involves re-installing the build agent my guess would be that it could be a permissions problem, maybe the build agent was installed as a different user to how it was running in the TFS 2010 configuration and that process/user does not have permissions to deploy the build. But that is just a guess - digging into the deployment steps that you added to your build process should help you track it down. Good luck!
Related
Issue:
I am trying to automate the build and installation of DNN modules on a build server. We are currently using DNN 5.5 and TFS for source control and build automation. The TFS build works as expected (getting, compiling, building/copying DNN packages) but when executing the Install.aspx?mode=InstallResources URL we get the "Site is under construction". The event log for DNN does not reveal any information. If I log in to the build server using my Id or the build server id and run the this script, everything works as expected. It’s when the script is started from the scheduler that the DNN InstallResouces URL has issues. The build id used is an administrator on the build server. I have search the web for others doing the same but only found one that stated they wrote an exe utility that submits a HTTP request and parses the response for the success or fail of the resources. Is this the only option? Any other ideas?
I would recommend that you nit work with Instances of your software from build. It is a bad practice and you need many workarounds to get things going. I would recommend that you install Release Management which is specifically designed to do what you are asking. It just has better tooling and configuration options for this.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
I created a post on this not to long ago and you can get more info in Professional ALM with Visual Studio 2013 on building and configuring a release pipeline. This way you are deploying tested binaries and not creating untested new ones for future deployments.
Resolution: The issue was resolved by setting the correct permissions for the TFS build user to execute the DNN install resources. The script being executed needed to load the Windows user profile when the script was being executed.
I really don't understand the meaning of tfs build although MSDN provides many definitions.
For example, I have an asp.net project. If I passed the local build on my local machine and I checked in the code. Everything is fine.
I used to copy(publish) the code to the server, that's it.
Why we need tfs build? What is different between tfs build and local build. You might to say, there are build history that can be reverted to an old one. But I think that since code was versioned, we can checked it out and rebuild in the local machine and republish the project to the server.
When I was using TFS, I could run local builds on my local machine. And then when checking in code, TFS would automatically perform a build on the build server (this is specified via a build definition). In that case, the build server was located on the machine which housed the master copy of the TFS source repository.
It's not enough for each developer to build locally as they may not have the latest code. I think the point of a TFS build is that it will run a build on the build server which has all the latest code. I think the idea is that if the build is successful on the build server, then it's deemed safe to check in the code.
That's how I understood it anyway. It's useful if there are multiple developers working on a project. If there is only one developer on one machine, a separate build may not be necessary.
Did that answer your question or did I misunderstand?
The answer of CiaranG is indeed one way to look at it.
Also the TF Build server has the possibility to build your code with signed 3rd party DLL's and put everything in a place as it is every time a new version of your software. This can be then useful for testers that need to test your software and don't need development tools.
Besides CiaranG's description of the Continuous Integration benefits, there is also the security and cleanliness. Allowing production code to be built off of developer machines where there is a chance for virus/malware may be present and the configuration is not known/documented is just poor policy. By building it off a protected server, from which no surfing is ever done, you are ensuring a safe, clean, reproducible environment which adds professionalism to your code deployments. TFS also adds in reporting build metrics over time, accountability, and archiving.
I am going to be responsible for implementing TeamCity into our development environment pretty soon. I have searched around and see no real answers, does anyone know if there is a 'best practice' when it comes to a build server. Is it Ok to install TeamCity on the same server as TFS, is it preferred? Or should I install it onto a dedicated server (which I can do).
Thanks
I would think that Microsoft's own advice about TFS would also be relevant here:
You can host a build server on the same computer as your Team
Foundation Application-Tier Server, but, in most of these situations,
this build server should not host any build agents. Build agents place
heavy demands on the processor, which could significantly decrease the
performance of your application tier. In addition, you might want to
avoid running any build server components on the application tier
because installing Team Foundation Build Service increases the attack
surface on the computer.
So, you might see unnecessary slow downs on other operations like version control, work item tracking, etc.
Install it on its own server, you don't want it grinding tfs to a halt when it is performing a build.
You could install the Teamcity server on the tfs server but if you can a separate machine, but as its the agents that do the work it those that definitely need to be on a different machine from teamcity and tfs if possible.
I have a long-time-to-build (setup) project in a Visual Studio 2010 Solution. It is set not to build in the Solution configuration. That way, when a developer builds locally they are not burdened with waiting for the setup to compile in Visual Studio.
However, I am looking for a way to change the configuration in tfsbuild or msbuild files so whenever things are built on the server, the setup project is always built, regardless of what the setting might be when a developer checks in their solution. TFS 2008 is the source control system but just a plain Server 2008 (with devenv fully installed) is the build server.
All clues appreciated.
Thanks.
I would suggest creating a new configuration in your solution, named e.g. Release_Setup, that way you have seperate configurations for developer and setup build (note that developers can choose that config and build everything locally if they so choose, which is quite nice when all Build agents are busy and you want to check that everything's fine).
In Solution Properties->Configuration Properties->Configuration you can even tell it to build the normal Release Configuration and still choose which projects to build and which to exclude.
Hope this helps. I haven't actually tested this, so please try it and comment back if there are any problems or this doesn't solve your specific question.
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx