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.

1. @filippo
Test Driven Infrastructures

2. Filippo Liverani
@filippo

3. agile methods + IT operations?
photo credit: https://www.flickr.com/photos/kalexanderson/6354182139/

6. 1. Test Driven Development
2. Infrastructure as code
3. From theory to practice

7. Test Driven Development
photo credit: https://www.flickr.com/photos/pagedooley/4308431673/

8. write a
failing unit
test
make it
pass
refactor

9. the 3 laws of TDD
photo credit: https://www.flickr.

10. 1
You are not allowed to write
any production code unless it is
to make a failing unit test pass

11. 2
You are not allowed to write any
more of a unit test than is
sufficient to fail

12. 3
You are not allowed to write any
more production code than is
sufficient to pass the one failing
unit test

13. drives design
small incremental changes
continuous validation
rapid feedback

14. why it works?
reduces complexity
breaking down a difficult problem into smaller
pieces

15. listen to the tests
if it’s hard to write
the design is probably wrong

17. -> Acceptance Test Driven Development
acceptance criteria
examples
definition of done

18. write a failing
acceptance test

19. write a failing
acceptance test

20. write a
failing unit
test
make it
pass
refactor
write a failing
acceptance test

21. write a
failing unit
test
make it
pass
refactor
write a failing
acceptance test

22. benefits of TDD
higher code quality
regression test suite
feedback and confidence

23. more benefits of TDD
implicit acceptance criteria
executable documentation
prevent gold plating

24. challenges
takes time to learn
requires discipline
changing habits is hard
management does not perceive internal quality

25. infrastructure as code
photo credit: https://www.flickr.com/photos/mwichary/2348383457/

26. DevOps
+
virtualization and cloud
->
infrastructure is code too

27. programmatically configure and provision
everything versioned
business= code repository
+ data backup
+ compute resources

28. collaboration + automation
knowledge sharing
tooling
power of text

29. benefits
consistency and repeatability
scalability
testability
maintainability

30. challenges
spaghetti code
duplication
fear of change
low quality
side effects and chain reactions

31. TDD can help!

32. 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

33. 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

34. from theory to practice
photo credit: https://www.flickr.com/photos/jurvetson/489257240/

35. install and start Apache httpd server
exercise

36. tools needed
git
chefdk
vagrant
virtualbox
(packer)

38. $ git init httpd-cookbook
$ cd httpd-cookbook

40. $ chef generate cookbook httpd

41. Test Kitchen

42. $ kitchen init --driver=kitchen-vagrant

43. ---
driver:
name: vagrant
provisioner:
name: chef_zero
platforms:
- name: ubuntu-14.04
suites:
- name: default
run_list:
- recipe[httpd::default]
httpd-cookbook/.kitchen.yml

44. write an acceptance test

46. 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

47. watch it fail

48. $ kitchen test

49. Service "apache2"
should be running (FAILED - 1)
Port "80"
should be listening (FAILED - 2)

50. write a unit test

51. 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

52. watch it fail

53. $ chef exec rspec

54. F
Failures: 1) httpd::default installs apache2 package
Finished in 0.00957 seconds
1 example, 1 failure

55. make it pass

56. package 'apache2' do
action :install
end
httpd-cookbook/recipes/default.rb

57. $ chef exec rspec

58. .
Finished in 0.00946 seconds
1 example, 0 failures

59. refactor

60. write a unit test

61. 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

62. watch it fail

63. $ chef exec rspec

64. .F
Failures: 1) httpd::default starts apache2 service
Finished in 0.02133 seconds
2 example, 1 failure

65. make it pass

66. package 'apache2' do
action :install
end
service 'apache2' do
action :start
end
httpd-cookbook/recipes/default.rb

67. $ chef exec rspec

68. ..
Finished in 0.02041 seconds
2 example, 0 failures

69. refactor

70. make acceptance test pass

71. $ kitchen test

72. 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)

74. {
"variables": {
"aws_access_key": null,
"aws_secret_key": null
},
...
packer.json - 1

75. ...
"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

76. ...
"provisioners": [
{
"type": "chef-solo",
"cookbook_paths": ["berks-cookbooks"],
"run_list": ["httpd::default"]
}
]
}
packer.json - 3

77. source 'https://api.berkshelf.com'
cookbook 'httpd', path: './httpd-cookbook'
Berksfile

78. $ berks vendor
$ packer build
-var 'aws_access_key=YOUR ACCESS KEY'
-var 'aws_secret_key=YOUR SECRET KEY'
packer.json

79. ==> Builds finished. The artifacts of successful
builds are:
--> amazon-ebs: AMIs were created:
eu-west-1: ami-ac3199db

80. next steps
manage whole stack:
Terraform
Cloudformation
Heat
continuous delivery

81. TDD is a powerful technique
Treat your infrastructure as code
You can start now

82. risorse

86. thank you