Automation CI class - creating child class for different technologies

[lucaslopesm]

Hello guys! Just a quick question and second opinions on this. 

We have a requirement in our company to register InfraCode and other remediation automations as a CI per se, as it has versions and relationship to other CI and changes in those have production impacts and risks.

We are thinking about creating a child class (extended from Automation CI) per technology, such as Ansible/AWX automation, N8N automation and etc. 

Would that be a good move? Or would it be wise to just use Automation CI directly?

[Mark Manders · Accepted solution]

What's the reason for creating a Child class? Is it just so you can make a distinction? 

You could consider checking the fields available if you can store the technology part in the OOB table. Any reporting/filtering can then be done on that field.

It also depends on the number of automations you have and if there is any difference in how they are handled in logic/relations/etc. 

The golden rule with the CMDB (especially after introduction of CSDM) is to always try to use OOB tables and only create your own if the use case does not allow for the use of an OOB one. 

[lucaslopesm]

The only reason would be to store specific automation data, like gitlab directory for ansible/awx automation. But I guess that would be irrelevant for now and agree with your approach. Thanks for the heads up.