Add Grafana graphs

.gitignore

@@ -1 +1,2 @@
 app/vendor
+.DS_Store

README.md

@@ -11,17 +11,17 @@ nt-strategies/).
 
 - [recreate](recreate/README.md): terminate the old version and release the new
   one
-- [ramped](recreate/README.md): release a new version on a rolling update
-  fashion, one after the other
-- [blue/green](recreate/README.md): release a new version alongside the old
+- [ramped](ramped/README.md): release a new version on a rolling update fashion,
+  one after the other
+- [blue/green](blue-green/README.md): release a new version alongside the old
   version then switch traffic
-- [canary](recreate/README.md): release a new version to a subset of users, then
+- [canary](canary/README.md): release a new version to a subset of users, then
   proceed to a full rollout
-- [a/b testing](recreate/README.md): release a new version to a subset of users
-  in a precise way (HTTP headers, cookie, weight, etc.). This doesn’t come out
-  of the box with Kubernetes, it imply extra work to setup a smarter
+- [a/b testing](ab-testing/README.md): release a new version to a subset of
+  users in a precise way (HTTP headers, cookie, weight, etc.). This doesn’t come
+  out of the box with Kubernetes, it imply extra work to setup a smarter
   loadbalancing system (Istio, Linkerd, Traeffik, custom nginx/haproxy, etc).
-- [shadow](recreate/README.md): release a new version alongside the old version.
+- [shadow](shadow/README.md): release a new version alongside the old version.
   Incoming traffic is mirrored to the new version and doesn't impact the
   response.
 

blue-green/README.md

@@ -4,6 +4,8 @@ Blue/green deployment
 > Version B is released alongside version A, then the traffic is switched to
 version B. Also known as red/black deployment.
 
+![kubernetes blue-green deployment](grafana-blue-green.png)
+
 The blue/green deployment strategy differs from a ramped deployment, version B
 (green) is deployed alongside version A (blue) with exactly the same amount of
 instances. After testing that the new version meets all the requirements the

canary/README.md

@@ -3,6 +3,8 @@ Canary deployment
 
 > Version B is released to a subset of users, then proceed to a full rollout.
 
+![kubernetes canary deployment](grafana-canary.png)
+
 A canary deployment consists of gradually shifting production traffic from
 version A to version B. Usually the traffic is split based on weight. For
 example, 90 percent of the requests go to version A, 10 percent go to version B.

ramped/README.md

@@ -4,6 +4,8 @@ Ramped deployment
 > Version B is slowly rolled out and replacing version A. Also known as
 rolling-update or incremental.
 
+![kubernetes ramped deployment](grafana-ramped.png)
+
 The ramped deployment strategy consists of slowly rolling out a version of an
 application by replacing instances one after the other until all the instances
 are rolled out. It usually follows the following process: with a pool of version