I have a console application that I am building on a on-premises tfs 2015 with a Visual Studio Build. What I want to achieve is:
If the application is executed on a dev machine during normal development there will be a simple message "Hello Developer" and if it was deployed in a qa environment and the tester runs it from there it should print "Hello Tester". Just a simple demo.
So I think I need an App.config to be able to store a configuration that will than be changed during the build process. I was confident that this is a no brainer as I found a lot of websites describing something like this but it turns out, that they all are not revealing the interesting bits like
How does the App.config needs to look like?
How is the variable used in C# code?
What are the needed settings in the Release Management Client?
What are the needed settings in the on-premises TFS Build Definition?
or were out-dated (TFS 2013 (1), RM Client 2013 (2)) or were using Visual Studio Online/ Team Services or were using custom tasks.
Can someone explain me, how to achieve the described scenario "Hello Developer"/ "Hello Tester"?
Thanks a lot!
We use MSDeploy for this type of setup. You can extend MSBuild by adding an Import line in your csproj file to a new .targets file in your project. Reference the MSDeploy task and use that to create a MSDeploy package for your console app. Finally create Parameterization files to define the config section you want to transform and SetParameters files for each environment with the appropriate message.
This blog post is for a database project but the basics steps are the same.
Within RM you would use MSDeploy to deploy the package with the appropriate SetParmeter file against the target server via a PowerShell command.
Have you tried with SlowCheetah?
This package allows you to automatically transform your app.config (or
any file) when you press F5 in Visual Studio. You can have different
transformations based on the build configuration. This will enable you
to easily have different app settings, connection strings, etc for
Debug versus Release. If you want to transform other files you can do
that too.
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've been trying for a week to deploy a webrole to Azure Clous Services without quite getting there.
Here is my setup:
I've got a cloud solution with a cloud project and a MVC application (standard no changes to template yet). Its under source control in Visual Studio Online.
I'm using octopack to try generating the nuget package
I'm using the buildt in nuget repo from Octopus
The Octopus server and tentacle is hosted on a VM in azure
I've created a step-template for my deployment step (see this article)
My plan:
I'd like to have a CI build to a dev-service and a seperate build to push my project to the staging environment and roll it onto the production environment using Octopus.
My problem:
The packages that are produced by Octopack seems to not contain what they should. And I've tried to play around with the nuspec file included in my webrole to get it just right. Something ends up missing either way i try.
Have anyone gotten this to work? I'd appreciate any tips pointing me in the right direction as I've slowly been running out of ideas. So i turn to you my fellow nerdlings for some much needed help.
Regards
ZiGGstern
Correct me if I'm wrong but it looks like you're in need of the octo.exe to automate deployments after build within Visual Studio/TFS Online to your target environments.
I'm trying to focus on this statement:
I'd like to have a CI build to a dev-service and a seperate build to
push my project to the staging environment and roll it onto the
production environment using Octopus.
You can configure within your build-template, using the "Post-Deploy Script Path" a PowerShell script to call the Octo.exe (with an API Key) and fire off a deployment for your desired environment(s). You can customize this per build if you so choose. I've used this method by creating a folder within the root of my Solution (I call it 'Tools' but the name doesn't matter). Within that Tools folder, I add a PowerShell script AND the octo.exe. The PS script fires the Octo.exe which makes a call to my Octopus Server and with the "create release" option, I'm able to automatically deploy to whatever environment AFTER my build finishes within TFS. Make sure to always include those files (right-click in VS and in file properties select 'always copy').
I'm not quite sure why your NuGet packages would not be configured correctly, but that should be remedied first. Your question is trying to ask for two things and it's not clear which is more important to you; NuGet package or the Deployment from CI build. Having said that, I think you need to give more details on why you think your NuGet package is inadequate or not working correctly for your Azure services.
Please note, the site you supplied is using a custom PowerShell script in the form of a step template. It may be best to try the default Azure step within Octopus first before using a customized script. Just a thought.
Read more about the Octo.exe here: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
I'm using TFS 2013 to build many solutions; each with different solution configurations. I'm also transforming web.config based on the build definition process setting. If the build definition is configured to deploy the web project, web.config is properly being transformed - everything is good there.
However, the web.config that is copied to the build output directory is NOT being transformed. I realize this may be as designed.
So, my question is:
Is it possible for the web.config that is copied to the output directory as part of a TFS continuous integration build definition to be transformed the same as if it were deployed?
I'm not too interested in SlowCheetah as the developer has announced he's stopping work / support on the project. https://github.com/sayedihashimi/slow-cheetah/issues/158
I'm also sure I can come up with a custom post build script to do this as a last resort. But for now, I'm curious if anyone has been successful at getting a transformed web.config copied to the output directory of a TFS build definition.
As far as I understand, you have only two options to apply transforms: SlowCheetah (based on Visual Studio APIs) or publish the site. Unless you use a different "transformation" language, your only choice is to write your own tool.
If you want you can use a different language and tools. As an example, I have been very successful with XML Preprocess.
I would recommend that you drop all of the configs to your build drop and do the transform at deployment time. That way you don't have to rebuild to deploy the same version. If you use Release Management for Visual Studio for deployment you can have two conversions. The base one as dev.config that you use at debug time and the deployed one that matches the configuration that you build that has the RM variables ready to replace depending on the environment.
I’ve been reading some articles (this one in particular: http://speaksql.wordpress.com/2013/06/07/a-journey-to-db-deployment-automaton-ssis-build-using-msbuild/) about using msbuild.exe to build and deploy an SSIS package (.ispac). I had no problem with that from my computer which has all the required assemblies, and only using the msbuild.exe command.
Once I tried to use the TFS Build Server I had some problems. First I realized that using a project with msbuild.exe (SSIS.MSBuild.proj) was not recommended with TFS 2013 since it was used with TFS 2008 and 2010. Anyway, I just wanted to make it work and it sounded plausible, but I had to use the TFSBuild.proj. That was not a problem, but my next problem was that the project I was being using (Microsoft SQL Server Community Samples: Integration Services) references a SQL Server assembly (Microsoft.SqlServer.ManagedDTS) which is not installed on my build server.
Then I realized that even if I managed to install that assembly on the gac, or referenced it on a relative path I would have a bigger problem next, I am using custom activities on my packages which I need to install using gacutil.exe on the host server, and I was wondering how to install, remotely, those dll.
That’s when I started to lose faith, and here I am, is there an “easy” way to implement continuous integration for SSIS packages without installing third party tools (http://remotegacutil.codeplex.com/ for example), and adding missing assemblies to the gac of a build server?
Did any of you have a similar issue? Did you solve it? How?
Thanks!
Use devenv.exe to build the ispac. Add an invoke process task and call out to devenv.
Add an Invoke Process to the Build Template, the one above shows a Sequence container, which assigns the path to the correct version of DeVenv to call, VS2010 /12 /13 etc. this is shown as hard coded but can be put into an argument, so it can be populated in individual build definitions. the one you can't see clearly is "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com"
Next is the invoke Process, this call out to the specified devenv.exe and passes arguments used to build the ISPAC file.
The arguments are passed in localProject would get you the actual project you wanted to build in previous versions, you may have to do something different for 2013, due to the changes to the new templates.
this gives a TFS2012 way of doing it, as i say you may have to do something different to get the project that you want to build under 2013, but the build will run and an .ISPAC file will be generated.
at this point i would deploy the ISPAC using powershell, you may want to add additional scripts to the powershell calls to handle creating the SSIS Catalog and scheduling of the job.
deploying with Powershell can be found here Deploying ISPAC's with Powershell
I am attempting to automate my process for deployments.
Currently, the following steps need run:
Run an external tool in Visual Studio to call Migrator.net (using MSBUILD) to update the database
Right-click the web project and publish locally
Copy the publish folder to all web servers for that specific website
I have now been looking at how to deploy directly from Visual Studio Team Services.
I have created a build definition that will compile my code, and using MSBuild arguments in the "Process" tab of the build definition, will use a publish profile to publish directly to IIS on a target machine. The arguments are something like this:
/p:DeployOnBuild=true;PublishProfile="test_publish.pubxml";UserName=xxx;Password=xxx
This works like a charm for the actual web content, but it does not deal with the database side of things.
The external tool to update the database, as I mentioned, calls MSBUILD with the following:
$(ProjectDir)\Migrations.proj /target:MigrateUAT /p:To=-1 /p:password=xxx
How would I change the build definition to also deal with this MSBuild call? I am at the limit of my MSBuild knowledge.
Thanks in advance.
I have not found out how to do this directly. So I am taking the approach to write a large MSBUILD script that will do everything I want, and only use Team Services to call this script. Rather than use the work flow stuff within the build definition.