We all want faster deployments – but how? Learn how to use Perforce to manage everything that goes into deployments, how to use Puppet to manage the state of nodes with Perforce, and how integrating Perforce and Puppet speeds up the adoption of DevOps practices.

1. #
Christoph Leithner, Founder at celix

2. #
• What is the starting Point of our Journey to
Continuous Delivery?
• Continuous Integration
– Source Code Checkout
– Static Code Analysis
– Automated Tests
– Compilation
– Packaging

3. #
• Database Structure
• Database Content
• Installable Software
– Libraries
– Executables
– OS Packages
– Installers
• Some Type of Deployment

4. #
Manual
Personal
Only a Guru understands the
system and is able to deploy it
Defined
Scripted
Scripts are available
to setup most of the
Components of our
System
There enough
Documentation so we do
not always have to ask the
Guru if we want to deploy
We use IT-Automation to
deploy and enforce our
Deployment – no manual
changes.
Defined Deployments are not
possible without IT-Automation,
Traceability and Discipline

5. #
• Not all Changes to Dependencies trigger a Build
• DEV-Database is populated with Snapshots
• DEV-Database Changes are not tracked
• Semi-automated DEV-Deployments cause Delays
• Only some aspects of the System are managed by
Continuous Integration – no full Stack Deployment
• Builds/Deployments are not reproducible

6. #

7. #
• Developer Code
• Deployment Code
• Configuration Data
• Database Structure
• Database Content
• Installable Software
• Documentation

8. #

9. #
module_name
manifests
files
templates
lib
spec
tests
Modulefile

10. #
puppet module install puppetlabs-apache --version 0.6.0
puppet module install puppetlabs-ntp --version 0.2.0
apache stdlib firewall ntp

11. #
forge
puppetlabs-apache
puppetlabs-stdlib
puppetlabs-firewall
puppetlabs-apache
puppetlabs-stdlib
puppetlabs-firewall

12. #
• Module Reuse is the fastest way of Automation
• But it is not as easy as it might seem to write a
reusable Puppet Module
• “We have this Module managing …, but I cannot
share it. It contains too many Site specific
Parameters”
• Separating Module Code from Configuration Data
is key for Module Reuse

13. #
• Puppet 3.0 integrates Hiera for Configuration Data
• Hiera defines a list of Backends
• Hiera defines a Lookup Hierarchy
:hierarchy
- “%{clientcert}”
- “%{environment}”
- “%{osfamily}”

14. #
apache stdlib firewall hiera

15. #
module_name
manifests
files
templates
lib
spec
tests
Modulefile
data

16. #

17. #
• DB Structure
– DB Dump
– DB Snapshot
– SQL Scripts
• Creating DB Structure with SQL Scripts
1. Create all Tables
2. Fill all Tables
3. Create/Enable all Relational Constraints, Triggers etc.

18. #
• DB Content Types
– System Data
– Configuration Data
– Business Object Data
• DB Content Tools
– SQL Insert Scripts
– Schema or Table Exports/Dumps
– Tool Specific Files (e.g. XML)

19. #
• DB Migration Tools
– OR Mappers – built into the Application
• Rails: Active Records
• Java: Flyway
– Evolutionary/Agile Database Tools
• dbdeploy
• DBmaestro

20. #
1_create.sql
2_fill.sql
3_enable.sql
create
tables
indexes
...
views
functions
procedures
fill
system
configuration
business_objects
migrate
changelist_A
changelist_B

21. #

22. #
• OS Packages
– Different for each Platform and Distribution
– Multiple Repositories required
– Packages and Metadata
• Installers
– Simplify complicated installations
– Same Installation on multiple Platforms
– Manual Installations not supported

23. #
• Puppet Package Resource:
package {‘apache2’:
ensure => present,
}
• Ensure Attribute Values
– present: Package is installed
– latest: Package is upgraded to the latest available
– ‘2.4.6’: specified Version of the Package is installed

24. #
• New Package Versions are available online
• Can we apply them automatically?
– Is the Package managed by Puppet?
– Is the Package a Dependency of a Package managed
by Puppet?
– Is there a Requirement for a particular Version of an
updated Package?
– Is there a Requirement for a particular Version of a
Dependency of an updated Package?

25. #
• We need to know which is the latest Version of a
Package in a certain Environment
• We need to create a local Repository and manage
all Changes to it.
• On Ubuntu we use aptly to manage our local
Repositories

26. Source: http://www.aptly.info/doc/overview/
#

27. #

28. #
• We check in the published Repository into
Perforce to get full Traceability
• We can use Perforce to propagate Changes
between Environments
• What do we use for Puppet ensure:
• latest: Puppet actively tries to upgrade
• present: Puppet trusts the Package Manger
• ´2.4.6´: if we need to pin an older Version
(apt::pin)

29. #
• We use a Perforce Stream to track the Work of an
Installer in particular Directory
• This way can use a Task Stream to track the work
of the Installer on each machine
• Currently we only use this Feature when we
automate deployments
• The same concept can be used to tack changes of
Directories on managed nodes

30. #
• Developer Code
• Deployment Code
• Configuration Data
• Database Structure
• Database Content
• Installable Software
• Documentation

31. #
• Full Traceability
• Code Reviews in Swarm for all Changes
• Ability to make consistent changes across all
Artifacts
• Revision Graph for Insights on a particular Artifact
• Easy Tracking of the Work of Installers

32. #
Christoph Leithner
c.leithner@celix.at