code review and automated testing for puppet code

Code review and automated testing for Puppet code

Maxim BurgerhoutSolution Architect Linux and Open Source

Inter Access

Puppetcamp Amsterdam 2014

Agenda

● Who? Me?● Code review for Puppet● Gerrit, a code review tool● Jenkins, a continuous integration tool● Puppet workflow with code review and testing● The downsides of Gerrit● A live demo

Who? Me?

● Maxim Burgerhout

● Solution Architect Linux and Open Source

● Linux migrations are a big part of my job

● Puppet plays an important role in that

● Open source fanatic!

Place of work

● Inter Access● Recently acquired by SLTN● Together we are a fairly large IT

services provider and software reseller● We focus on implementations of cloud

platforms, Linux, and Puppet

Code review for Puppet

What is code review?

“Systematic examination of computer source code, intended to find and fix mistakes overlooked in the development phase.” -- Wikipedia

Why do code review?● Two people see (and know) more

than one● Increase skill of both people involved● Enforce coding standards● Keep bad commits out of your repo!● Write better code*

Ok, what is 'better' code?● In the Puppet domain, most likely:

– Code that's not WET

– Code that follows the style guide

– Code without deprecated syntax

– Code that's portable

– Code without data mixed in

So, how to review code● Previous points are key in reviewing● Also, apply site specific knowledge

to code● And make review teams combining

experienced and less experienced people

Things to look for

Puppet DSL pitfalls● For example: the fact that Facter

always returns strings

if $::is_virtual { => if str2bool($::is_virtual) {

do_something => do_something

} => }

What more to look for● Syntactically correct, but not

optimal● For example: no default in case

statements or selectors

Default case examplecase $::timezone {

'CET': { do_something }

}

case $::timezone {

'CET': { do_something }

default: { fail('unknown part of the world') }

}

One more: Overreaching● Modules should aim to manage one

thing, and not try to do everything● This is probably not what you wantclass loganalyzer {

package { 'mysqlserver': ensure => installed, }

.. goes on to manage entire database setup ..

}

Gerrit

Some background● Code review and discussion

platform● Started in 2008 as a fork of Rietveld● Gerrit is used in many large open

source projects today● Focused towards git

Gerrit & git● Gerrit is also hosts your git repositories● Can set granular ACL's per repository● Push to Gerrit with Git and Gerrit starts the

review process automatically● Made a mistake? Gerrit allows you to

update an already submitted patch● Problem but already merged? Revert!

Gerrit == floodgates● Submitted patches kept in purgatory upon

review● Patch needs a code review and a set of

successful tests to be merged● Code review is voted on between -2 and +2,

tests are voted on between -1 and +1● A failed test (-1) or negative review (-2) blocks

merging a patch completely

Jenkins

Some background● Started in 2011 as a fork of Hudson● Used as a CI tool at lots of sites● Can test code, time based or event

triggered (i.e. upon commit)● Can execute just about every test

you can think of

Jenkins: Testing Puppet● Per repository in Gerrit, we create a 'job'

in Jenkins● Job defines where the code comes from,

and which tests to run on it● Jenkins gets triggered to build upon

every submitted patch in Gerrit● When done, Jenkins votes -1 or +1

Puppet tests in Jenkins● Can be simple

– Syntax checks for .pp files: for file in $(find name '*.pp'); do puppet parser validate ${file} puppetlint logformat “..” ${file} done

– Syntax checks for .erb files:for file in $(fine name '*.erb); do erb P x T '' ${file} | ruby cdone

Puppet tests in Jenkins● Or more complex

– Smoke tests● Execute your module's tests/init.pp with --noop, make

sure it doesn't blow up

– rspec-puppet● Tests the logic of your module by mocking parameters

and facts● Very powerful. Highly recommended.

– Fire up Vagrant VM's from Jenkins● Cool, but admittedly not something I do a lot

Workflow

Engineer

Gerrit

Submits review request to Gerrit

Engineer

Peer Review

Jenkins Tests

Gerrit


Creates review and triggers Jenkins

Engineer

Peer Review

Jenkins Tests

Gerrit



JudgementResults

Engineer

Peer Review

Jenkins Tests

Gerrit



JudgementResults

Change is merged

Improvement needed

Ack

Nack

Engineer

Peer Review

Jenkins Tests

Gerrit



JudgementResults

Change is merged

Improvement needed

Ack

Nack

Cycle restarts, engineers pulls, commits, pushes for review

Engineer

Peer Review

Jenkins Tests

Gerrit


JudgementResults

Change is merged

Improvement needed

Ack

Nack

Cycle restarts, engineers pulls, commits, pushes for review


The downsides

Nothing is perfect● Looking for a reviewer can be

annoying● Reviewing everything slows things

down● Gerrit implements some functionality

through plugins; not a pleasant experience

Demo● Want to show you the interaction

between two users and Gerrit– An engineer writing code

– An engineer reviewing that code

● Quick walkthrough through the Gerrit interface

Wrap up● Gerrit and Jenkins are great to work

with and helped us a lot● Solid building blocks for CI and CD● Jenkins and Gerrit can be used to

go full continuous deployment● How far you take it? It's up to you!

You made it!

● You're still alive. So am I! Yay!● Questions?

README● More information here:

– http://code.google.com/p/gerrit/

– http://jenkins-ci.org/

– http://rspec-puppet.com/

– http://git-scm.com/

– http://bit.ly/pc_cr_2014 (link to study on code review)

– Thanks to Walter Heck for the inspiration for the bad code examples

http://code.google.com/p/gerrit/

http://jenkins-ci.org/

http://rspec-puppet.com/

http://git-scm.com/

http://bit.ly/pc_cr_2014

code review and automated testing for puppet code

Technology

review request

code review tool jenkins

background code review

review patch

review teams

negative review

review process

puppet gerrit