1.
TDD e Continuous Delivery
sull’infrastruttura
@filippo

2.
Filippo Liverani
@filippo

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

4.
1. test driven development
2. continuous delivery
3. nella pratica

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

6.
le 3 leggi del TDD
photo credit: https://www.flickr.
com/photos/oldpatterns/5837733407/

7.
1
Non scriverai codice di
produzione finché non avrai
scritto un test che fallisce

8.
2
Non scriverai più di un test che sia
sufficiente a provocare un
fallimento, e la non compilazione è
un fallimento

9.
3
Non scriverai più codice di
produzione di quanto ne serva per
passare il test corrente

10.
piccoli cambiamenti incrementali
sistema sempre funzionante
i fallimenti devono essere risolti subito

11.
perchè?
abbatte la complessità
soluzione di un problema complesso
→ soluzione di problemi più semplici

12.
i benefici
criterio di accettazione implicito
specifica eseguibile
suite di regressione completa
feedback immediato e continuo

13.
le difficoltà?
richiede disciplina
cambiare le abitudini è difficile
il management non capisce la qualità interna

14.
continuous delivery
photo credit: https://www.flickr.com/photos/afoncubierta/9049067504/

15.
benefici
si vede se abbiamo costruito la cosa giusta
release frequenti -> meno rischi per release
indicatore reale di avanzamento

16.
obiettivi
aumentare la qualità
diminuire il cycle time
CYCLE TIME = tempo per portare una
modifica di una linea di codice in
produzione

17.
continuous integration
photo credit: https://www.flickr.com/photos/dps/136565237/

18.
il problema
il costo per l'integrazione aumenta con:
numero di bug
numero di componenti
tempo trascorso dall'ultima integrazione

19.
la soluzione?
integrazioni rapide e continue
senza bloccare il processo

20.
i benefici
i problemi si trovano subito
si trovano facilmente
meno rischi
feedback rapido
nessun punto cieco nel processo
predizioni più accurate

21.
le 10 pratiche
photo credit: https://www.flickr.com/photos/edenpictures/3813227079/

22.
1
un solo rep ository
tutto quello che serve deve essere versionato

23.
2
build automatica
artefatto finale pronto per la produzione
ogni passo automatizzato

24.
3
test automatici
dai sorgenti ai test che girano
nessun intervento manuale
nessuna modifica dell'ambiente

25.
4
commit frequenti
al MASSIMO una volta al giorno
lavorare sul trunk

26.
5
integrazione a ogni commit
build di riferimento
monitor dello stato del repository
massima priorità alla build funzionante

27.
6
build veloce
<10min
feedback immediato
divisione in stage (pipeline)

28.
7
su un clone di produzione
stessi problemi che si verificherebbero in produzione
ambiente identico
sistema operativo
librerie
hardware
rete

29.
8
ultimo artefatto accessibile
demo e test sempre disponibili
chiaramente identificabile da tutti

30.
9
tutti vedono cosa succede
comunicazione immediata dello stato
pubblicamente accessibile

31.
10
deploy automatico
riduzione dei tempi
riduzione degli errori
rollback

32.
come arrivarci?
1. TESTARE
2. AUTOMATIZZARE
3. VELOCIZZARE

33.
delivery pipeline
photo credit: https://www.flickr.com/photos/abuaiman/6267986277/

34.
pipeline
implementazione automatizzata
del processo di build, deploy,
test e rilascio

35.
1. visibilità
2. feedback
3. controllo

36.
struttura
sequenza di stage
se uno stage fallisce la pipeline si blocca
ogni commit genera una nuova pipeline

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

38.
DevOps
+
virtualizzazione e cloud
->
anche l’infrastruttura è codice

39.
la potenza del testo
collaborazione + automazione
trasferimento della conoscenza
tooling

40.
i benefici
ripetibilità
tracciabilità
manutenibilità
velocità

41.
immutable servers

photo credit: https://www.flickr.com/photos/mwichary/2348383457/

42.
approccio tradizionale
cambiamenti e disallineamenti -
>
snowflake server

43.
sincronizzazione
creazione
immagine
provisioning
istanza
cambiamento cambiamento
applicazione
cambiamento
applicazione
cambiamento

44.
immutable server
creazione
immagine
provisioning
istanza
cambiamento
creazione
immagine
provisioning
istanza

45.
nella pratica
photo credit: https://www.flickr.com/photos/jurvetson/489257240/

46.
source code
repository
CI server
production
image
commit
test image
dev box
checkout
provision
provision run tests

47.
$ git init git-cookbook
$ cd git-cookbook

48.
name "git"
version "0.1.0"
git-cookbook/metadata.rb

49.
Test Kitchen

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

51.
---
driver:
name: vagrant
provisioner:
name: chef_solo
platforms:
- name: ubuntu-14.04
suites:
- name: default
run_list:
- recipe[git::default]
git-cookbook/.kitchen.yml

52.
git-cookbook/test/integration/server/serverspec/git_spec.rb
require 'serverspec'
set :backend, :exec
describe package('git') do
it { should be_installed }
end

53.
$ kitchen test

54.
======================================
Recipe Compile Error
========================================
Chef::Exceptions::RecipeNotFound
--------------------------------
could not find recipe default for cookbook git
>>>>>> Converge failed on instance <default-ubuntu-
1404>.

55.
include_recipe "apt"
package "git"
git-cookbook/recipes/default.rb

56.
name "git"
version "0.1.0"
depends "apt"
git-cookbook/metadata.rb

57.
git-cookbook/Berksfile
source "https://api.berkshelf.com"
metadata

58.
$ kitchen test

59.
Package "git"
should be installed
Finished in 0.21441 seconds (files took 0.36317
seconds to load)
1 example, 0 failures
Finished verifying <default-ubuntu-1404> (0m33.
52s).
-----> Kitchen is finished. (1m31.77s)

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

61.
...
"builders": [{
packer.json - 2
"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": "git"
}]
...

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

63.
source 'https://api.berkshelf.com'
cookbook 'git', path: './git-cookbook'
Berksfile

64.
$ berks vendor

65.
$ packer build
-var 'aws_access_key=YOUR ACCESS KEY'
-var 'aws_secret_key=YOUR SECRET KEY'
packer.json

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

67.
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Description" : "Git box",
"Parameters" : {
"AmiId" : {
"Type" : "String"
}
},
...
cloudformation.json - 1

68.
...
"Resources" : {
cloudformation.json - 2
"Instance" : {
"Type" : "AWS::EC2::Instance",
"Properties" : {
"ImageId" : { "Ref" : "AmiId" },
"KeyName" : "git-box-key",
"InstanceType" : "t2.micro"
}
}
}
}

69.
$ aws cloudformation create-stack
--stack-name git-box
--region eu-west-1
--template-body file://./cloudformation.json
--parameters ParameterKey=AmiId,
ParameterValue=ami-ac3199db

70.
{
"StackId": "arn:aws:cloudformation:eu-west-
1:422553113847:stack/git-box/978445e0-5f78-11e4-
95a6-507bb00bdca0"
}

71.
risorse

72.
https://github.com/filippo-liverani/test-driven-infrastructure

73.
grazie!