[joshdotsmith]

Does anyone have resources on how one should design their changes to run side-by-side? I have not been at large companies and don't have the advantage of institutional knowledge to help here. Book, articles, and practical examples would be fantastic.

And since it's often hard to generalize, I work today with Elixir and Postgres. Anything specific around this stack would be exceptional.

[lukejduncan]

I don't know if this helps, but reading up on backwards and forwards compatibility can get you in the right direction. The same concepts apply, but the details may very. For API interfaces read up on or think through best practices around overloading old fields, adding new fields, removing old fields, making them optional. I remember Acro had a "schema evolution" doc that talks through some of these concepts and they may apply to things you care about. For databases, I've seen updates staged as pre-commit, post-commit, and rollback patchs. Pre-commit modifies the database in a backwards compatible way -- for example adding new fields and mutating old fields into them if necessary. Code would be pushed live and could read the "old" or "new" way. After all the code is rolled out and there's high confidence the post commit would cleanup things left behind only for backwards conpatabaility reasons. Rollback only operated on pre-commit, post commit may be destructive.

[lukejduncan]

Acro == Avro

[jlgaddis]

click "edit"

[lukejduncan]

sorry, was on mobile

[hlieberman]

For Elixir in particular, you should be using appups and relups if you want hot code reloading with the ability to instantly and safely fall back.

It's important to remember, appups and relups are themselves code that needs separate testing. Ericsson engineers spend as much time (if not more!) testing the relups as they do writing new code.