I'm deploying a web app to Azure using Visual Studio Team Services to build and then release.
During release I'm replacing tokens within the web.config file with environment variables I have setup within the release definition for each environment, staging, production etc.
I have set the Release Name Format to include the build number and release number using the following:
$(Build.BuildNumber).$(rev:r)
I know Release.ReleaseName is provided as a pre-defined global release variable, but how can I access this Release.ReleaseName variable within my app to display it in a footer?
Usually, you can use Tokenization build / release task to transfer the value of a variable into web.config file.
But since the variable you want to use is filled with the value of another variable, you need to add an additional powershell step to do this.
Following are the steps for you reference:
Create a new variable.
Change the content that you want to replace in web.config to __Eddie__.
Add a powershell step to set the value of "Eddie" to "Release.ReleaseName".
Add a Tokenization step to replace the __Eddie__ in config.
Now, when you start the release, the content in web.config will be replaced by the value of Release.ReleaseName.
Related
I want to develop a pipeline for a .net web app using Azure tfs. I used the IIS Web Deploy template/utility already provided for such deployments. In the release pipeline, I am using XML variable transformation. But one issue I am facing is, that in the project, I have multiple .config files and I have included them in my web.config file as follows
<configuration>
<connectionStrings configSource="None"/>
<appSettings file="None">
</appSettings>
Based on the release for different environments, I perform variable substitution during the release. For example, a folder app_data contains app_sttings_*.config files and file variable does get replaced. But I am having an issue with the connection String file, I can not get configSource to change during release.
Am I doing this wrong or missing a step?
Since the configSource attribute cannot be replaced by the IIS Web App Deploy task. You can use the extension tool Magic Chunks to replace the configSource value.
You can install Magic Chunks extension in your azure devops organization. And add Config transformation task before IIS Web App Deploy task to replace the configSource value.
First you need to define a variable (eg. configSource) to hold configSource value in the Release Pipeline variables section. Then configure the Transformations Section of Config transformation task as below
{
"configuration/connectionStrings/#configSource": "$(configSource)"
}
There is another Replace Tokens task that can replace the configSource value. You can check it out here.
It said in the IIS Web App Deploy task that Variables defined in the Release Pipeline will be matched against the 'key' or 'name' entries in the appSettings, applicationSettings, and connectionStrings sections of the config files. Maybe that is the reason that configSource cannot be replaced by the IIS Web App Deploy task.
See File transforms and variable substitution reference for more information.
I'm using an Azure DevOps Pipeline to release an ASP.NET MVC system to an Azure Web App.
I've configured the build not to apply the XML transforms, so I can apply them later, during the release step, and the same build artefact can be released to multiple environments.
The build works fine, and I end up with an artefact containing an untransformed web.config, and the environment-specific transform files.
The Azure App Service Deploy task has a check-box called XML Transformation, which displays the following help text:
The config transforms will be run for *.Release.config and
*.<EnvironmentName>.config on the *.config file. Config transforms will be run prior to the Variable Substitution. XML transformations
are supported only for Windows platform.
At the moment I'm trying to set up a release into a test environment, but the Web.Release.config is being applied, rather than the Web.Test.config. I've searched everywhere I can find for a place to define the environment to make the release use the test config, but I can't find anywhere.
There's a similar question on GitHub which shows the following screenshot:
Unfortunately mine doesn't look like that:
Am I trying to do the right thing? If so, where do I set the environment?
You need to make sure your stage name is just 'Test' and not 'Deploy EMS to Test', reference here.
Before I was shown Octopus Deploy I thought that environment dependent appSettings should be a part of Build Configuration in project properties.
Now in times of software as a service it is a deployment process that buckles everything up.
I want my environment configuration in release process to just open web.config and substitute appsettings and connection strings based on variable names i defined for the release definition.
How can I do it? The closest I could get was Magic chunks. The problem with it is that I have to give it a json with the mapping and I have to define it for each environment separately, so it makes no use of environment variables, really, or at least you have to define it in "enviroment variables" section and then, again, in each process of environment.
You can use the "Tokenizer" task in "Release Management Utility tasks" extension or "Replace Tokens" task.
These tasks can replace the strings in a file with the custom variables in definition.
I have created an Azure Web Site and connected it to Visual Studio Online, and this automatically set up a continuous deployment build (as per this page).
Initially this worked for a solution with one project, but now I have added a Web API project as a back end. This is named such that it is the first of the two projects alphabetically, and so now it is the only project that gets built and deployed whenever files are checked in. Which leads to my question:
How can I modify the default continuous deployment build to deploy both applications?
I'm sure it must be a fairly simple change to either the build template or parameters, or the publish profiles that are being used by the build. The only problem is I don't know: A) how to change those settings in the default TfvcContinuousDeploymentTemplate.12.xaml build template, and B) how to modify the publish profiles that are used in the continuous deployment build.
I have already, from within Visual Studio, manually published the two projects and got them to deploy to the right locations by following the instructions in this answer. I right-clicked on each project, clicked publish, then selected the "Microsoft Azure Web Apps" publish target which (after filling in all the settings) added the publish profiles to my projects and allowed me to manually deploy them how I wanted.
Unfortunately there seems to be no way to re-upload those publish profiles so that they can be used in the CD build. I've checked them into source control, I just need to know how I can get the CD build to make use of them. How can I do this?
After reading through the first link in my question again, I noticed that you can edit the build definition (or template) to point to the publish profile that you want to use:
Path to Deployment Settings: The path to your .pubxml file for a web app, relative to the root folder of the repo. Ignored for cloud services.
Unfortunately, this both doesn't work and only allows you to specify one publish profile file. Presumably, even if specifying this argument worked, the build would still only deploy the first app in alphabetical order.
This lead me to this question and answer though, which suggests that the Azure/TFVC continuous deployment works simply by using the ordinary Web Deploy arguments to MSBuild. Looking at the diagnostic logs of my build in Visual Studio Online proved this to be the case; here are the relevant arguments:
C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe /p:DeployOnBuild=true /p:CreatePackageOnPublish=true /p:DeployIisAppPath=mysitename
So, as per that question, to use a specific publish profile you can just set the additional necessary MSBuild arguments in the build definition:
Each project needs to have a publish profile called "publishprofilename.pubxml", in this case, checked into source control. I found that the user name (which is your site name with a dollar sign in front of it) is not needed, but unfortunately the password string is required. If you don't include it you get an error like this in the build:
Web deployment task failed. (Connected to the remote computer
("[mysitename].scm.azurewebsites.net") using the Web Management Service,
but could not authorize.
No other arguments were required for me, but it doesn't seem ideal that the password has to be included. The default deployment setup, without using publish profiles, must be authorising with that password somehow, but I don't know how.
So after making this change I navigated to [mysitename].azurewebsites.net, and it appeared that still only the Web API project was being deployed. However, by going to console for the site and entering dir D:\home\site\wwwroot I can see that both projects are actually being deployed. It's just that both projects are being deployed to the root of the site, at D:\home\site\wwwroot. The DeployIisAppPath settings are different in each publish profile, but these values are being ignored. This is because the /p:DeployIisAppPath=mysitename argument to MSBuild (mentioned above) overrides any PropertyGroup settings in publish profile *.pubxml files, as described in this blog post.
What I have found is that the continuous deployment process for Azure/TFVC works by having an InitializeContinuousDeployment build activity in the TfvcContinuousDeploymentTemplate.12.xaml build template, immediately before the RunMSBuild activity. This takes the MSbuild arguments you specify in the build definition, and appends to them the ones needed to deploy to Azure. Unfortunately, this is mostly hard-coded, and that means it always specifies a single deployment path for all web projects in the solution. You can't deploy each web app to a different location using publish profiles alone.
So one workaround option is to add something like a BeforeBuild MSBuild target to each project, to override the command line value of DeployIisAppPath. The problem with this is that the path specified in the publish profile, and seen in the publish wizard, will no longer be the path actually being used for deployment.
So the solution I went with is marginally better; it is what we would describe in New Zealand as "huckery".
Basically I added an InvokeMethod build activity between the InitializeContinuousDeployment and RunMSBuild activities. The arguments for this activity are as follows:
DisplayName:
Configure build for using publish profiles (removes DeployIisAppPath MSBuild parameter)
GenericTypeArguments:
System.String
MethodName:
SetValue
TargetObject:
AdvancedBuildSettings
Parameters:
Direction: Type: Value
In String "MSBuildArguments"
In String String.Join(" ", AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty).Split(New String() {" "}, StringSplitOptions.RemoveEmptyEntries).Where(Function(s) Not s.StartsWith("/p:DeployIisAppPath=")))
What this does is removes the DeployIisAppPath argument from the MSBuild command line arguments list completely, so that it doesn't override this same property in the publish profiles. Instead of the messing around with splitting and joining the string, it would be slightly nicer if you could just append /p:DeployIisAppPath="" to the command line, but this just sets the property to an empty string and you get an error:
"ConcatFullServiceUrlWithSiteName" task was not given a value for the
required parameter "SiteAppName"
So like I said, pretty huckery, but it's a solution that allows you to have continuous deployment of multiple web projects to Azure with a minimal amount of changes to the default setup.
You can override the deployment engine in Kudu by using the Azure CLI Tools. Running the azure site deploymentscript command and passing in the parameters for one of your projects -s <solutionFile> --aspWAP <projectFilePath>.
This will create a .deployment file and a deploy.cmd (or deploy.sh if you pass the -t bash parameter) modifying the deploy.cmd to add build/deploy steps for the second project.
More information is on deployment hooks is available in the project kudu wiki.
EDIT
You can use App Setting COMMAND to add a deployment script to your site.
The solution I'm building contains a whole lot of projects. One of them, Web, is the front end web site, and is being built and deployed to the QA server by default when a QA build is run. I have another project, called Service (and an associated Service.TestHarness), which I'd like to deploy to the same server as part of the same build. Where in the build's settings, or in the BuildProcessTemplate, can I configure this?
I've tried creating a deployment package via Visual Studio and importing this manually in IIS on the QA server, but got the error "This access control list is not in canonical form and therefore cannot be modified" which I haven't been able to resolve either.
Current build settings:
DeploymentApplicationPath = QA server's address
DeploymentComputer = QA server's name
DeploymentPackageSource = Web.zip
PerformDeploy = true
PerformDeploymentBackup = true
There's four ways you can do this:
1) pass everything as parameters to msbuild using the Team Build Process settings This is the least flexible and doesn't work well if you have multiple deployment projects as you currently have
2) create a custom target and a set of conditions in the project files and let msbuild handle the deployment, don't configure anything in the Build Definition itself (other than maybe setting a property on the msbuild command line arguments to enable a specific deployment)
3) use the Solution Configuration to create a specific solution configuration for each deployment you want to do and when specifying the solution/configuration to build in the build definition, enter your own custom configuration
4) let Team Build handle the build and use something like TFS Deployer or Powershell to handle the actual deployment of the packages.