I have a release pipeline to deploy a asp.net core web app. This was created from a simple asp.net web deploy template on azure devops. The web deploy step just points to the .zip file of the artifact drop folder and deploys the app.
I would like to replace tokens in my appSettings.Staging.json file for example:
I am using Token Replace marketplace tool: https://github.com/qetza/vsts-replacetokens-task and setting it up in a pretty standard way as documented:
and setting up my variables in devops:
I would like the "DummyValue" to be replaced with "ActualValue".
Since the artifact is a zip file, I added the "File Extractor" task to unzip the the archive and then had Token Replace task target that folder. According to the logs, it seems like the Token Replace did end up replacing a value, but I can't access those resources directly to make sure.
Since I am now extracting files, I pointed the web deploy task to the new folder where the unarchived files reside, and it successfully deployed, but the resulting appsettings.Staging.json file still doesn't have the token replaced. In the logs of the deploy job I saw this:
2021-03-28T07:36:19.6554561Z Package deployment using ZIP Deploy initiated.
2021-03-28T07:38:08.8457706Z Successfully deployed web package to App Service.
Seems like it's still using ZIP deployment, and I am not sure where it's finding the zip file as there's nothing in the devops logs for that.
Just wondering if anybody else has experienced this and what the best way is to go with this.
It seems that you are using this extension: XDT Transform. After installing it in organization, there are 2 external tasks: XDT tranform task and Replace Tokens task in release pipeline.
There is appSettings.Staging.json file in my repo and it will be published into zip artifact.
In my release pipeline, the path to this artifact is $(System.DefaultWorkingDirectory)/Drop/drop/aspnet-core-dotnet-core.zip.
If I want to replace the DummyValue token in appSettings.Staging.json file of this artifact, creating pipeline variable DummyValue and using the Extract Files task, Replace Tokens task, and Archive Files task, finally the release will archive the replaced folders to replace original zip artifact, so it is done. so it is done. The unnecessary PowerShell task is used to output the replaced file.
Related
How do I remove/deploy deployment without .serverless directory for team collaboration?
For example if I run sls deploy --aws-profile profile1 with a .yml file it then creates this .serverless directory which I am not including in my git push to hide secrets. Now when someone else clones this repo on my team how can they now manage the same deployment? Is the .yml file and same aws profile sufficient?
The .serverless folder is created by serverless to alocate the cloud formation files. You should not handle them manually (and the folder and it’s content should not be included in source control).
The serverless.yml is the source of truth for the deployment, so it should do the same if running with the same environments.
The AWS account/profile can be set using the AWS cli. Given all the devs use the same account or use accounts with the same level of permissions, each one of you should be able to run deploy/remove.
If you project uses a .env file or environmental variables, each member of the team has to include them in their environment.
The project I am working on is a API App service. It builds and deploys fine, but it will not run correctly due to the appSettings.config file not being transferred over. It appears to not be included in the .zip file that is dropped in the artifacts. I have tried setting it to copy always, messing with the csproj file, etc, but no luck. Config files such as the Web.config and unity.config are carried over, but the appSettings.config is not. I can copy it over later, but that defeats the purpose as I want to use the XML substitution. Any ideas what I am missing?
Azure Devops Build/Release - all configs included except appSettings.config
To keep appsettings.json to be left beside the published app, you could try to set the property <ExcludeFromSingleFile>true</ExcludeFromSingleFile> for this appsettings.json file in the project file .csproj.
Check this thread for some more details.
Hope this helps.
I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.
I am in the process of creating an application to allow the automation of application deployments, (https://github.com/twistedtwig/AutomdatedDeployments#readme).
The idea being that everything is in source control, application files, application configuration as well as IIS configuration. My application allows the solution to auto deploy, (adding a post build setp to the sln / proj file), after a build to the dev machine. It will allow the CI server to auto deploy to its machine for testing as well as the CI Server pushing successful builds to QA / Test / production servers. One of the issues I have with msdeploy is the requirement of IIS to be setup with the website / application before hand, (which my app is trying to get around).
So far I can create, update and remove, app pools, websites and applications via config files automatically. I can sync files and folders fine. The last step was to use the /target:package switch in msbuild to create clean file structures for web deployments. For example I would run a command like:
msbuild.exe myMvcSite.csproj /target:clean /target:package /p:Configuration=Release /p:_PackageTempDir=C:\websites\mySite /p:PackageLocation=C:\dropLocation\mySite.zip
This creates a nice zip file with the internal file path of "C_C\wbesites\mySite" ready (as I understand it) to be sync'd to the production server.
My issue is how I deploy this zip file. I want it to be independent of any IIS information, i.e. I am simply pushing the files / folders to a location, (either on the local machine for developers, or remote for testing etc). The setup of IIS with app pools and sites etc would be taken care of separately. Some of the commands (and their output) I have tried are below:
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\Temp\deploy\installer\test\testPackage.zip" -dest:auto
Info: Adding sitemanifest (sitemanifest).
Error: The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.
Error count: 1.
and
"C:\Program Files\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="C:\website\installer\testPackage.zip" -dest:contentpath=C:\temp\mytest
Error: Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Error count: 1.
The first command I am trying to let it unpack the files with the structure it has. It seems to be upset about app pool stuff though, (which I don't want it to touch).
The second I am trying to get around the "auto" bit but this isn't happy either.
I am struggling to find much information about this process.
The only way I can see how I might achieve this at the moment is to not use msdeploy for it, but to create my own task to integrate the file structure and do the file syncing my self, (not ideal).
I ended up coding around this issue, rather than being able to solve it.
I take the zip package:
unzip in a temp location
find the final path it will be going to (normally from archive.xml)
check to see if I am merging the folders or doing a clean install, (i.e. do I delete the destination folder first).
copy / push files to end location, (normally with msdeploy).
I open sourced my solution to this: https://github.com/twistedtwig/AutomatedDeployments
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.