Hacker News Reader

Comment by btmorex | Hacker News Reader

> We should also strive to reduce the amount of time PRs sit in master without being live.

Simplest solution at the scale and level of reliability that I've had experience with is to effectively say that master is what's live. In other words, a merge to master triggers a deploy under normal circumstances. It'll save you a lot of headaches. That plus one command/click deploy last known good build and feature flagging all major updates pretty much removes the whole deploy process as a significant failure risk.

View on HN

Often times database changes are a complex multi-stage process. Since we're still a small team, we're able to have them merged as a single PR and the author deploys each commit as needed. A complicated CD process would just add more burden on our team at this size, and is really more useful when you have enough people contributing that those sort of complex deploys block other people's work

This is counter to my experience, I've worked with multiple small teams (6 people at most), that all have datastore integrations, and CI/CD pipelines generally make them faster.

> those sort of complex deploys block other people's work

I think this is the root cause of your concerns, the database migrations seem to always be backwards incompatible and therefore deployments and migrations need to be synced, blocking other changes.

Typically CI/CD pipelines are never blocked.

Making sure the database migration / code change is backwards compatible is minimally more tedious (i.e. multiple incremental changes across multiple days), but overall speeds up development.

I think you make some assumptions that are context-specific.

The decision to always be backwards compatible is just that, a decision. It comes with some really nice benefits around CI/CD, but also adds overhead for certain kinds of development, especially if data models are evolving rapidly. I've been in situations where we made the explicit decision not be backwards compatible due to business context that prioritized these evolutions.

Likewise, deploying to production continuously is not always an option. I've been in situations where customer relationships (contractual or otherwise) require that changes not be made continuously. Accidental outages or regressions are simply not an acceptable risk in some business contexts.

On the other hand, without continuous deployment, my experience is that a deployment to live always goes wrong, meaning you have to budget an entire night for one deployment, and hope you’ll fix all the issues before next morning.

As always, it depends.

I've seen staged releases work quite well at multiple companies and fail miserably at some others.

That said, continuous deployment is the right choice in many/most contexts. I'd just prefer that people see it as a choice instead of assuming that it's the only way that can work.

Reply on news.ycombinator.com