Repos-que-me-gustan/devops-exercises
1
0
Fork 0
Code Pull Requests Activity

Answer some DevOps questions (#106)

Browse Source
This commit is contained in:
TWC 2020-09-10 04:47:27 +02:00 committed by GitHub
parent ee50fa9bef
commit 6bd8879001
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -133,10 +133,18 @@ Each piece of code (change/patch) is verified, to make the change is safe to mer
<details> <details>
<summary>What is Continuous Deployment?</summary><br><b> <summary>What is Continuous Deployment?</summary><br><b>
A development strategy used by developers to release software automatically into production where any code commit must pass through an automated testing phase. Only when this is successful is the release considered production worthy. This eliminates any human interaction and should be implemented only after production-ready pipelines have been set with real-time monitoring and reporting of deployed assets. If any issues are detected in production it should be easy to rollback to previous working state.
For more info please read [here](https://www.atlassian.com/continuous-delivery/continuous-deployment)
</b></details> </b></details>
<details> <details>
<summary>What is Continuous Delivery?</summary><br><b> <summary>What is Continuous Delivery?</summary><br><b>
A development strategy used to frequently deliver code to QA and Ops for testing. This entails having a staging area that has production like features where changes can only be accepted for production after a manual review. Because of this human entanglement there is usually a time lag between release and review making it slower and error prone as compared to continous deployment.
For more info please read [here](https://www.atlassian.com/continuous-delivery/continuous-deployment)
</b></details> </b></details>
<details> <details>
@ -260,7 +268,7 @@ One can argue whether it's per company definition or a global one but at least a
* MTTF (mean time to failure) other known as uptime, can be defined as how long the system run before if fails. * MTTF (mean time to failure) other known as uptime, can be defined as how long the system run before if fails.
* MTTR (mean time to recover) on the other hand, is the amount of time it takes to repair a system. * MTTR (mean time to recover) on the other hand, is the amount of time it takes to repair a system.
* MTBF (mean time between failues) is the amount of between failures of the system. These errors can be intermittent or fatal. * MTBF (mean time between failues) is the amount of time between failures of the system. These errors can be intermittent or fatal.
</b></details> </b></details>