Hi,
We're setting up a load balanced environment with one of our clients that has the most active release schedule.
We're using an automatic deployment tool where we can disable one node in the server farm to make a deploy while the other one(s) continue serving traffic.
This sounds quite straight forward until we add another thing into the pot: keeping up with the Episerver updates!
Currently Episerver does not count a change in the database schema as a major change, therefore there could be database changes with each weekly update.
And for each update in the database Episerver increments a version number that is stored within a Stored Procedure. Episerver also checks this version at startup to ensure that the database version is correct.
Are there any good plans how to handle this with the automatic deployments?
Should we take inspiration from the deployments in DXC with the following steps if we don't want a downtime when upgrading?
This list is given that we only have 2 nodes in the farm and that every step is successful so we don't need to rollback.
Of course we also consider having routines where we health check each node before putting it back into the load balanced farm, but we keep the following list simple for the example.
- 1) A copy of the database is taken.
- 2) Node A is taken out of the load balanced farm (because we don't want visitors on Node A while doing step 3)
- 3) Node A receives a new set of connectionStrings that is using the copy of the database and where AppSettings have episerver:DatabaseMode set to ReadOnly according to the Database mode documentation. As this is a change in the configuration for AppSettings, Node A needs to recycle!
- 4) Node A is taken back into the load balanced farm
- 5) Node B is taken out of the load balanced farm to be upgraded
- 6) Node B receive the new deployment package and the original database is upgraded
- 7) Node B is taken back into the load balanced farm
- 8) Node A is taken out of the load balanced farm to be upgraded
- 9) Node A receive the new deployment package (with a configuration that will not have database mode in AppSettings and the connectionStrings use the original, now upgraded, database)
- 10) Node A is taken back into the load balanced farm
I'm not so keen that Node A needs to recycle to be set in Read Only mode!
Even if we would let Node A use the original database and Node B use the copy for upgrading, Node A still needs to recycle as the Read Only mode is set with a change in web.config.
I'm thinking of implementing my own IDatabaseMode that will identify whether Read Only is enabled by reading something else than web.config. Will that do any harm as the website needs to initialize before I can replace the original implementation with my own?