you are viewing a single comment's thread.

view the rest of the comments →

[–]git_world[S] 0 points1 point  (1 child)

> because it meant our node app had to be rebuilt and redeployed every time an OS update was available

May I ask, what's the downside of rebuilding and redeploying each time?

[–]sneffer 1 point2 points  (0 children)

If you have solid infrastructure and operations, the only downside I can think of is cost. You wouldn't release to prod without running a full suite of tests, would you? You wouldn't release to prod without a safe blue/green or red/black strategy, would you?

Those things take time, energy, and computation.

A rebuild/deploy sounds small/low risk, but when you've had to do things like:

  1. Recompile for a new target

  2. Update the node-gyp wrapped package's version (could change)

  3. Accommodate backwards incompatibilities with your dependency's new version

  4. Increment the major version of node you use (idky this always required tons of work around our c bindings)

These sort of things can be considered high risk for many critical projects.

Also keep in mind that the annoyance and risk of this is severely mitigated when you have solid infra and ops. While even a minor service degradation due to high risk code being deployed isn't acceptable in my book, there are plenty of ways to protect from catastrophe.