O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Test driven infrastructure

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 86 Anúncio

Test driven infrastructure

Baixar para ler offline

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.

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.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (19)

Semelhante a Test driven infrastructure (20)

Anúncio

Mais de XPeppers (20)

Mais recentes (20)

Anúncio

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

×