How to include my config transformation files in the web deploy zip? - azure-devops

Im setting up a new build and deploy pipeline in Azure Devops. It is an older Web application with some transformation files for the web.config. In the old days we would build the same code x times depending on how many environments. This this is no longer necesary as I read from here https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/transforms-variable-substitution?view=vsts#xmltransform
it looks like the deploy pipeline can pick up the changes from my transform file.
But the problem is that my other transform files does not get included in the package so I get these warning message:
[warning]Unable to apply transformation for the given package. Verify the following.
[warning]1. Whether the Transformation is already applied for the MSBuild generated package during build. If yes, remove the <DependentUpon> tag for each config in the csproj file and rebuild.
[warning]2. Ensure that the config file and transformation files are present in the same folder inside the package.
And yes when i download the artifact the Web.[stage].config files are not there as suggested.
Is there some setting somewhere that let me include these files? Or stop them from being transformed?

For Web applications
MSBuild knows how to transform the web.config files based on the following settings/properties/parameters (in order)
Build Configuration dotnet publish --configuration Release
Publish profile dotnet publish --configuration Release /p:PublishProfile=FolderProfile
Environment dotnet publish --configuration Release /p:EnvironmentName=Production
Custom file transform dotnet publish --configuration Release /p:CustomTransformFileName=custom.transform
I think it's typical for developers to make this happen based on build configuration only, and I believe MSBuild (and dotnet) know how to do this based on the <DependentUpon>Web.config</DependentUpon> element in the Web.[configuration].config item in the project or build script file.
Azure DevOps Release Pipelines is a little different.
The pipeline wants to transform your web.config after the project has been built/published and doesn't know how to do that if MSBuild (or dotnet) has already made an attempt at it. Thus:
[warning]Unable to apply transformation for the given package. Verify the following.
[warning]1. Whether the Transformation is already applied for the MSBuild generated package during build. If yes, remove the tag for each config in the csproj file and rebuild.
[warning]2. Ensure that the config file and transformation files are present in the same folder inside the package.
The warning text states:
Remove the <DependentUpon> tag for each config in the csproj
Thus: you need to remove the tag from the csproj to prevent MSBuild from transforming the files
Or: you need to use the /p:TransformWebConfigEnabled=False argument to MSBuild. (note: I believe it is correct that this can be used w/o removing the dependent upon tag, but I could be wrong)
Make sure the transform source and target files are in the same folder inside the package.
There may be several ways to do this. I've chosen to mark the transform source config files as content to force MSBuild to include them in the published package.
Now you need to organize your release pipeline in accordance with the File Transforms and Value Substitutions documentation.
[section]Starting: IIS Web App Deploy
====================================
Task : IIS Web App Deploy
Description : Deploy a website or web application using Web Deploy
Version : 0.0.51
Author : Microsoft Corporation
Help : More information
====================================
...[command]C:...\ctt\ctt.exe s:C:...\Web.config t:C:...\Web.Release.config d:C:...\Web.config pw i
[command]C:...\ctt\ctt.exe s:C:...\Web.config t:C:...\Web.Development.config d:C:...\Web.config pw i
XML Transformations applied successfully
...
For Non-Web Applications Needing .config Transformation
Getting your .config files to the release pipeline can happen several ways. Here are two.
Your release should have "access" to the repository as a part of the artifact, which will ensure that the deploy agent downloads the source (not desirable IMHO).
You will need to include the web.[stage].config files as part of your build artifact with a copy task, or a minimatch that picks them up.
Once you have the .config files available to the release pipeline
You can use the File Transform Task or XDT Transform Task to perform the transformation operations.
Option 2 is the route I've gone.
Here is an image of what that task looks like for me.
That task puts the config in the artifact from the build that I can then use in the release pipeline without rebuilding xx times.
Cleanup
If you're in a position where you care to not have the transform files persisting on the agent after the release is complete, then you'll need to add that to your pipeline.

Related

Azure pipeline yml: publish or file copy?

At the end of my pipeline I want to copy the bin directly to a network share from which it can be used to deploy.
I see there are two possible task typed that could do this:
copy files that makes a task: CopyPublishBuildArtifacts#1; or
_ copy and publish build artefacts_ that makes a CopyPublishBuildArtifacts#1.
And this publish is different to dotnet publish?
Which one should I pick and why?
They appear to have identical parameters.
What is the # for?
Azure pipeline yml: publish or file copy?
The task CopyPublishBuildArtifacts is deprecated. If you're using Team Foundation Server 2017 or newer, we recommend that you use Pipeline Artifacts.
And if you want to know the different between publishbuildartifacts vs publishpipelineartifact, you could check below thread for the details:
What is the difference between Build Artifact and Pipeline Artifact tasks?
And this publish is different to dotnet publish?
The answer is yes. The dotnet publish task is to serve the specific project. Its function is similar to that we choose the Publish option for net core project in Visual Studio.
But we could specify the folder or files to publish for the publishbuildartifacts or publishpipelineartifact task.
Which one should I pick and why?
We recommend to use the publishpipelineartifact task if you just want to copy the bin directly to a network share.
You could check the reason from here:
For build artifacts, it's common to copy files to $(Build.ArtifactStagingDirectory) and then use the Publish Build Artifacts task to publish this folder. With the Publish Pipeline Artifact task, you can just publish directly from the path containing the files.
By default, the Download Pipeline Artifact task downloads files to $(Pipeline.Workspace). This is the default and recommended path for all types of artifacts.
File matching patterns for the Download Build Artifacts task are expected to start with (or match) the artifact name, regardless if a specific artifact was specified or not. In the Download Pipeline Artifact task, patterns should not include the artifact name when an artifact name has already been specified. For more information, see single artifact selection.
What is the # for?
The role of # is to specify the version of the task. For example, #1 is to use the version 1.0 of the task.

What does "Package or folder" refer to in the File transform task in a release pipeline?

I'm completely new to Azure DevOps Pipelines so if I'm doing something incorrectly I'd appreciate a nod in the right direction... I setup a build pipeline and that seems to be working, now I'm trying to setup a release pipeline in order to run tests, it's mostly based on Microsoft's documentation:
https://learn.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=azure-devops
Before running tests I need to transform a config file to replace some variables like access keys, usernames, etc. What I setup is what I have below but for the life of me I can't figure out what text box Package or folder refers to. The documentation is super helpful as you can imagine:
File path to the package or a folder
but what package or what folder is this referring to??? I've tried several different things but everything errors with
##[error]Error: Nopackagefoundwithspecifiedpattern D:\a\r1\a\**\*.zip
or pretty much whatever I specify for a value.
The File Transform task supports the .zip files.
Test with the default File Transform task settings, I could reproduce this issue.
In Release pipeline, the file path could has one more node for the build artifacts .zip file.
The format example:
$(System.DefaultWorkingDirectory)\{Source alias name}\{Artifacts name}\*.zip
So you could try to set the $(System.DefaultWorkingDirectory)/**/**/*.zip in Package Or folder field
For example:
On the other hand, you can check the specific path in the Release log -> Download Artifacts Step.
$(System.DefaultWorkingDirectory): D:\a\r1\a
You could aslo use this specific path in the task.
Update:
If your file is Project Folder, you refer to the following sample:
File structure:
Task Settings:
Note:You only need to assign to the folder node.
You could also select the folder path via ... option.

Azure release add artifact

Within Azure Devops I have a build pipeline which builds and publishes artifacts and a release pipeline which downloads those artifacts, defines some infrastructure configuration, and batch uploads the artifacts to a web container.
After the configuration definition I want to add a task to fetch the clientId of an AD registered app, dumps it into a json file and copies the file in the same folder as the build artifacts. The json has to be uploaded to the web container to provide runtime configuration for a spa app.
What I have tried:
generate a json in a release task and copy it into said folder
commit an empty json in the code, have it published as build artifact and update its content in a release task
use the file transform task which only seem to allow updating a key / value, not generating a new one
The contents of the folder which gets uploaded seem to be locked.
Is that correct ? What can I do to achieve my goal ?
Releases don't publish artifacts. Releases consume published artifacts. A release can be run multiple times for the same build. A release can have multiple environments. What you want to do would fall apart immediately in any of those scenarios.
What you should do is write a custom BASH or Powershell script (depending on your preferences and OS) that does exactly what you describe:
Generate an appropriate JSON file
Upload the JSON file to the "web container"
You haven't provided any details about what a "web container" is or what your deployment environment is (i.e. AWS, Azure, containers running in Kubernetes), so that's the most thorough answer that can be provided.

Azure build pipeline - published zip file

I am fairly new to Azure Build pipelines, but I am having issues finding the answer to this.
When I build my artifact, the results include my server code files (vb and cs). How do I construct a build pipeline where the artifacts that are dropped are only the files I need to publish a site? Meaning, I want to exclude vb and cs files, but include necessary dll's and html/java script files.
You're publishing the wrong thing as an artifact. You're probably specifying $(Build.SourcesDirectory) or $(System.DefaultWorkingDirectory) as the root folder for your artifacts.
Look at your build step. Are you specifying an output directory as an MSBuild argument? If not, specify one. Specifically, $(Build.ArtifactStagingDirectory). So you'd pass the MSBuild argument /p:OutDir=$(build.artifactstagingdirectory)
Then publish $(Build.ArtifactStagingDirectory) instead of whatever folder you're currently publishing.

Unique Need - Perform Team Services releases using artifacts created in an external build

I have a unique need where I need to perform releases from Team Services using a Release Pipeline and artifacts that have been created in a previous external build. I have the artifacts that were created, dacpacs and websites ect.
I would like to deploy these items using the features in release Pipelines but artifact sources only come from a build or some other version control.
My approach (hack) was to use a build to copy the external files and publish them into the artifact container for the build. I could then use the release pipelines to do my releases. But .. Build copy tasks only seem to work with paths into a repo.
My fall back will be to use the release pipeline and powershell to do the releases with these externally created artifacts. I would sure like to avoid this since there is nice capability in the release pipeline tasks.
This is a compliance requirement my firm has which results in the rather crazy post.
Any help would really be appreciated.
You can use Copy Files task and Publish Build Artifacts task for your build definition.
Copy Files task
Source Folder: you can specify the folder which has your external build artifacts. Such as C:\project\a.
Contents: you can use wildcards to specify which files to copy. Such as **\*.dll, this will copy all *.dll files in C:\project\a and it’s subfilder.
Target Folder: where you want to copy these files. Usually it’s $(build.artifactstagingdirectory).
Publish Build Artifacts task
Path to Publish: set as the same with Target folder in Copy files task. Such as $(build.artifactstagingdirectory).
Note: Copy files task will find the source folder in the machine where the private agent is located.