Enhancing Ansible Development with SOLID Principles

Discover how the fundamental principles of SOLID—Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—can significantly elevate your Ansible role and playbook development. Join us for a session that delves into the practical application of SOLID principles within the realm of Ansible content creation.

Through insightful examples drawn from real-world experiences, this presentation will illuminate the precise moments and methods for applying SOLID principles to enhance Ansible content. Attendees will glean actionable strategies for efficiently refining their Ansible content by applying these principles.

Geared towards both seasoned Ansible practitioners and newcomers, this session will feature accessible, yet impactful examples that transcend expertise levels. Whether you're seeking quick ways to improve your Ansible content or aiming to optimize your development workflow, this presentation promises practical insights and actionable takeaways.

Target Audience: Individuals interested in optimizing their Ansible content development process, whether they possess familiarity or are new to Ansible. The presentation will offer generic examples that cater to a diverse audience, requiring no expert-level knowledge of Ansible.

Transcript

1. 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
2. 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.
3. Why? SOLID principles SOLID principles for Ansible content with examples References Outline
4. To create more Ansible content that is understandable, readable, testable Ansible content that easy to change that many developers can collaboratively work on. Why?
5. 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
6. DEMO
7. Ansible role should do one thing and have only a single reason to change S
8. Ansible role should be open for extension and closed to modification O
9. One should be able to reuse Ansible role task files, where it makes sense L
10. Many specific Ansible roles are better than one role that does everything I
11. Ansible role should separate installation and configuration tasks D
12. 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."
13. 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
14. 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