3 ms·

My take on that is that you’re creating work in one place to avoid it in another. And it sounds like it works for you, but I don’t think I’d choose that route,

My take on that is that you’re creating work in one place to avoid it in another. And it sounds like it works for you, but I don’t think I’d choose that route, and I definitely wouldn’t say you can avoid needing maintenance pages just because you don’t have planned downtime to do migrations.

robertlagrant 5y ago
> I definitely wouldn’t say you can avoid needing maintenance pages just because you don’t have planned downtime to do migrations For sure. I'm just making the point that to do continuous delivery you wouldn't necessarily need maintenance mode pages, which predate continuous delivery.
- stephenr 5y ago
  No there are definitely alternatives, but IME having a maintenance page is a good idea/necessity anyway, and the engineering involved to activate it during deployments is essentially set and forget, whereas the engineering to make your application backwards compatible with any possible schema change is entirely an ongoing issue, and a lot more complex. If your development team is sufficiently experienced to do allow for the no-downtime approach that’s a big win, but my experience so far makes me pessimistic about how widespread that kind of experience is. Edit: I should clarify somewhat: I’ve had to introduce at least one of the following concepts at basically every client: continuous/automatic deployments; automatic migrations; automatic maintenance pages during outages (planned or otherwise); and hard as it is to believe: version control. My clients are typically smallish, so anything I can do to solve problems/provide solutions at the infra layer is a no-brainer because setting up an automated {enable maintenance mode; apply migrations; disable maintenance mode} is a lot more reliable long term than trying to teach every possible developer how to handle backwards compatible models - particularly when the clients application language of choice is something I’m not necessarily experienced in.

robertlagrant 5y ago

> I definitely wouldn’t say you can avoid needing maintenance pages just because you don’t have planned downtime to do migrations For sure. I'm just making the point that to do continuous delivery you wouldn't necessarily need maintenance mode pages, which predate continuous delivery.

stephenr 5y ago
No there are definitely alternatives, but IME having a maintenance page is a good idea/necessity anyway, and the engineering involved to activate it during deployments is essentially set and forget, whereas the engineering to make your application backwards compatible with any possible schema change is entirely an ongoing issue, and a lot more complex. If your development team is sufficiently experienced to do allow for the no-downtime approach that’s a big win, but my experience so far makes me pessimistic about how widespread that kind of experience is. Edit: I should clarify somewhat: I’ve had to introduce at least one of the following concepts at basically every client: continuous/automatic deployments; automatic migrations; automatic maintenance pages during outages (planned or otherwise); and hard as it is to believe: version control. My clients are typically smallish, so anything I can do to solve problems/provide solutions at the infra layer is a no-brainer because setting up an automated {enable maintenance mode; apply migrations; disable maintenance mode} is a lot more reliable long term than trying to teach every possible developer how to handle backwards compatible models - particularly when the clients application language of choice is something I’m not necessarily experienced in.