It looks like the time has finally come and all new LCS projects will have self-service Tier 2+ environments. If you want to know a bit more about them, I wrote this post about service fabric/self-service environments in Microsoft Dynamics 365 for Finance and Operations.
The last two projects I’ve started are on self-service and we’ve had a customer migrated to it. So it’s about time I warn you about one scary thing…
Update flow
Regular environments
On the regular/old style environments we all know how to do an update. We create a Deployable Package with our code and apply it to a UAT environment in LCS, mark it as a release candidate and finally apply the package to the production environment. We’re applying a package.
Let’s say you have a sandbox environment and during the weekend you apply a version update package. Once done you can mark it as a release candidate to apply it to prod later. During the week you apply another DP (or more) with your code changes and move them to prod. And the following weekend you apply the first version update DP to prod, and now you have a production environment with the latest version and the code changes that have been applied during the week.
Self-service environments
What if we did what I’ve just said to self-service environments? Well, you’d have tons of fun the day after you applied the version update to prod! Nothing really terrible but you’d spend one or two bad hours.
If you’ve read my other post on self-service environments you already know that with the new deployments we will update a sandbox environment as we do now, and once it’s done we’ll select a sandbox environment to be promoted into production. When we deploy a package to a sandbox environment we give it a name, then we’ll select these names to apply the changes to prod. The sandbox environment state is moved to production! With the code and version it has.
For example:
- Sunday: we apply version update 10.0.9 to the UAT environment. We name this AAS10.0.9Update.
- Tuesday: we apply a package with new or changed code to the PreProd environment. We name it AASCode01. UAT is not updated.
- Tuesday: we apply the AASCode01 state from PreProd to the production environment.
- Sunday: on the next weekend, after testing the new version, we select the AAS10.0.9Update state we deployed on UAT and apply it to production.
On Monday, after updating prod with the 10.0.9 version you’ll have the production environment with the same state as the UAT one in the step number 1.
Why? Because, as I said, we’re promoting the state of an environment, we’re not applying deployable packages to production. When we apply an update to a sandbox environment and give it a name, we’re creating a snapshot of that sandbox environment that will be used as the new production environment when we select it to update it.
What about One Version?
The week of the 17th of February the self-service environments got the option of automatic updates. With this functionality enabled the environments are now in the same update cadence as regular environments and we must remember of the new way of updating the production environment.
So, be careful with this, or you’ll end up with a small headache and a release to prod during working hours, but at least you won’t have to wait 5 hours until it starts because it’s a self-service environment!
