10. snomed
428071000124103 Current Heavy tobacco smoker Current Heavy tobacco smoker Smoking Status
428061000124105 Current Light tobacco smoker Current Light tobacco smoker Smoking Status
428041000124106 Current some day smoker Current some day smoker Smoking Status
8517006 Ex-smoker (finding) Former smoker Smoking Status
266919005 Never smoked tobacco (finding) Never smoker Smoking Status
77176002 Smoker (finding)
Smoker, current status
unknown
Smoking Status
449868002 Smokes tobacco daily (finding) Current every day smoker Smoking Status
266927001
Tobacco smoking consumption
unknown (finding)
Unknown if ever smoked Smoking Status
11. snomed
428071000124103 Current Heavy tobacco smoker Current Heavy tobacco smoker Smoking Status
428061000124105 Current Light tobacco smoker Current Light tobacco smoker Smoking Status
428041000124106 Current some day smoker Current some day smoker Smoking Status
8517006 Ex-smoker (finding) Former smoker Smoking Status
266919005 Never smoked tobacco (finding) Never smoker Smoking Status
77176002 Smoker (finding)
Smoker, current status
unknown
Smoking Status
449868002 Smokes tobacco daily (finding) Current every day smoker Smoking Status
266927001
Tobacco smoking consumption
unknown (finding)
Unknown if ever smoked Smoking Status
70. The project
• There’s a Ruby script that…
1. Calls a REST API.
2. Creates a text file of the results.
• There’s a person that…
1. Calls the Ruby script, passing in a string.
2. Checks the text file into git.
3. Merges to master.
• There’s a person that...
1. Creates a release.
2. Deploys the release with Chef.
• There’s Java code that...
1. Finds the text file and zips it up.
2. Makes the zip file available for download via REST.
txt
ruby REST
chef
git
oozie
java
zipREST
80. The project
• There’s a Ruby script that…
1. Calls a REST API.
2. Creates a text file of the results.
• There’s a person that…
1. Calls the Ruby script, passing in a string.
2. Checks the text file into git.
3. Merges to master.
• There’s a person that...
1. Creates a release.
2. Deploys the release with Chef.
• There’s Java code that...
1. Finds the text file and zips it up.
2. Makes the zip file available for download via REST.
txt
ruby REST
chef
git
oozie
java
zipREST
81. The project
• There’s Java code that...
1. Calls a REST API.
2. Creates the text file and zips it up.
3. Makes the zip file available for download via REST.
REST
oozie
java
zipREST
82. How did we
get here?
ANSWER:
______________
______________
______________
______________
83. Stages of
Competence
Right Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
85. Stages of
Competence
Right Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
86. The project
• There’s a Ruby script that…
1. Calls a REST API.
2. Creates a text file of the results.
• There’s a person that…
1. Calls the Ruby script, passing in a string.
2. Checks the text file into git.
3. Merges to master.
• There’s a person that...
1. Creates a release.
2. Deploys the release with Chef.
• There’s Java code that...
1. Finds the text file and zips it up.
2. Makes the zip file available for download via REST.
txt
ruby REST
chef
git
oozie
java
zipREST
87. Stages of
Competence
Right Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
90. Stages of
Competence
Right Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
91. The project
• There’s Java code that...
1. Calls a REST API.
2. Creates the text file and zips it up.
3. Makes the zip file available for download via REST.
REST
oozie
java
zipREST
92. Stages of
Competence
Right Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
93. Where you
need to be
to teach
peopleRight Intuition
Right Analysis
Wrong Analysis
Wrong Intuition
unconscious
incompetence
conscious
incompetence
conscious
competence
unconscious
competence
96. Automated Deployments
An automated deployment is defined as a deployment process that occurs seamlessly without manual
intervention. The triggering of this process is outside of the scope of the deployment itself.
Minimum Requirements
Below are the minimum requirements outlined to have a successful automated deployment process. An
automated deployment MUST have each of the attributes listed below.
Consistent Deployments
It is assumed that automated deployments MUST be consistently deployed across domains.
No Intermediary Actions
With an automated deployment, there MUST be no intermediary actions that take place between the start of
the execution and the end state (regardless of that being a successful deployment or not). If any manual
intervention is made during or as a result of the deployment, it is not an automated deployment.
Idempotence
Automated deployments MUST be idempotent. If the deployment were to run multiple times, the end
state MUST be the same.
No Downtimes
Automated deployments MUST support and maintain high availability.
Pre/Post Condition Checks
Automated deployments MUST have automatic precondition and postcondition checks.
• A deployment can be initiated if and only if the precondition checks pass.
• A deployment is considered successful if and only if the postcondition checks pass.
Automated Rollbacks
Automated deployments MUST be able to automatically rollback to previously stable state based on the
result of the post condition checks.
Critical State Alerting
Automated deployments MUST have the ability to alert if the system reaches an invalid state.
Example:
1. A deployment happens
2. The post condition check fails
3. An automated rollback happens
4. The post condition for that rollback also fails
5. An alert fires to immediately have system owners investigate the state of the system
97. Logging Transparency
Automated deployments MUST have transparent logging to be able to investigate, troubleshoot, and
facilitate additional learning about the deployment process in action.
Benchmarking
Automated deployments MUST support benchmarking to account for consistency, success and failure rates,
and other metric based information.
Recommended Practices
Below are the recommended practices outlined to have a successful automated deployment process. An
automated deployment SHOULD have each of the attributes listed below.
Checkpointing
Automated deployments SHOULD support checkpointing. Checkpointing is defined as supporting the
deployment of viable partial states (if part of the deployment fails, only the part of it that failed SHOULD be
automatically rolled back). This assumes that the successful parts of the deployment are isolated and not
dependent on the failed portions.
Blackout Periods
Automated deployments SHOULD support periods of calendar time where the automated triggering of
deployments is suspended. Examples of such times would be incidents, critical events, off hours, etc.
Synthetic Traffic/Processing
Automated deployments SHOULD use synthetic traffic/processing for validation purposes. Synthetic
traffic/processing ensures greater reliability of the successfulness of a deployment.
Real-time Visibility
Automated deployments SHOULD have real-time visibility with which to see a visual representation of
deployments as they are occurring. This visibility ensures more accurate comprehension of the high level
view of the overall system.
2 Pages of documented Expectations
98. Logging Transparency
Automated deployments MUST have transparent logging to be able to investigate, troubleshoot, and
facilitate additional learning about the deployment process in action.
Benchmarking
Automated deployments MUST support benchmarking to account for consistency, success and failure rates,
and other metric based information.
Recommended Practices
Below are the recommended practices outlined to have a successful automated deployment process. An
automated deployment SHOULD have each of the attributes listed below.
Checkpointing
Automated deployments SHOULD support checkpointing. Checkpointing is defined as supporting the
deployment of viable partial states (if part of the deployment fails, only the part of it that failed SHOULD be
automatically rolled back). This assumes that the successful parts of the deployment are isolated and not
dependent on the failed portions.
Blackout Periods
Automated deployments SHOULD support periods of calendar time where the automated triggering of
deployments is suspended. Examples of such times would be incidents, critical events, off hours, etc.
Synthetic Traffic/Processing
Automated deployments SHOULD use synthetic traffic/processing for validation purposes. Synthetic
traffic/processing ensures greater reliability of the successfulness of a deployment.
Real-time Visibility
Automated deployments SHOULD have real-time visibility with which to see a visual representation of
deployments as they are occurring. This visibility ensures more accurate comprehension of the high level
view of the overall system.
2 Pages of software requirements
99. • documented expectations
• repeatable tests
• source control
• PEER Review
• User feedback
• monitoring
Automation is software
development.
