FOSDEM, the Free and Open Source Software Developers' European Meeting, took place this weekend in Brussels, Belgium, with over 4000 participants. This year the conference had over 40 tracks, both official and developer rooms organized by different communities, dedicated to diverse subjects such as Ruby, virtualization or config management.

What follows is an excerpt of some of the talks at the config management developer room.

How to have a constructive conversation about awful infrastructure code

Ryan Coleman, product manager at Puppet Labs, discussed Puppet best practices and common errors dealing with Puppet modules.

Ryan recommended using small, discrete modules. There are organizations that create a monolithic Puppet module with the whole configuration in it, but having discrete modules provides advantages for reuse, easier understanding and simplification of the overall codebase.

When creating modules, it should be considered the interface that is presented to the module users, which Puppet classes are intended to be used directly and which ones are considered private. Because Puppet does not have the concept of private classes, this distinction is meant to be explained in the module documentation. The interface does not need to, and should not, expose all possible options for the underlying system being configured, just the ones that make sense. Ryan also recommended using the parameters pattern, to make cleaner code and explicitly show default values. Use standardized names for classes and parameters, and one class per file, as a convention.

The Puppet language style guide provides naming, style and formatting conventions. Following them allows consistent and therefore easier to understand modules, while avoiding common issues. Puppet Labs is currently updating the style guide to a new v2, and also provides a module documentation template and examples.

Compatibility between modules and operating systems and versions can be listed in the new module descriptor metadata.json introduced in recent versions of Puppet, and are a valuable resource for users to choose a module that is supported in particular versions of Puppet and operation system.

There are tools that can help with style and documentation. Puppet-lint can be used to automatically check compliance with the style guide and even fix the sources. Puppet-strings is a new tool that will extract inline documentation from the Puppet classes much like the Javadoc tool in Java.

Better Devops through thievery. Effective practices for infrastructure as code

Adrien Thebo, software engineer at Puppet Labs, focused his talk on improving the infrastructure as code delivery, by using best practices learned over the years in the development field.

Developers need guardrails to be safe and prevent errors, and that is one of the tenants of configuration management. It helps alleviate the human mistakes by removing the human element, by avoiding manual changes in live servers, synchronizing different environments, such as QA and production, and validating changes before they go live.

Adrien referred to Dev flavored Ops, which steal all the best practices from development to apply them to infrastructure code. For instance, using version control systems, commit messages, and using version control as a way to review changes.

Test driven infrastructure can be also achieved, the same way as test driven development. There are many ways of validating changes, such as waiting for angry users or manual checking, but it is better to have automated tests.

Testing is not just for developers.

Another interesting concept mentioned was test driven monitoring, where RSpec tests can generate Nagios plugin output format.

The Puppet ecosystem provides several tools to test Puppet modules. rspec-puppet will run unit tests against modules, and serverspec allows to programmatically check that servers are configured correctly, via SSH, WinRM, Docker API,... Beaker is a cloud enabled acceptance testing tool, that allows running tests against virtual machines, cloud or Docker containers.

Version control and testing are not enough, Continuous Integration is still necessary to ensure that ongoing development does not break the tests and there are not regressions.