Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
@filippo
Test Driven Infrastructures
Filippo Liverani
@filippo
agile methods + IT operations?
photo credit: https://www.flickr.com/photos/kalexanderson/6354182139/
1. Test Driven Development
2. Infrastructure as code
3. From theory to practice
Test Driven Development
photo credit: https://www.flickr.com/photos/pagedooley/4308431673/
write a
failing unit
test
make it
pass
refactor
the 3 laws of TDD
photo credit: https://www.flickr.
1
You are not allowed to write
any production code unless it is
to make a failing unit test pass
2
You are not allowed to write any
more of a unit test than is
sufficient to fail
3
You are not allowed to write any
more production code than is
sufficient to pass the one failing
unit test
drives design
small incremental changes
continuous validation
rapid feedback
why it works?
reduces complexity
breaking down a difficult problem into smaller
pieces
listen to the tests
if it’s hard to write
the design is probably wrong
-> Acceptance Test Driven Development
acceptance criteria
examples
definition of done
write a failing
acceptance test
write a failing
acceptance test
write a
failing unit
test
make it
pass
refactor
write a failing
acceptance test
write a
failing unit
test
make it
pass
refactor
write a failing
acceptance test
benefits of TDD
higher code quality
regression test suite
feedback and confidence
more benefits of TDD
implicit acceptance criteria
executable documentation
prevent gold plating
challenges
takes time to learn
requires discipline
changing habits is hard
management does not perceive internal quality
infrastructure as code
photo credit: https://www.flickr.com/photos/mwichary/2348383457/
DevOps
+
virtualization and cloud
->
infrastructure is code too
programmatically configure and provision
everything versioned
business= code repository
+ data backup
+ compute resources
collaboration + automation
knowledge sharing
tooling
power of text
benefits
consistency and repeatability
scalability
testability
maintainability
challenges
spaghetti code
duplication
fear of change
low quality
side effects and chain reactions
TDD can help!
testing what?
Acceptance tests
Prototypes
Exploratory testing
Usability testing
Unit tests
Integration tests
Performance t...
testing what?
Acceptance tests
Prototypes
Exploratory testing
Usability testing
Unit tests
Integration tests
Performance t...
from theory to practice
photo credit: https://www.flickr.com/photos/jurvetson/489257240/
install and start Apache httpd server
exercise
tools needed
git
chefdk
vagrant
virtualbox
(packer)
$ git init httpd-cookbook
$ cd httpd-cookbook
$ chef generate cookbook httpd
Test Kitchen
$ kitchen init --driver=kitchen-vagrant
---
driver:
name: vagrant
provisioner:
name: chef_zero
platforms:
- name: ubuntu-14.04
suites:
- name: default
run_list:
-...
write an acceptance test
require 'spec_helper'
describe service('apache2') do
it { should be_running }
describe port(80) do
it { should be_listenin...
watch it fail
$ kitchen test
Service "apache2"
should be running (FAILED - 1)
Port "80"
should be listening (FAILED - 2)
write a unit test
require 'spec_helper'
describe 'httpd::default' do
let(:chef_run) {
ChefSpec::SoloRunner.converge(described_recipe)
}
it '...
watch it fail
$ chef exec rspec
F
Failures: 1) httpd::default installs apache2 package
Finished in 0.00957 seconds
1 example, 1 failure
make it pass
package 'apache2' do
action :install
end
httpd-cookbook/recipes/default.rb
$ chef exec rspec
.
Finished in 0.00946 seconds
1 example, 0 failures
refactor
write a unit test
require 'spec_helper'
describe 'httpd::default' do
let(:chef_run) {
ChefSpec::SoloRunner.converge(described_recipe)
}
it '...
watch it fail
$ chef exec rspec
.F
Failures: 1) httpd::default starts apache2 service
Finished in 0.02133 seconds
2 example, 1 failure
make it pass
package 'apache2' do
action :install
end
service 'apache2' do
action :start
end
httpd-cookbook/recipes/default.rb
$ chef exec rspec
..
Finished in 0.02041 seconds
2 example, 0 failures
refactor
make acceptance test pass
$ kitchen test
Service "apache2"
should be running
Port "80"
should be listening
Finished in 0.09441 seconds
2 example, 0 failures
Finish...
{
"variables": {
"aws_access_key": null,
"aws_secret_key": null
},
...
packer.json - 1
...
"builders": [{
"type": "amazon-ebs",
"access_key": "{{user `aws_access_key`}}",
"secret_key": "{{user `aws_secret_key`...
...
"provisioners": [
{
"type": "chef-solo",
"cookbook_paths": ["berks-cookbooks"],
"run_list": ["httpd::default"]
}
]
}
p...
source 'https://api.berkshelf.com'
cookbook 'httpd', path: './httpd-cookbook'
Berksfile
$ berks vendor
$ packer build 
-var 'aws_access_key=YOUR ACCESS KEY' 
-var 'aws_secret_key=YOUR SECRET KEY' 
packer.json
==> Builds finished. The artifacts of successful
builds are:
--> amazon-ebs: AMIs were created:
eu-west-1: ami-ac3199db
next steps
manage whole stack:
Terraform
Cloudformation
Heat
continuous delivery
TDD is a powerful technique
Treat your infrastructure as code
You can start now
risorse
thank you
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Test driven infrastructure
Upcoming SlideShare
Loading in …5
×

Test driven infrastructure

1,562 views

Published on

Many IT operations teams are used to managing infrastructure manually or with simple one-off scripts. This manual work and lack of verifiable behavior results in many issues and in uncertainty. In software development, Test Driven Development (TDD) is well recognized for improving design, increasing code quality, and allowing refactoring and better knowledge sharing.
Similar benefits can be gained in infrastructure projects when infrastructure is treated as code, driving that code development with tests. Configuration management tools such as Chef and Puppet allow infrastructure to be easily described as code and provide a complete support to introduce and run tests. This can allow development and operations teams to collaborate and confidently deliver working infrastructure code.

Published in: Technology
  • DOWNLOAD FULL. BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Test driven infrastructure

  1. 1. @filippo Test Driven Infrastructures
  2. 2. Filippo Liverani @filippo
  3. 3. agile methods + IT operations? photo credit: https://www.flickr.com/photos/kalexanderson/6354182139/
  4. 4. 1. Test Driven Development 2. Infrastructure as code 3. From theory to practice
  5. 5. Test Driven Development photo credit: https://www.flickr.com/photos/pagedooley/4308431673/
  6. 6. write a failing unit test make it pass refactor
  7. 7. the 3 laws of TDD photo credit: https://www.flickr.
  8. 8. 1 You are not allowed to write any production code unless it is to make a failing unit test pass
  9. 9. 2 You are not allowed to write any more of a unit test than is sufficient to fail
  10. 10. 3 You are not allowed to write any more production code than is sufficient to pass the one failing unit test
  11. 11. drives design small incremental changes continuous validation rapid feedback
  12. 12. why it works? reduces complexity breaking down a difficult problem into smaller pieces
  13. 13. listen to the tests if it’s hard to write the design is probably wrong
  14. 14. -> Acceptance Test Driven Development acceptance criteria examples definition of done
  15. 15. write a failing acceptance test
  16. 16. write a failing acceptance test
  17. 17. write a failing unit test make it pass refactor write a failing acceptance test
  18. 18. write a failing unit test make it pass refactor write a failing acceptance test
  19. 19. benefits of TDD higher code quality regression test suite feedback and confidence
  20. 20. more benefits of TDD implicit acceptance criteria executable documentation prevent gold plating
  21. 21. challenges takes time to learn requires discipline changing habits is hard management does not perceive internal quality
  22. 22. infrastructure as code photo credit: https://www.flickr.com/photos/mwichary/2348383457/
  23. 23. DevOps + virtualization and cloud -> infrastructure is code too
  24. 24. programmatically configure and provision everything versioned business= code repository + data backup + compute resources
  25. 25. collaboration + automation knowledge sharing tooling power of text
  26. 26. benefits consistency and repeatability scalability testability maintainability
  27. 27. challenges spaghetti code duplication fear of change low quality side effects and chain reactions
  28. 28. TDD can help!
  29. 29. testing what? Acceptance tests Prototypes Exploratory testing Usability testing Unit tests Integration tests Performance testing Security testing Business facing Technology facing Supporting the team Critique Product credit: Brian Marik
  30. 30. testing what? Acceptance tests Prototypes Exploratory testing Usability testing Unit tests Integration tests Performance testing Security testing Business facing Technology facing Supporting the team Critique Product credit: Brian Marik
  31. 31. from theory to practice photo credit: https://www.flickr.com/photos/jurvetson/489257240/
  32. 32. install and start Apache httpd server exercise
  33. 33. tools needed git chefdk vagrant virtualbox (packer)
  34. 34. $ git init httpd-cookbook $ cd httpd-cookbook
  35. 35. $ chef generate cookbook httpd
  36. 36. Test Kitchen
  37. 37. $ kitchen init --driver=kitchen-vagrant
  38. 38. --- driver: name: vagrant provisioner: name: chef_zero platforms: - name: ubuntu-14.04 suites: - name: default run_list: - recipe[httpd::default] httpd-cookbook/.kitchen.yml
  39. 39. write an acceptance test
  40. 40. require 'spec_helper' describe service('apache2') do it { should be_running } describe port(80) do it { should be_listening } end end httpd-cookbook/test/integration/server/serverspec/default_spec. rb
  41. 41. watch it fail
  42. 42. $ kitchen test
  43. 43. Service "apache2" should be running (FAILED - 1) Port "80" should be listening (FAILED - 2)
  44. 44. write a unit test
  45. 45. require 'spec_helper' describe 'httpd::default' do let(:chef_run) { ChefSpec::SoloRunner.converge(described_recipe) } it 'installs apache2 package' do expect(chef_run).to install_package('apache2') end end httpd-cookbook/spec/unit/recipes/default_spec.rb
  46. 46. watch it fail
  47. 47. $ chef exec rspec
  48. 48. F Failures: 1) httpd::default installs apache2 package Finished in 0.00957 seconds 1 example, 1 failure
  49. 49. make it pass
  50. 50. package 'apache2' do action :install end httpd-cookbook/recipes/default.rb
  51. 51. $ chef exec rspec
  52. 52. . Finished in 0.00946 seconds 1 example, 0 failures
  53. 53. refactor
  54. 54. write a unit test
  55. 55. require 'spec_helper' describe 'httpd::default' do let(:chef_run) { ChefSpec::SoloRunner.converge(described_recipe) } it 'installs apache2 package' do expect(chef_run).to install_package('apache2') end it 'starts apache2 service' do expect(chef_run).to start_service('apache2') end end httpd-cookbook/spec/unit/recipes/default_spec.rb
  56. 56. watch it fail
  57. 57. $ chef exec rspec
  58. 58. .F Failures: 1) httpd::default starts apache2 service Finished in 0.02133 seconds 2 example, 1 failure
  59. 59. make it pass
  60. 60. package 'apache2' do action :install end service 'apache2' do action :start end httpd-cookbook/recipes/default.rb
  61. 61. $ chef exec rspec
  62. 62. .. Finished in 0.02041 seconds 2 example, 0 failures
  63. 63. refactor
  64. 64. make acceptance test pass
  65. 65. $ kitchen test
  66. 66. Service "apache2" should be running Port "80" should be listening Finished in 0.09441 seconds 2 example, 0 failures Finished verifying <default-ubuntu-1404> (0m6.52s). -----> Kitchen is finished. (0m31.77s)
  67. 67. { "variables": { "aws_access_key": null, "aws_secret_key": null }, ... packer.json - 1
  68. 68. ... "builders": [{ "type": "amazon-ebs", "access_key": "{{user `aws_access_key`}}", "secret_key": "{{user `aws_secret_key`}}", "region": "eu-west-1", "ami_virtualization_type": "hvm", "source_ami": "ami-28ff505f", "instance_type": "t2.micro", "ssh_username": "ubuntu", "ami_name": "httpd" }] ... packer.json - 2
  69. 69. ... "provisioners": [ { "type": "chef-solo", "cookbook_paths": ["berks-cookbooks"], "run_list": ["httpd::default"] } ] } packer.json - 3
  70. 70. source 'https://api.berkshelf.com' cookbook 'httpd', path: './httpd-cookbook' Berksfile
  71. 71. $ berks vendor $ packer build -var 'aws_access_key=YOUR ACCESS KEY' -var 'aws_secret_key=YOUR SECRET KEY' packer.json
  72. 72. ==> Builds finished. The artifacts of successful builds are: --> amazon-ebs: AMIs were created: eu-west-1: ami-ac3199db
  73. 73. next steps manage whole stack: Terraform Cloudformation Heat continuous delivery
  74. 74. TDD is a powerful technique Treat your infrastructure as code You can start now
  75. 75. risorse
  76. 76. thank you

×