1. StatusHva kan vi om testing av infrastruktur-kode?
Vi skiller kodemiljøene frahverandre
Kanskje en branch, deretter dev, test, qa før prod
Vi itererer raskt i dev-miljøet
Vagrant, VMware, OpenStack, LXC/Docker
Vi validerer syntaks ogkodestil automatisk
Integrert med versjonskontroll og CI
Vi kjører unit- ogintegrasjonstesting
Modules/cookbooks/bundles er kodekomponenter
Hmm .. gjør vi egentlig det?
Vi overvåker og målerinfrastrukturen
Vi overvåker og målerinfrastrukturen tjenestene
OK, men det gjør vi jo? Det gjør vel alle?
- Ja, i prod!
2. Hva er
egentlig
infrastruktur-
kode?Ikke ditt typiske utviklingsprosjekt, nei
Det egentlige artifaktet eret dynamisk system!
Start-tilstanden vil ofte være ukjent
Kjøring av koden har flereinputs enn dine!
Ikke anta for mye om miljøet
Koden beskriver entilstand!
Dersom tilstandsbeskrivelsen er korrekt, hva er igjen åteste?
Tradisjonell testing trefferikke godt nok!
Unit- og integrasjonstester gir mindre gevinst
3. Test-pyramiden
faller?.. eller hvorfor infra-kodere liker iskrem
Originalen
Mike Cohn, (2009)Succeeding with Agile
Pyramiden 2.0
Robert C. Martin, (2011)The Clean Coder
4. Løsninger?Endeling kan vi snakke om verktøy!
og Serverspec mspectatorrspec-system
ServerspecVerktøy og bibliotek for utside-inn testing av server-
infrastruktur
@beddari tidlig i 2013:
Hurra!
Dette er jo enn veldig veldig VELDIG god ide!
Alle kan skrive tester medserverspec
Ops? Det er bare bash med en wrapper rundt!
Dev? Det er rspec, du kan jo det/lærer det lett!
Både et verktøy i seg selv og etbibliotek
Ferdig util for å kjøre tester via Vagrant og SSH
Vi vil se kode![root@localhost serverspec-eksempel]# tree.├── Rakefile└── spec ├── centos64 │ └── httpd_spec.rb └── spec_helper.rb
Mulighet for en gjenbrukbartestbase!!
På kryss av ansvar og bakgrunn
Er alt bare fryd ..
Nei, prosjektet har utfordringer rundt beskrivelse av flerenoder og .. syntaks!
Ideer til implementasjon ...tenkehatten på!
Testene bør skrives av andreVi kan hente data fra ikke-kodet-infrastruktur, typiskstorage, nettverkBenytte testene i hele kjeden helt fra dev til prodTesting blir en form for overvåkning? WIN!
mspectatorFullt ut integrert infrastruktur-testing med Mcollective av
Raphaël Pinson, Camp2camp
mspectator kan benyttemcollective-filter
Løser problemet med at serverspec knytter testene motFQDN
.. also, since I installed mcollective, I lost 5kg, I can see in the dark and cook without using my hands
require 'mspectator'
describe "apache::server" do it { should find_nodes(10).or_less.with_agent('spec') } it { should have_certificate.signed } it { should pass_puppet_spec }
context "when on Debian", :facts => [:operatingsystem => "Debian"] do it { should find_nodes(5).or_more } it { should have_service('apache2').with( :ensure => 'running', :enable => 'true' ) } it { should have_package('apache2') } it { should have_user('www-data') } endend
Arkitekturen er mer komplisert
En må naturlig nok ha mcollective ...Testene må deployes til nodene som skal kjøre deTaper noe av elegansen, vinner i utbytte!
rspec-systemEt undercover Puppetlabs-prosjekt av Ken Barber
Mange av de samme tankene
Testing av systemer og gjerne større sett av noder
sammen
SSH som default-transport
Vurderer å ta i bruk serverspec som lib
5. Referanserog linker
Tekster
The Clean Coder: A Code of Conduct for Professional