Anyone got some good resources on CD?
I think, especially in the cloud, I'd would fear updating a database automatically and lose data. Some of the resources in AWS/CloudFormation are "replaced" and not "updated", which gives me a bit of paranoia.
I think, especially in the cloud, I'd would fear updating a database automatically and lose data. Some of the resources in AWS/CloudFormation are "replaced" and not "updated", which gives me a bit of paranoia.
Beyond that however it’s about taking a look at your processes and your particular challenges.
Say if you have a old-school DB with lots of stored procs, no or not enough tests, and that people tremble to update, that DB is a business risk.
You should have backups and contingency plans (eg a hot standby?) to ensure updates are resilient even if something fails. And of course the “good hygiene” of adding columns, using feature flags etc as the other commenter wrote.
Once you’re less worried about the database, you can start refactoring it if you wish.
Refactoring a large, entrenched database is a large topic but re publicly available case studies, have a look at Netflix’s case study on how they migrated their billing system away from Oracle[1].
[1] http://techblog.netflix.com/2016/06/netflix-billing-migratio...
Currently, I'm mostly interested in greenfield projects and how to do things the right way from start.
On the AWS/CloudFormation side, "Cattle, not pets" is the motto[0]. Terraform specifically is really good at capturing the desired vs current state of your infra, and showing you what those changes will be before you apply them. Point being - as long as your automation is captured in Infra-as-code, you shouldn't care too much if something gets destroyed.
[0]- http://cloudscaling.com/blog/cloud-computing/the-history-of-...
While the latter may sound easier (and often is easier when you're starting out and iterating quickly), you will soon start to feel the pain of managing dozens of different versions of your "schema" at the app layer. I've always found it easier to only have to deal with a single schema at a time in any situation where you can't just regenerate all records on the fly, like a cache, and for which you don't care about what the specific schema was at a point in time.
If you actually do care about what the schema was at any point in time at the app layer, your app WILL need to account for any version of the data—but if you need this you're accepting the tradeoffs of the additional complexity.
Definitely more nuanced than "no migrations = easier" though.
The tradeoff is that if you're actually relying on the structure of that data, you're introducing risk since its changes aren't being intentionally managed at the DB level.