mitodl/handbook

What does it mean to be "production ready"?

justinabrahms opened this issue · 4 comments

I'm assuming we have standards for what "production ready" entails. I'd further assume that there are things that devs should know about, like taking configuration information in as env vars. Hoping someone could maybe write up some guidelines on what this means.

@bdero?

bdero commented

Production ready applications:
At the application scope, the high level description of what I see as "production ready" from an deployment/ops standpoint is this: http://12factor.net/
From a product standpoint, the application is production ready when it meets MVP requirements, which highly varies between projects.

Production ready features:
Any time a new changeset impedes any of those guidelines (for example, a changeset might introduce a feature that, by design, obscures logging or fails silently in a production setting), it's not a production ready change, and should not be promoted in the release pipeline. Additionally, for any code change to become "production ready", it must be verified working in the context of a controlled pre-production environment identical to production.

This is sort of the tip of the iceberg, as it's a big topic.

Do you have a punch list of "all prod ready apps have: new relic
monitoring, logs going to syslog, have a documented release process with
tooling that includes promoting a staging build to production" etc?

On Wednesday, November 25, 2015, Brandon DeRosier notifications@github.com
wrote:

Production ready applications:
At the application scope, the high level description of what I see as
"production ready" from an deployment/ops standpoint is this:
http://12factor.net/
From a product standpoint, the application is production ready when it
meets MVP requirements, which highly varies between projects.

Production ready features:
Any time a new changeset impedes on any of those guidelines (for example,
a changeset might introduce a feature that, by design, obscures logging or
fails silently in a production setting), it's not a production ready
change, and should not be promoted in the release pipeline. Additionally,
for any code change to become "production ready", it must be verified
working in the context of a controlled pre-production environment identical
to production.

This is sort of the tip of the iceberg, as it's a big topic.


Reply to this email directly or view it on GitHub
#3 (comment).

Sent via mobile phone.

bdero commented

Nope, I'll draft a doc and make a PR to this repo with the info above and a production requirements list.

bdero commented

This was solved by #6 !