see egi-foundation.github.io/ansible-style-guide

This repository contains style guide for EGI's use of Ansible. It will

• Generate styling 🏄🏾 Ansible roles, all dressed up and ready to roll 👗 using a sweet skeleton
• Pass an expert eye over your code, applying the Ansible Fashion Police 👮‍♂️ compliance profile, to help you stick with the style guide as you code.

See the quickstart if you're just super keen 😍.

See EGI's roles on Galaxy. You can find guides on:

• Documenting roles
• Ansible syntax in roles
• Testing role scenarios, testing tools
• Role release and publication
• Collaborating with code

EGI is responsible for several internal services either directly, or through collaboration with partners. Ansible roles are a simple, powerful way to express the desired state and composition of these services. As with many languages and tools, a certain amount of leeway is possible when it comes to the style of implementation. When working on roles, it's a good idea to have common nomenclature, follow common styles and adopt common practice regarding documentation, community engagement, maintenance, support, etc. With this repository, we express the consensus view of the EGI Operations team about how Ansible roles should be developed. It's raisons d'etre are:

• Improve peer review: discuss issues of style out-of-band so that when it comes to peer review of pull requests, there is an unambiguous reference. This will help speed up peer review, and make it more attractive for repository maintainers to actually conduct such peer review. Further it will encourage contributors, providing better transparency in the process, and allowing discussion around the style guide itself.

• Improve reliability, test coverage: Ansible roles can and should be tested according to common profiles. Infrastructure tests can be expressed in plain language, easy to read, and easy to audit. Test coverage and profiles can be harmonised across roles so that they can be applied modularly with confidence.

• Promote re-use: Roles can only be re-used if they are reliable and deliver what they claim to. If, through the points above, we can improve the re-use of these roles, we can avoid dispersion of effort and even better, start to give proper recognition to the authors and peer reviewers of roles.

All in all, we have a more robust infrastructure, less toil and better collaboration.

As a community of practice, we welcome contributions which work smoother and help us be more inclusive. If you see something you think needs to change, or is missing, please open a pull request. If you could read the Contributor's Guide first, that might help.

If you have feedback or would like to engage on issues related to this, start a discussion on the EGI Community Forum

EGI believes in a healthy community and welcomes diverse points of view. Contributors to and users of this repository are asked to refer to the Code of Conduct regarding any conflicts or events of abuse which may arise. The maintainers undertake to abide by the Code of Conduct in their dealings with each other and the community.