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: content/posts/171101-continuous-delivery-devops-you.markdown
+33-6Lines changed: 33 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -283,32 +283,59 @@ failure scenarios?
283
283
284
284
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.030.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="Eventually you ship code into production that breaks your application.">
285
285
286
-
...
286
+
If you do not have the right tools and processes in place, eventually you
287
+
end up with a broken production environment after shipping code. What is
288
+
one tool we can use to be confident that the code going into production is
289
+
not broken?
287
290
288
291
289
292
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.031.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="Text that reads 'automated testing' with example code coverage in the background.">
290
293
291
-
...
294
+
Automated testing, in its many forms, such as unit testing, integration
295
+
testing, security testing and performance testing, helps to ensure the
296
+
integrity of the code. You need to automate because manual testing is too
297
+
slow.
298
+
299
+
Other important tools that fall into the automated testing bucket but are
300
+
not traditionally thought of as a "test case" include code coverage and
301
+
code metrics (such as Cyclomatic Complexity).
292
302
293
303
294
304
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.032.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="Automated tests in dev only deploy to production when they are successful.">
295
305
296
-
...
306
+
Awesome, now you only deploy to production when a big batch of automated
307
+
test cases ensure the integrity of your code. All good, right?
297
308
298
309
299
310
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.033.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="Bugs can still occur in production.">
300
311
301
-
...
312
+
Err, well no. Stuff can still break in production, espcially in environments
313
+
where for various reasons you do not have the same exact data in test
314
+
that you do in production. Your automated tests and code metrics will
315
+
simply not catch every last scenario that could go wrong in production.
302
316
303
317
304
318
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.034.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="Text that reads 'monitoring and alerting' with New Relic dashboard in the background.">
305
319
306
-
...
320
+
When something goes wrong with your application, you need monitoring to
321
+
know what the problem is, and alerting to tell the right folks. Traditionally,
322
+
the "right" people were in operations. But over time many organizations
323
+
realized the ops folks ended up having to call the original application
324
+
developers who wrote the code that had the problem.
307
325
308
326
309
327
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.035.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="When something breaks in prod, your developers know about it and can fix the problem.">
310
328
311
-
...
329
+
A critical piece to DevOps is about ensuring the appropriate developers
330
+
are carrying the pagers. It sucks to carry the pager and get woken up in the
331
+
middle of the night, but it's a heck of a lot easier to debug the code that
332
+
your team wrote than if you are a random ops person who's never seen the
333
+
code before in her life.
334
+
335
+
Another by-product of having application developers carry the "pagers" for
336
+
alerts on production issues is that over time the code they write is more
337
+
defensive. Errors are handled more appropriately, because otherwise you know
338
+
something will blow up on you later on at a less convenient time.
312
339
313
340
314
341
<imgsrc="/img/171101-devops-cd-you/devops-cd-you.036.jpg"width="100%"class="technical-diagram img-rounded"style="border: 1pxsolid#aaa"alt="When production is running smoothly with many tests, do that increase the chance of black swan-type events?">
0 commit comments