As an existing customer, we haven't reached the point of considering doing IaC with ProGet ... yet. However, since it was brought up I do agree it would be helpful. Eventually we will likely make use of the existing APIs that are available. Such as the security apis, feed apis, and asset apis. Hopefully those are helpful to you @mikael.
The comment made about trying to rollback a feed that had been deleted and the original artifacts not being restored is true. However, that point is mostly irrelevant because the same exact situation occurs if one deletes the feed from the UI. One benefit of IaC in a situation like that is one of prevention. By utilizing IaC, we can engage an additional layer of review in configuration changes to tools such as ProGet. A review that is performed outside of ProGet at a textual level and informative of what is changing. While trusted administrators would be ultimately responsible, we are still human and make mistakes. IaC is a helper in reducing those mistakes and helpful in sharing knowledge of how things are configured.
To the point of IaC changes of permissions/users being more painful than the UI, that is entirely dependent upon the tool involved. We almost (again, human and making improvements) exclusively use IaC to apply permissions in our cloud resources. It works wonderfully and gives us clear indication of the config. Another benefit is we can give others outside of the admin side the ability to recommend actual changes to the permissions if need be. Responsible administrators can then review and potentially approve it or reject it with reasons. It provides a sense of shared ability within separate but closely operating teams. It also gives them easy, heavily reduced risk, read only access to the configuration.
Additionally, IaC helps from an auditing perspective immensely. The UI can be locked down to only a couple of emergency use administrators. Configuration changes being made soley via IaC gives a clear history, via git commit logs, of who made the change, what the change was and when it was implemented. While this can be done by streaming logs from tools such as ProGet to destinations like Splunk, it is incredibly useful to have that in the git history as well for teams to reference.
Admittedly these benefits are of most use to organizations with specific controls that must be adhered to. Either external regulatory requirements or by internal business security control decisions. Other organizations would not benefit from IaC of this nature.
I recognize and respect that there are no plans to do IaC of ProGet. That's a business and customer driven decision. However, it is hoped this adds positively to any other discussion of IaC configuration of ProGet.
