I just have watched a video for the first time, and I have noticed, that the best practices mentioned by the presenter and the best practices on the Ansible website differ a lot from the content of the course book.
The most noticeable detail is that in most of the examples and exercises in the training material, FCDN is almost never used. Further the video recommends putting "when", "register" and the like before the actual module, while in the course guide this is consitently not the case.
Of course, I don't expect an immediate fix, but I suggest to incorporate the best practices in the training material (everywhere).
I am very happy, that I did not neglect the video this time, as I got many useful tips (unfortunately more than from the course guide)!
So I would hope the course guide is using the FQDN everywhere now. I'm guessing there are a few spots it might be off still, if that is the case, please submit a support ticket from RHLS and it can be addressed with the next course update.
In terms of differences between videos, course guides, and Ansible upstream ...
https://redhat-cop.github.io/automation-good-practices/
https://github.com/redhat-cop/automation-good-practices
Red Hat does maintain some best practices for Ansible, but those aren't always updated. I've given the GithubIO page as well as the source and you can see that some items haven't changed in years, and some are a few months old.
The videos are always great as you have an instructor that can add to content that isn't in the book and our live courses are even better as I teach a ton of Ansible courses and I'm constantly updating my demos and providing new guidance based on questions and scenarios that participants pose during the delivery.
Bottom line, not everything can be covered in a self-paced course (especially reading a course guide) and Best Practices are guidelines that people come up with. One of the more important things I stress is in the DO374 is coming up with "Best Practices" and a team working agreement for your office / team / whatever where you all agree to developing Ansible playbooks in a certain way (where to store variables, where to put play and task directives, where to place handlers in the playbook, where to put module/task options) and stick with it. Everyone is going to have preferences, but if you can pick something the entire team can agree on, do that.
I personally work with teams and I like the conditions at the bottom of a module for a task so the (when, register, loop) are all at the bottom. I also insist as well as the rest of the team to always have state (even though it has a default and can be left out) that way people know what is intended and future changes to the module don't break your playbook.
@AndreasF Thank you for your feedback - I will document this feedback and forward this to the concerned team for consideration. Thank you for your time and feedback !
@jmeegan_rhls for visibility.
So I would hope the course guide is using the FQDN everywhere now. I'm guessing there are a few spots it might be off still, if that is the case, please submit a support ticket from RHLS and it can be addressed with the next course update.
In terms of differences between videos, course guides, and Ansible upstream ...
https://redhat-cop.github.io/automation-good-practices/
https://github.com/redhat-cop/automation-good-practices
Red Hat does maintain some best practices for Ansible, but those aren't always updated. I've given the GithubIO page as well as the source and you can see that some items haven't changed in years, and some are a few months old.
The videos are always great as you have an instructor that can add to content that isn't in the book and our live courses are even better as I teach a ton of Ansible courses and I'm constantly updating my demos and providing new guidance based on questions and scenarios that participants pose during the delivery.
Bottom line, not everything can be covered in a self-paced course (especially reading a course guide) and Best Practices are guidelines that people come up with. One of the more important things I stress is in the DO374 is coming up with "Best Practices" and a team working agreement for your office / team / whatever where you all agree to developing Ansible playbooks in a certain way (where to store variables, where to put play and task directives, where to place handlers in the playbook, where to put module/task options) and stick with it. Everyone is going to have preferences, but if you can pick something the entire team can agree on, do that.
I personally work with teams and I like the conditions at the bottom of a module for a task so the (when, register, loop) are all at the bottom. I also insist as well as the rest of the team to always have state (even though it has a default and can be left out) that way people know what is intended and future changes to the module don't break your playbook.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.