How can I configure which Web.config to use in deployment to Azure Cloud Services?
I have two files (Web.config and Web.Staging.config) how can I configure to transform Web.config using Web.Staging.config?
I will change the question: in AppVeyor build and deploy process there is a command linke that:
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" "C:\projects\xxxxxxxxx\xxxxxxxx.AzureCloudService\xxxxxxxxxxx.AzureCloudService.ccproj" /p:Configuration="**Release**" /p:Platform="AnyCPU" /verbosity:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" /t:Publish /p:PublishDir=C:\Users\appveyor\AppData\Local\Temp\1\th712xjsl2\
In that command, there is a parameter called Configuration that has a fixed "Release".
How can I change this parameter to another configuration?
Is there a way in AppVeyor settings or in Visual Studio?
Web.config transformation is run at the time Azure cloud service package creation and is controlled by solution configuration.
However, you cannot choose between different web.configs during the deployment as cloud service package already contains transformed web.config.
This blog post describes a nice approach of how you can change Azure cloud service configs at the time of deployment: https://blogs.endjin.com/2015/03/using-a-different-new-relic-application-name-per-environment-with-azure-cloud-services/
Related
I am working on a website that will be deployed to various environments - Dev, UAT and Production - and each of them has different config settings defined through the use of config files.
The deployment process consists of two steps:
Publish the latest build output
Copy and replace the default config files with the one specific to the environment were the deployment is being done (these files are currently under source control)
I am trying to automate the deployment process using VSTS and Azure App Services but I couldn't find any task or option that would let me copy files into an App Service.
What is it the best way to implement this deployment process?
You can make this much easier on yourself by using config transforms for your web.config file.
Basically, make sure that you've defined a Build Configuration for each environment. Debug and Release are defined out of the box for Visual Studio MVC projects. You can add as many configurations as you want, such as a UAT configuration.
Once you have your configurations defined, make sure there's web.[your build config].config file located beneath your web.config in the Visual Studio solution explorer. Within each of these build configuration specific transform files, you can override settings as needed.
To close the loop, you can specify a build configuration to target when creating a build in VSTS. This will automatically execute the transform for the build configuration you've selected.
More details on build configs and web.config transforms here.
Alternatively, you could specify your app settings and connection strings directly in the Application Settings of your Azure Web App. These override anything in your deployed web.config file. What I like about this approach is that you don't have to expose sensitive information like connection strings to other developers on your team, and it removes the minor complexity of web.config transforms.
Kudu api give you the ability to upload and download files from azure web app with overwrite
The git:
https://github.com/projectkudu/kudu/wiki/REST-API
Not sure if vsts have this ability.
I recently did what you describe with Jenkins . Now I'm trying to integrate Jenkins to vsts
Hope it give you an answer
We are using Team Services to maintain our web projects and Azure for hosting. At now, there are several Web Roles (asp mvc) and Worker Roles which is being hosted as Cloud Services. We are going to setup Continuous Integration and Delivery for them.
As you know, Team Services Build Definitions suggest to use Azure Cloud Service Template for building and Azure Cloud Service Deployment Task to deploy. We’ve tried it for single cloud service and it works.
In our case, there are web project (web role) and scheduler (worker role) as separate Cloud Services and they should be deployed simultaneously (in sequence), let it be DEV environment. But we have much more environments: dev, qa, ta, demo, preview, production, etc. Furthermore, each of them has slightly different web.config, ServiceDefinition.csdef and ServiceConfiguration.cscfg. And it became much more complicated task than just deploy one Cloud Service.
Questions are:
Should we build dozens of Cloud Service pachages (artifacts) and later decide which of them deploy or not? Could you suggest how to do it in a proper way? (in most cases it will be only Dev environment and we will waste time and resources for building other artifacts).
Will it be better to build one common artifact and later replace all configurations for specific environment? (It’s more complicated task because Cloud Service package zipped on several occasions with preconfigured ServiceDefinition and ServiceConfiguration)
What is the best way to replace configuration tokens (web.config, serviceconfiguration, etc) in Deployment mode, or it should be done while projects is being built?
I would be grateful if you suggest any best practices.
For azure cloud project, it’s better to apply changes to the project per to the environment before build, so you can build the project during the release process.
Regarding to deploy to corresponding environment, you can configure artifact filter with build tag.
For example:
Add a file (e.g. json, xml or txt) to project that used to determine which environments the release should deploy
Add a PowerShell task to build definition to read the data from that file (step1) and add build tag(s) through logging command (Write-Host "##vso[build.addbuildtag]build tag")
Add Publish Build Artifacts task to upload the source files
Create a release definition and link artifacts and add multiple environments
Configure Pre-deployment conditions for each environment: Enable Artifact filters=>Select artifact=>Specify build tags
Add tasks and variables (e.g. visual studio build) for each environment to deploy to corresponding environments.
On the other hand, regarding replace value, there are many ways, such as Replace Tokens, XDT Transform
I am new to DevOps. Recently I practiced the Docker examples. I have one usecase in my current project. Here it is
This is java project. It contains one war project that depends on jar project. Build tool is maven.
We are using Jboss Wildfly server.
DataBase is mysql 5.7.
We are using testng framework for the unit test cases.
sonarqube for code analysis. Selenium for testing.
So in any linux box the infrastructure we need is java8, wildfly server and mysql 5.7.
Consider we have 2 boxes. one is dev and another is test. Developer works on his local windows machine.
Sometimes we need some configurations required in jboss folder. Suppose we changed one xml in wildfly configuration folder in this release. How to communicate same to dev and test boxes as local machine. Another case is for dev box we need different configuration in xml and for test box it is different from dev box(SSL information in standalone.xml and user properties). How to handle this?
I would suggest to run all required stack (wildfly and mysql) via docker-compose. Also you can extend official wildfly image to provide your custom configuration so you should build 2 different images, one with tag 'dev' and second with tag 'test'.
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 am trying to figure out how to use msdeploy with my MVC site to be able to automate the deployments including setting up IIS on the remote server.
I use the following command to create the package:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Clients\PokerLeagueWebSite\PokerLeagueWebSite.csproj /T:Package /p:Configuration=Deployment
My setup is as follows:
local dev box using VS2010 + GIT
GITHUB for repo
Teamcity for CI server (different machine to dev box)
remote (same network) UAT server
If I tick the "Include IIS Settings as configured in IIS" and "Include application pool settings used by this web project" and build the package on my dev box then publish from there it works great. Here is the command I use:
C:\myproject\Packages\Deployment\PokerLeagueWebSite>PokerLeagueWebSite.deploy.cmd /Y /M:192.168.10.98:8172 /U:administrator /P:password
This creates the virtual directory within my UAT server and all is well. The problem is when I commit to github and the CI server downloads and builds it. Naturally the virtual directory is not setup on the CI server so the build / package fails.
What I want to do is use the packaging that msdeploy gives and be able to deploy the site and IIS remotely. I guess there are a few options:
1) Alter the MVC project file to hard code iis settings so that when ever / where ever you run the build package it creates the XML files with the correct settings so it can be deployed from any machine. I think this might be able to be done with the package.xml file in the root of the project, but I have no idea how I setup all the app pool and virtual directory settings. Feel like I am half way there but can't get the final push across the line.
2) Use powershell to alter created package XML files so that the extract IIS settings are added.
The first option is preferable as it keeps all the information in one place and you don't need to remember to run an extra script before deployments.
I believe I could figure the second option out by using VS to create the package and get the settings I need then script it, but I don't have a clue and spent a fair while reading about it without any success on how I would do option one.
N.B.
Reading some of the suggested questions before I posted this I can see some sort of possibilities:
MSdeploy deploys an MVC 2 application with wrong virtual directory name
This question talks about passing extra values on the msdeploy command, seems OK but not internal to the build process so to speak. Not sure of all the commands to use but can google that I am sure.
This links seems to continue with the above: http://msdn.microsoft.com/en-us/library/ee814764.aspx
This page takes about the possibilities for option 2. http://learn.iis.net/page.aspx/1082/web-deploy-parameterization/
Think this is the way: using parameters.xml in teh root of the site for project stuff:
http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
EDIT
I have continued reading and testing around this. Using the parameters.xml file in the root of the project I can get the parameters pretty much there I think. My issue seems to be the archive.xml file. This is pretty different and is what is causing the package to not install correctly if I do not have the use IIS settings check box ticked. I have started to read about [project].wpp.targets file that might help but pretty darn lost with that atm.
EDIT 2
So what I think I need to do is get the [project].sourcemanifest.xml file to change a few of its settings. I believe this is what drives the archive.xml which is what is different now. I have the parameters.xml working correctly I think.
When NOT using IIS the sourcemanifest.xml looks like this:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" managedRuntimeVersion="v4.0" />
<setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\hoh_code\GIT\ai-poker- project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>
But when I tick the use IIS settings it looks like this:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<appHostConfig path="Default Web Site/PokerLeague" />
<contentPath path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" />
<setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>
Not sure how to change it, working on the [project].wpp.targets file, but fumbling in the dark atm.
EDIT 3
OK so I thought I had it for a minute. in my [project].wpp.targets file I have:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<AddContentPathToSourceManifestDependsOn>
SetCustomACLs;
</AddContentPathToSourceManifestDependsOn >
</PropertyGroup>
<Target Name="SetCustomACLs">
<ItemGroup>
<MsDeploySourceManifest Include="appHostConfig">
<Path>Default Web Site/PokerLeague</Path>
</MsDeploySourceManifest>
</ItemGroup>
<ItemGroup>
<MsDeploySourceManifest Include="contentPath">
<Path>$(_MSDeployDirPath_FullPath)</Path>
</MsDeploySourceManifest>
</ItemGroup>
</Target>
</Project>
Which builds, creates a deployment package that I can then deploy from my dev box to the UAT server and it works. But when I run it on my CI server it will not build the deployment package, it drops out at the manifest stage with the error:
One or more entries in the manifest 'sitemanifest' are not valid.
The manifest file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<appHostConfig path="Default Web Site/PokerLeague" />
<contentPath path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" />
<IisApp path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" managedRuntimeVersion="v4.0" />
<setAcl path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>
I am guessing it is because it still has the IisApp as well as the appHostConfig that I added. I am just guessing about this, and don't know how to remove that yet.
EDIT 4
OK so I found the setting to remove the IISAPP from the manifest and parameters:
<DeployAsIisApp>False</DeployAsIisApp>
This goes into the wpp.targets file.
This has now created a new issue that it will no longer deploy. I believe this is something to do with apphostconfig dealing with sites and iisapp dealing with virtual directories.
EDIT 5
so I have been going through the differences left between ticking with IIS and my custom one.
sourcemanifest.xml files are the same
systeminfo.xml are the same
setparameters.xml:
The IIS web applicaiton name section is different. With IIS version is has the "Default Web Site/pokerleague" value but mine has "C:\websites\pokerleague".
I think this is what is driving the error in the parameters.xml:
the IIS web application has those same values and the tags attribute has physical rather than iisapp.
I have similar tools, and do automated build and deployment:
git repo
vs 2010 , asp.net mvc 3
teamcity 7.1
msbuild
msdeploy
I separate the build, packaging, and deployment steps. I don't use the msdeploy xml files, but do the same thing on the command line.
These are my steps:
Step 1: edit the Visual Studio project properties
right-click "MyAppName" project -> Properties... , tab "Package/Publish Web" ...
Configuration: Active (Debug) - this means the 'Debug' config is active in VS, and you are editing it. The 'Debug' and 'Release' configurations both can be selected and independently edited.
Web Deployment Package Settings - check "Create deployment package as zip file". We want the ZIP file so it can be deployed separately later.
IIS Web Site/application name - This must match the IIS Web site entry on the target server. I use "MyAppName/" with no app name after the path, because i create that in IIS manually. That is how it looks on the web server config.
I create the IIS web site manually the first time (maybe you can automate, i don't). When using MSDeploy, it will push your app to the matching Web Site name - you don't have to hardcode any destination folder paths or anything.
Save it with your project, and make sure your changes are checked into Git (pushed to origin/master). Those settings will be pulled from version control when the CI server runs the build steps.
Step 2: add a Build Step in the TeamCity config
I edit the Build Steps, and add a second build step, to build the MyAppName.sln directly, using msbuild. You can modify as you like, as you probably already do this some way.
Step 3: fix build error by installing Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package
Basically, either we need to install VS on the build server, manually copy files, or install the Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package.
Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
This will get it to build. Still no deployment to a server yet.
Step 5: Install the MS Web Deployment tool
I get the Web Deployment Tool here and install. After reboot, the TeamCity login has a 404 error. Turns out Web Deploy has a service which listens on port 80, but so does TeamCity Tomcat server. For short term, i stop the Web Deploy web service in control panel, and start the TeamCity web service. The purpose of the Web Deployment Agent Service is to accept requests to that server from other servers. We don't need that, because the TeamCity server will act as a client, and deploy out to other web servers.
The Web Deployment Tool also has to be installed on the target web server. I'm not going to go too far into detail here, but you have to configure the service to listen as well, so when you run the deployment command, it accepts it and installs on the server. For the server, i set up a new account named 'webdeploy' with permission to install.
Step 6: Create a MSBuild command to package the Web project
I do separate steps for packaging and deployment. This will allow cases for building a Release package but manually deploying it, if you want.
This is the msbuild package command:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyAppName/MyAppName/MyAppName.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyAppName.Debug.zip"
Let me explain the command parts:
MyAppName.csproj : path to VS project file to build. There are important options in there which get set from the project Properties tabs.
/T:Package : create a ZIP package
/P:Configuration=Debug;PackageLocation=*** : run the Debug configuration. This is the same as Build in Visual Studio with the 'Debug' setting selected. The 'Package Location' is what it created. We will reference the package file later in the deployment command.
Step 7: Create a Web Deploy command to deploy the project ##
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
After deployment, i checked the IIS web server files, to make sure they had the latest DLLs and web.config file.
Step 8: Call the MSDEPLOY from the TeamCity build steps
Since there are now have 2 good commands (MSBUILD.exe to package, MSDEPLOY.exe to deploy), add them to the build steps. I use the command line runner, and just put in the same command as the prior 2 steps.
run it all
When you run the build with these steps, if they succeed, you have automatic deployment directly from git.
Now every time new code gets merged and pushed to git origin/master branch, it will automatically build and deploy the the development server.
As you can see, this avoids your original problem:
The problem is when I commit to github and the CI server downloads and
builds it. Naturally the virtual directory is not setup on the CI
server so the build / package fails.
The CI server only builds and packages. Then it deploys to the target web server.
Take a look at Appveyor. We've just released v2.0 and IMHO it is a really strong alternative to WebDeploy. The entire deployment process could be scripted through PowerShell on CI server and there are PS hooks to customize the process.
Disclaimer: I'm Appveyor developer. I'm not trying to advertise here, but it would be great to see if that works for you.