Confirmed users
2,456
edits
ReleaseEngineering/Development Best Practices: Difference between revisions
ReleaseEngineering/Development Best Practices (view source)
Revision as of 19:26, 27 April 2018
, 27 April 2018→Resiliency: Add note about graceful shutdown
(→Browser-side: Update recommendations) |
(→Resiliency: Add note about graceful shutdown) |
||
| Line 48: | Line 48: | ||
Think about resiliency from the beginning, as reliable resiliency is generally embedded in the architecture of the tool, making it hard to change later. | Think about resiliency from the beginning, as reliable resiliency is generally embedded in the architecture of the tool, making it hard to change later. | ||
* If you're building a daemon, build it so that it can be restarted it at will without any serious ill effects. | * If you're building a daemon, build it so that it can be restarted it at will without any serious ill effects. | ||
** Add support for gracefully stopping your service so that new versions or configurations can be deployed without downtime | |||
** To this end, do not store state in memory, including in the call stack. If you have a long-running process that you don't want to restart during a transient failure, then break that task up, persist intermediate state somewhere, and be able to pick up where you left off. This is often most easily accomplished with an explicit state machine. It's impossible to achieve with a function. | ** To this end, do not store state in memory, including in the call stack. If you have a long-running process that you don't want to restart during a transient failure, then break that task up, persist intermediate state somewhere, and be able to pick up where you left off. This is often most easily accomplished with an explicit state machine. It's impossible to achieve with a function. | ||
* Retry everything: HTTP requests, DB queries, DNS lookups, etc. | * Retry everything: HTTP requests, DB queries, DNS lookups, etc. | ||