You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+9-1Lines changed: 9 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,10 +133,18 @@ Each piece of code (change/patch) is verified, to make the change is safe to mer
133
133
134
134
<details>
135
135
<summary>What is Continuous Deployment?</summary><br><b>
136
+
137
+
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.
138
+
139
+
For more info please read [here](https://www.atlassian.com/continuous-delivery/continuous-deployment)
136
140
</b></details>
137
141
138
142
<details>
139
143
<summary>What is Continuous Delivery?</summary><br><b>
144
+
145
+
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.
146
+
147
+
For more info please read [here](https://www.atlassian.com/continuous-delivery/continuous-deployment)
140
148
</b></details>
141
149
142
150
<details>
@@ -260,7 +268,7 @@ One can argue whether it's per company definition or a global one but at least a
260
268
261
269
* MTTF (mean time to failure) other known as uptime, can be defined as how long the system run before if fails.
262
270
* MTTR (mean time to recover) on the other hand, is the amount of time it takes to repair a system.
263
-
* MTBF (mean time between failues) is the amount of between failures of the system. These errors can be intermittent or fatal.
271
+
* MTBF (mean time between failues) is the amount of time between failures of the system. These errors can be intermittent or fatal.
0 commit comments