Embed Size (px)
Citation preview
Filippo Liverani@filippo
agile methods + IT operations?
photo credit: https://www.flickr.com/photos/kalexanderson/6354182139/
1. Test Driven Development2. Infrastructure as code3. 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.com/photos/oldpatterns/5837733407/
1
You are not allowed to write any production code unless it is to make a failing unit test pass
2You are not allowed to write any
more of a unit test than is sufficient to fail
3You 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 complexitybreaking down a difficult problem into smaller
pieces
listen to the tests if it’s hard to writethe design is probably wrong
-> Acceptance Test Driven Development
acceptance criteriaexamplesdefinition 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 TDDhigher code quality
regression test suite
feedback and confidence
more benefits of TDDimplicit acceptance criteria
executable documentation
prevent gold plating
challengestakes 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
benefitsconsistency and repeatability
scalability
testability
maintainability
challengesspaghetti code
duplication
fear of change
low quality
side effects and chain reactions
TDD can help!
testing what?
Acceptance testsPrototypes
Exploratory testingUsability testing
Unit testsIntegration tests
Performance testingSecurity testing
Business facing
Technology facing
Supportingthe
team
CritiqueProduct
credit: Brian Marik
testing what?
Acceptance testsPrototypes
Exploratory testingUsability testing
Unit testsIntegration tests
Performance testingSecurity testing
Business facing
Technology facing
Supportingthe
team
CritiqueProduct
credit: Brian Marik
from theory to practice
photo credit: https://www.flickr.com/photos/jurvetson/489257240/
install and start Apache httpd server
exercise
tools neededgit
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: - recipe[httpd::default]
httpd-cookbook/.kitchen.yml
write an acceptance test
require 'spec_helper'
describe service('apache2') do it { should be_running }
describe port(80) do it { should be_listening } endend
httpd-cookbook/test/integration/server/serverspec/default_spec.rb
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 'installs apache2 package' do expect(chef_run).to install_package('apache2') endend
httpd-cookbook/spec/unit/recipes/default_spec.rb
watch it fail
$ chef exec rspec
FFailures: 1) httpd::default installs apache2 packageFinished in 0.00957 seconds1 example, 1 failure
make it pass
package 'apache2' do action :installend
httpd-cookbook/recipes/default.rb
$ chef exec rspec
.Finished in 0.00946 seconds1 example, 0 failures
refactor
write a unit test
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
watch it fail
$ chef exec rspec
.FFailures: 1) httpd::default starts apache2 serviceFinished in 0.02133 seconds2 example, 1 failure
make it pass
package 'apache2' do action :installend
service 'apache2' do action :startend
httpd-cookbook/recipes/default.rb
$ chef exec rspec
..Finished in 0.02041 seconds2 example, 0 failures
refactor
make acceptance test pass
$ kitchen test
Service "apache2" should be running Port "80" should be listening Finished in 0.09441 seconds2 example, 0 failuresFinished verifying <default-ubuntu-1404> (0m6.52s).-----> Kitchen is finished. (0m31.77s)
{ "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`}}", "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
... "provisioners": [ { "type": "chef-solo", "cookbook_paths": ["berks-cookbooks"], "run_list": ["httpd::default"] } ]}
packer.json - 3
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 stepsmanage whole stack:
Terraform
Cloudformation
Heat
continuous delivery
TDD is a powerful technique
Treat your infrastructure as code
You can start now
risorse
thank you
