Test driven infrastructure
3 likes2,136 views
The document discusses the principles and practices of Test Driven Development (TDD) and Infrastructure as Code (IaC), emphasizing the importance of writing failing tests before production code to enhance code quality and facilitate incremental design changes. It outlines the process of testing, including acceptance and unit tests, along with practical exercises using tools like Chef and Vagrant to manage infrastructure. The document further highlights the benefits and challenges of TDD and IaC, concluding with the potential for continuous delivery in IT operations.
![---
driver:
name: vagrant
provisioner:
name: chef_zero
platforms:
- name: ubuntu-14.04
suites:
- name: default
run_list:
- recipe[httpd::default]
httpd-cookbook/.kitchen.yml](https://image.slidesharecdn.com/testdriveninfrastructure-151210160216/85/Test-driven-infrastructure-43-320.jpg)
![...
"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](https://image.slidesharecdn.com/testdriveninfrastructure-151210160216/85/Test-driven-infrastructure-75-320.jpg)
![...
"provisioners": [
{
"type": "chef-solo",
"cookbook_paths": ["berks-cookbooks"],
"run_list": ["httpd::default"]
}
]
}
packer.json - 3](https://image.slidesharecdn.com/testdriveninfrastructure-151210160216/85/Test-driven-infrastructure-76-320.jpg)
Test driven infrastructure
- 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
- 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
- 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