@@ -17,6 +17,14 @@ We _could_ do all these things manually,
17
17
but a key insight of the modern infrastructure management
18
18
is that automation really pays off in reducing maintenance burdens.
19
19
20
+ // SEBASTIAN: IMO, above statement is not strong enough (my opinion)
21
+ // I'd add something that software development nowadays is made in short cycles with frequent deployments
22
+ // and automation is a MUST - the earlier one invests into it, the faster they can focus on doing what's
23
+ // actually giving value.
24
+ //
25
+ // ALSO... to reassure readers - automating anything requires deep understanding, so they will not miss anything.
26
+ // Perhaps this is even more important. When I first read this, I was like "ohhh, I'm gonna miss some fun!"
27
+
20
28
It's also key to making sure our tests give us true confidence over our deployments.
21
29
If we go to the trouble of building a staging server,footnote:[
22
30
What I'm calling a "staging" server, some people would
@@ -152,6 +160,7 @@ They're unlikely to ever go away,
152
160
and knowing a bit about them will get you some respect
153
161
from all the grizzled dinosaurs out there.
154
162
163
+ // SEBASTIAN: Nice, and seem-to-be timeless choice!
155
164
156
165
157
166
==== Spinning Up a Server
@@ -908,6 +917,11 @@ but I wanted to keep this (already long) chapter as simple as possible.
908
917
*******************************************************************************
909
918
910
919
920
+ // SEBASTIAN: I feel the above section would make more sense if it was mentioned waaay earlier.
921
+ // I must say I got lost while reading about Chef, Puppet and suddenly I see some Ansible examples
922
+ // without any explanation how Ansible works, any diagrams etc.
923
+ // I'd also appreciate seeing some example of SSH first as this is a prerequisite to
924
+ // using Ansible. Currently, there are too many "open loops" and I think this chapter is hard to follow.
911
925
912
926
Let's run the latest version of our playbook and see how our tests get on:
913
927
@@ -971,6 +985,8 @@ selenium.common.exceptions.WebDriverException: Message: Reached error page:
971
985
about:neterror?e=connectionFailure&u=http%3A//staging.ottg.co.uk/[...]
972
986
----
973
987
988
+ // SEBASTIAN: It's awesome that by this moment by using `TEST_SERVER` one is able to run tests against "staging". Just wow!
989
+
974
990
975
991
That `neterror` makes me think it's another networking problem.
976
992
@@ -1397,9 +1413,15 @@ which are a fairly typical set of steps for deployment in general
1397
1413
and looking into techniques like red-green deployments.
1398
1414
// CSANAD: we haven't mentioned the downtime so far
1399
1415
1416
+ // SEBASTIAN: Is red-green deployment a thing? I must admit it's the first time
1417
+ // I see the name and so far I've only know blue-green. I also read there's red-black deployment,
1418
+ // but am I looking for this wrong, so I cannot find anything about red-green? 🤔
1419
+
1400
1420
// TODO is there a better word than "switching across"?
1401
1421
// CSANAD: I can only think of "releasing" or "deploying"
1402
1422
1423
+ // SEBASTIAN: How about simply "updating" or "changing"?
1424
+
1403
1425
Every single aspect of deployment can and probably should be automated.
1404
1426
Here are a couple of general principles to think about
1405
1427
when implementing infrastructure-as-code:
@@ -1415,5 +1437,6 @@ Declarative::
1415
1437
rather than _how_ we should get there.
1416
1438
This goes hand-in-hand with the idea of idempotence above.
1417
1439
1440
+ // SEBASTIAN: Okay, this summary is goldie 👌
1418
1441
1419
1442
*******************************************************************************
0 commit comments