These are notes on how to have two builds (debug and release) but multiple target environments (e.g. dev, test and prod) with different web.config settings applied during the release steps (which is done by web.config transforms).
The high level process is:
- Setup a debug and release build. The debug build of the code goes to dev server, the release build goes to test and prod servers.
- During the release to each environment the config transforms are applied to ensure the config is relevant to the environment it is going to (e.g. connects to right database/webservices, has right app settings)
- The code going to both test and prod is identical (with an altered config).
- You don't have to do a build for each environment. You can just do a debug and release build which is quicker if you have a lot of environments
- You don't have to change the project file to add in a transform step. That step will actually apply to local builds which is a pain (you can create a 'localdebug' config and use that local but who can be bothered). Although I guess you could do an XDT Transform step during your build without changing the proj file (haven't tried this, but should work).
Do the build
Setup the BuildConfiguration to do a debug and release build by updating BuildConfiguration variable and turning on multi-configuration.
Configure artifact names so the different builds can be distinguished:
This means two builds happen:
Wow.
Do the release
The artifact can be copied to the final website location (e.g. the IIS directory) and the config transform applied there, but there will be a short time where the code will be deployed and the transform not applied - for that time users accessing will get the site with non-transformed (e.g. development) config. So process is:
- stick the artifact files in a temp/working directory
- do the transform for the environment
- move the files to the final website directory
Create release definition(s)
Copy the files from the artifact to a working directory (create the directory manually (or add a step to do it) first or this copy step will fail)
Apply the config transform to the files in the working directory (this comes from the marketplace https://marketplace.visualstudio.com/items?itemName=qetza.xdttransform#overview)
How does this work when it doesn't have any credentials associated with the step? Dunno. Maybe because the previous copy files step does pass credentials, so the process is already considered authorised on the remove machine.
Copy the files from the working directory to the website directory
Optional: delete the config transforms and clean the working directory:
You have to get the remote delete step from the marketplace. There is a bug with it where if your path has a space you need to wrap it in single quotes.
No comments:
Post a Comment