I've got a question regarding how teams who are working on multiple code branches (development, feature 1, bug 3 etc) test these changes.
We currently work against one development branch which then gets deployed to the integration environment and moved to pre-production for uat / qa and then onto production when it's good to go live.
We are now about to start work on a number of projects where the concept of all developers working against one branch & publishing to integration to test isn’t really going to work.
One project we'll soon be starting is going to last for a number of months and during the build we'll need to test the site as well as showing it to various stakeholders throughout our organisation and potentially external resources. This won't work in our traditional "test in integration" world as I don't want to be in a position where potentially we have to keep on switching branches and re-deploying.
How do people go about setting up environments for testers, stakeholders or anyone to look at that isn't the integration or pre-production environment? Is it a case of setting up test servers internally or azure resources (app services, sql db etc) that you then deploy the branch in question onto?How do you then deal with small / quick branches that you want to test?
Am interested to hear how other teams manage their testing & deployment strategy when working in this way.
You should reach out to your EPiServer account manager regarding to this requirement. There are different options for catering this requirement.e.g additional application environment
I hope this could help.
I usually set up additional dev/test environments in Azure. It can be done fairly quick using Powershell or Azure CLI. The hosting cost can be made ridiculously low, by scaling down when the environment is not used.
The license is another issue, though. It comes down to how you, and Episerver, interpret the use of demo and developer license :-)
(recommend to use the newer Az modules instead of AzureRm, or Azure CLI)