Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Thoughts on baseline requirements for deploying a server applicaiton to production.

Operations Team should not deploy a new software application to production unless the Development Team complies with the following minimum requirements:

Software Requirements

  • Packaging: the application must conform to conventions for configuration, directory structure and run scripts:

    • Configuration
    • Deployment Build
    • Run script
  • Reference Configuration: The reference configuration file included in the package must:

    • be free of settings specific to a single user's development environment, such as a local file path that only exists on the developer's work station (/home/nzucker/projects/tmpdata)
    • have in-line documentation explaining each setting (or individually or in blocks).
  • Log File Locations and Format: the application must generate log files that:

  • have names and locations that are defined via configuration (i.e. not hard-coded in compiled source code).

  • have names and locations that can be cleaned up / rotated by the standard operations procedures.

  • have contents that can be parsed and loaded into a log monitoring tool like LogStash.

  • Logging Configuration: If log configuration is file-based (i.e. logback.xml), the config file must be located in the standard configuration directory (i.e. not packaged and loaded from a JAR).

  • Versioning: on startup, the application must log its version number.

    • Alternatively, the application must provide a "version" command (e.g. ./start-app.sh --version)
    • The version number must exactly match a specific tag and/or commit ID ("hash") in source control.

Additional Requirements

  • Contact List
    • Lead Developer Contact
    • Backup Developer Contact
    • Product Owner / Sponsor
  • Run Book

Recommended

The following checklist items are not strictly required to get an application into Production, but having them will make production support much easer:

  • The application should send an email when serious/unexpected errors occur.
    • Long-running jobs (such as end of day or batch reporting procedures) should send emails upon start, completion and critical/fatal errors.
    • The "To" address of such emails should be configurable (but with a sensible default)
  • The application should have RESTful endpoint(s) that a monitoring tool can query for serious application error, liveness or "excessive load" conditions.
  • The application should run with an a performance monitoring agent (such as New Relic or AppDynamics), so Development can investigate performance and error conditions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment