Discusses an XP approach to writing Ansible scripts: Start with a failing test and write code around it to make it pass. Write monitoring code, let it drive your Ansible code to have a functioning server. I use ServerSpec and Cucumber as the monitoring code. Broader subject is that Ansible code should be treated as regular application code - use TDD, SCM, CI and pairing to create a single delivery team consisting of devs and sysadmins as a delivery team.
2. THE PREMISE
• Ansible scripts should be treated with the
same rigour with which we treat application
code
• In the way they’re tested
• In the way they’re written
3. JAMES WHITE MANIFESTO
•There is one system, not a collection of systems.
• The desired state of the system should be a known
quantity.
• The "known quantity" must be machine parseable.
• The actual state of the system must self-correct to the
desired state.
• The entire system must be deployable using source
media and text files.
• The only authoritative source for the actual state of the
system is the system.
5. WHY ANSIBLE?
•Assures scalability
•Repeatable and measurable
•Assures environments for consistent
development testing
Do not improve manual processes
if you can automate them instead.
•Fail fast (offline!) and cycle quickly
•Time To Rebuild System < Time To Fix It
22. CUCUMBER
Feature: App deploys to a VM
Background:
Given I have a vm with ip "33.33.33.33"
When I provision users on it
Scenario: Adding users
Then I can log on to it as the "deploy" user
And I can log on to it as the "root" user
Scenario: Adding Linux dependencies
When I run the "webserver" ansible playbook
And I log on as "deploy", there is no "ruby"
But "gcc" is present
23. CUCUMBER
IMPLEMENTATION
Then(/^I can log on to it as the "(.*?)" user$/) do |user|
result = system "ssh #{user}@#{@ip} exit"
result.should be_true
end
When(/^I run the "(.*?)" ansible playbook$/) do |playbook|
command = %W(../devops/#{playbook}.yml -i webhosts)
result = system 'ansible-playbook', *command
result.should be_true
end
24. WHY BOTHER?
• ServerSpec is to Ansible as rSpec is to Ruby
• You do not want your Ansible code to be
used untested
25. SOURCE CONTROL
SCaaCC
• Ansible code is part of the delivered code
• Developers and SysAdmins share code
using git for modifications.
• HugOps can use master
• Others can use branching or forking
26. SOURCE CONTROL
• Run ServerSpec prior to committing code
• Commit
• CI will take care of the rest
• Integration tests
• Environment Promotion
28. XP PRACTICES
• SysAdmins are part of the development
team
• Participate in standups, part of a
story/task cards
• Participate in pairing sessions
• Empathise