Enhancing Ansible Development with SOLID Principles Kirill Satarin Senior Software Engineer, Red Hat June 2024 Enhancing Ansible Development with SOLID Principles © 2024 by Kirill Satarin is licensed under CC BY-SA 4.0

Disclaimer of Warranties and Limitation of Liability. a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.

Why? SOLID principles SOLID principles for Ansible content with examples References Outline

To create more Ansible content that is understandable, readable, testable Ansible content that easy to change that many developers can collaboratively work on. Why?

SOLID principles The Single Responsibility Principle Class should do one thing and should have only a single reason to change The Open-Closed Principle Class should be open for extension and closed to modification The Liskov Substitution Principle Subclasses should be substitutable for their base classes. The Interface Segregation Principle Many client-specific interfaces are better than one general-purpose interface The Dependency Inversion Principle Class should depend upon interfaces or abstract classes instead of concrete classes and functions

DEMO

Ansible role should do one thing and have only a single reason to change S

Ansible role should be open for extension and closed to modification O

One should be able to reuse Ansible role task files, where it makes sense L

Many specific Ansible roles are better than one role that does everything I

Ansible role should separate installation and configuration tasks D

SOLID principles for Ansible content The Single Responsibility Principle Ansible role should do one thing and have only a single reason to change The Open-Closed Principle Ansible role should be open for extension and closed to modification The ‘Liskov Substitution’ Principle One should be able to reuse Ansible role task files, where it makes sense The Interface Segregation Principle Many specific Ansible roles are better than one role that does everything The Dependency Inversion Principle Ansible role should separate installation and configuration tasks "To create understandable, readable, and testable code that many developers can collaboratively work on."

GitHub repo with all code examples https://bit.ly/solid-ansible https://en.wikipedia.org/wiki/SOLID https://bit.ly/solid-ansible Enhancing Ansible Development with SOLID Principles © 2024 by Kirill Satarin is licensed under CC BY-SA 4.0 References

Follow me on GitHub @kksat Connect with me on LinkedIn in/ksatarin Enhancing Ansible Development with SOLID Principles © 2024 by Kirill Satarin is licensed under CC BY-SA 4.0 Contacts