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.
Related
We have just installed TFS 2015 (Update 1) on-premise and are trying to create a Continuous Integration/Build system using the new TFS Build system. The build works fine, and gives me a green light, but when I look at the default build it has only built the binaries from the bin directory, and there seems to be no easy way to deploy the app on-premise to a local server.
There are two deploy options for a filesystem copy, and a powershell script, and it would certainly be easy enough to use them to copy files to a new server, but since the build only built the binaries, I don't see a tool to gather up the Web artifacts (cshtml, images, scripts, css, etc..) for this.
After an exhaustive google search, I've only found one article which talks about this at:
http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/
However, this uses WebDeploy and creates a rather messy deploy package.
How can I deploy the site (standard MVC web application, in fact my tests are using the default boilerplate site created by the create project wizard) complete with artifacts to a local server in the easiest possible way? I don't want to have to install WebDeploy on the servers, and would rather use PowerShell or something to deploy the final artifacts.
The build is just the standard Visual Studio build template, with 4 steps (Build, Test, Index & Publish, Publish Build Artifacts).
We use "Visual Studio Build" step and as Arguments for MSBuild we use following line:
/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration)
On Variables tab page DeploymentConfiguration has to be configured. It must be the Name of the publish Profile (filename of the pubxml file). If the file Name is Build.pubxml the publish profile is Build.
for example:
/p:DeployOnBuild=True /p:PublishProfile=Build
I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager.
His msbuild arguments look like this:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website
The difference between this and the accepted answer is that this parameter set stages everything in an artifacts folder, and then saves it as part of the build. We can then deploy exactly the same code repeatedly.
We capture the web.env.config files alongside the for-deploy folder and then use xdt transforms in the release process to ensure everything gets updated for whichever environment we're deploying to. It works well for all our web projects.
We use WebDeploy/MSDeploy for 40+ applications and love it. We do install WebDeploy on all our servers so we can deploy more easily but you could also use the Web Deploy On Demand feature which doesn't require WebDeploy be pre-installed.
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
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!
I have web site project hosted at TFS Cloud. And I have hosting account at Godaddy, which allows me to deploy sites via FTP only.
I create publishing profile in Visual Studio 2012 and can successfully execute publishing to FTP in Visual Studio.
The problem:
This the task cannot be done using any standard TFS Build template and neither its standard workflow activities, even though it should be a trivial thing people do with TFS Build server. There is no ready "copy-paste" solution (wpp.targets) on MSBuild for that:
"C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Deploy\Microsoft.Web.Publishing.Deploy.FTP.targets"
Clearly says that it is not supported through the command line, one should use VS for that.
Question:
Is there any implemented solutions of that task that I can just copy paste to my team project with few clicks?
I expected to see lots of articles about it in web, however I didn't find any simple existing solution. Articles like this require me to install some 3rd party software (which is not an option in most popular hosting like Godaddy), and it's not clear how to use it with TFS.
In the default Build template, go to the process section and choose Msbuild Arguments and give the publishing profile.
MSBuild Arguments : /p:DebugSymbols=false;DebugType=None;DeployOnBuild=true;PublishProfile=YourProfileName
when Build got succeeded, it will be deployed to the ftp location.
this link may help you more : http://www.hanselman.com/blog/TinyHappyFeatures3PublishingImprovementsChainedConfigTransformsAndDeployingASPNETAppsFromTheCommandLine.aspx
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.