In the last article here I proposed the design for the custom Maintenance functionality:
After the serious testing we discovered that the solution works, to some extent.
For the naughty user ignoring our warnings to leave the portal during maintenance, it is possible to stay on the cached web page, go for a coffee while we are rebooting the portal, come back and continue working (submitting forms, editing) as nothing have ever happened.
Yes, if he refreshes the page or navigates from the page it will redirect him/her/them to the Maintenance page and stop from working. But not if he stays.
So what do we do?
We design the maintenance functionality for two phases: a deployment and a smoke testing.
In general this functionality shouldn’t be required at all. Most if not all of our deployments are seamless and don’t disturb our users. But what if. What if it’s required to go in the deep maintenance mode for couple of hours?
Let’s have a look at the extended process together!
- For the deployment phase, where we don’t need to test or anything It usually takes up to 1 hr. We enable the Maintenance mode.
For the naughty user the whole portal is gone the moment he submits a form. No more playing around!
- Before enabling it back we switch on a “light maintenance” custom mode which allows us to test and do all checks but stops naughty users from accessing the portal. Because we kicked them out now they have to wait till we finish the deployment, test then let them in.
- After completing the testing, we switch off the OOB Maintenance mode.
- Then we disable a custom Maintenance mode.
This will work for sure! 😀