|
|
|
|
|
|
by sixtypoundhound
4854 days ago
|
|
|
I would go one step farther.... Every production deployment should involve blowing away the prior instance, rebuilding from scratch, and restarting the service; you are effectively doing a near-full "restore" for every deployment, which forces you to have everything fully backed up and accessible... Any failure to maintain good business continuity practices will manifest early for a product / employee / team, which allows you to prevent larger failures... |
|
|
In the world where data needs to be maintained, this is not necessarily an option. In the bank where I work, we deploy new code without taking any outage (provide a new set of stored procedures in the database, then deploy a second set of middleware, then a new set of front-end servers, test it, then begin starting new user sessions on the new system; when all old user sessions have completed the old version can be turned off). Taking down the database AT ALL would require user outages. Restoring the database from backup is VERY HARD and would take hours (LOTS of hours).
That being said, we do NOT test our disaster-recovery and restore procedures well enough.