Grazie al fatto che molti dei valori e dei principi del movimento DevOps sono in comune con quelli di Extreme Programming, negli ultimi siamo riusciti ad applicare anche molte dellle pratiche in un contesto più ampio di quello nel quale erano state concepite. In questa sessione mi piacerebbe condividere il percorso che ho seguito per sviluppare una nuova infrastruttura in TDD e per arrivare ad un processo automatico in grado di deployare in produzione tutti i cambiamenti con un click.

1. TDD e Continuous Delivery
sull’infrastruttura
@filippo

2. Filippo Liverani
@filippo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43. immutable servers

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

44. approccio tradizionale
cambiamenti e disallineamenti -
>
snowflake server

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

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

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

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

50. $ git init git-cookbook
$ cd git-cookbook

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

52. Test Kitchen

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

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

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

57. $ kitchen test

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

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

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

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

62. $ kitchen test

63. 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)

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

66. ...
"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"
}]
...

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

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

69. $ berks vendor

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

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

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

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

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

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

77. risorse

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

82. grazie!