Operations Team should not deploy a new software application to production unless the Development Team complies with the following minimum 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).
- 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 (
-
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.
- Alternatively, the application must provide a "version" command (e.g.
- Contact List
- Lead Developer Contact
- Backup Developer Contact
- Product Owner / Sponsor
- Run Book
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.