I have a webjob and a webapp (both separate projects), I would like to build one artifact for all environments and do the transformations during the release step rather than build, as that way I have to create an artifact per environment. So I am creating two separate artifacts (one for webapp and one for webjob) per environment and applying the xml transforms during publish to the app service, now everything works fine, except that the transformed file for the webjob is placed in the root directory of the webapp, which is not what I intend to do. I would like the file to be placed as app_data\jobs\continous\myjob\myjob.exe.config
I've seen the slow cheeta and CTT transforms, but those are out of the scope of this question as they do transform only on build.
You can use Kudu api to run the commands to copy or delete files.
More information about how to call kudu api during build/relase, you can refer to: How to access Kudu in Azure using power shell script
You should transform during build and your transformation should happen as tokens in the build rather than actual target values. Then in deployment you can replace the token values with actual target environment values. That is the proper approach for packaging and deployment of any application type.
Steps should be
In build tokenize the configurations with transformation (use this extension task)
Package tokenized configurations as build output
At deployment apply target values to tokens (use replace tokens task comes with marketplace extension, which replaces values of defined configs with release variable values by mapping names automatically. in other words token should be the parameter name)
Here is an example done on a windows service. But it is applicable for webjobs (have tested this) as well and it is the proper solution.
Related
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.
i am using the Replace token extension https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens to replace variable in **/*.config files
Our build pipeline creates one artifact that needs to be deployed to all environments
we have 2 environments in our release pipeline(DEV ,QA)
Each environment has a set of variables configured
I have added the replace token task onto our release pipeline
My config files looks like this
The the tokens are not replaces , i Am new to Azure DevOps , am i missing anything here?
Release activities run on the release agent. You're running token replacement after the application is deployed to the app service, so the token replacement isn't getting deployed.
That's one issue.
Another issue is that web deploy packages are zip archives, so token replacement isn't going to affect the files contained in the zip file. You shouldn't use token replacement in conjunction with web deploy. You should use web deploy transforms (parameters.xml and SetParameters.xml), which are supported by the web deploy task that you're using. parameters.xml allows you to define xpath expressions for locating elements to transform, and the setparameters.xml files contain the values to use in the transformation.
I am setting up Continuous Deployment for a web app and I'm having trouble doing config transformations. The build and release both work without config transforms, but I would like to add a config transform step to ensure the correct connection strings, storage accounts, etc are in the web config.
I am using the config transform task in VSTS. The artifact that is getting built during the build process is a zip file. I am then extracting those files, and it gives an extremely deep file structure. The config transform works if I hardcode the file structure, but I worry that this could change, so I'd like to generalize it. If I do $(mypath)/**/Web.config it does not error and the logs show that it is doing transforms, but once it finishes, I look at the file in Azure and can see that the transforms weren't actually done or saved.
My requirements for this are that I can't use xslt transforms or the XML transforms(web.environment.config) because we would like to keep the important values out of source control and in VSTS. We are also doing config transforms on NLog.config, and those transforms are setup the same way and seeing the same issues. Any help on getting this more general path to work, or a different way of solving this would be greatly appreciated.
Other potentially helpful information:
MSBuild Arguments in Build Solution step:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Path Structure
$(My.Paths.InstallDirectory)\Content\d_C\a\1\s\Apps\ProjectName\ProjectName\obj\Release\Package\PackageTmp\Web.config
There is File Transforms & Variable Substituion Options in Azure App Service Deploy task, so you can use XML variable substitution or JSON variable substitution to do it without extracting the package file (zip file):
For example:
Add a new variable in Release definition (Scope: select an environment), for example: Name: DefaultConnection; Value: Data source=xxx…), clicking lock icon to change variable type to secret.
Check XML variable substitution option in Azure App Service Deploy task
Then during the deploying, any config and parameters.xml files will be updated with that variable value if the key or name entries in appSettings, applicationSettings and connectionStrings sections are matched the variable name
Related article: XML variable substitution
Another way is that you can change the value in web deploy parameters file (SetParameters.xml) through Token replace task (You also can specify the different file in Azure App Service Deploy task per to Environment of release, such as SetParameters.Dev.xml, SetParameters.QA.xml)
An article about Configuring Parameters for web package deployment
BTW: You can remove the source structure from web deploy package by specifying /P:PackageTempRootDir="" msbuild argument
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.
I am working on a CI process with automated deployment. TFS Build is building the solution, and it then uses an InvokeProcess task to kick off a Powershell script. The Powershell script deploys the database changes as a dacpac using sqlpackage, reporting services reports using the web service, fonts to the SSRS server, and the website itself to 1 or more web servers - the whole process uses a deployment configuration file to define drop paths, server ips, installation folders etc. There will be one of these per environment.
I would like to be able to build the solution and deploy to an internal server to run automated tests as part of the automated build. Once tests are completed, and the build has been manually checked, I'd then like to be able to kick off another Build definition which only has the deployment portion of the standard build template, which will simply take a build number or build drop location, and deploy the same build to a different environment (i.e. staging, prod etc.)
The issue I have is that I'm currently managing most of my web/app configuration using config file transformation - i.e. I have build definitions for Debug, Test, Prod etc. and then Web.Debug.config, Web.Test.config etc. I only want to carry out one build, and then deploy that same build to different environments, however at the moment the build will only generate configuration files for one environment - i.e. whatever the build configuration is.
Would the best approach be to generate all config files (or actually pre-createg complete config files for each environment), and then just choose the appropriate one for the specific deployment? Or should I store the env specific config in my deployment configuration file and update the appropriate keys using powershell when deploying?
What would be the normal/recommended approach here?
I'd suggest creating new Configurations for each target environment (e.g. by default you have Debug/Release, create some more). Then use the built-in web.config transforms, for non web-projects use Slow Cheetah
This will spit out pre-configured build outputs for each configuration you specify you want build (in your Build Definition).