I would like to know how other people are managing the deployment of Pingfederate through different environments.
We will need to develop some plugins for it and we are also creating templates etc. the current train of thought that is being pushed is that we submit the directory structure to SVN (because that's what we have) and then use Octopus to push any changes out through the environments (localDev -> devTest -> pre-prod -> prod). All of the above environments are single servers except prod which is load balanced.
I was looking at the config utility and then the admin API but my understanding here is that this is meant to be a server to server approach and we will need to take from SVN and push to devTest. It seems to me that we are being asked to apply source code approach to an installed system that may or may not work well.
Who else is working with PingFederate and what strategies are you using to deploy and control across environments? It seems to me that a lot of work has been put into the admin API for this and we are trying to re-invent the process.
What issues are we facing if we try it?
Is this a valid idea (SVN approach), we could have all relevant files under source control and we can push those into the admin API of the next environment?
Should we only be source controlling our plug in development and templates then use the Admin API and PingFederate admin page to actually admin the server?
There's a significant amount of work being done in the next iteration of PingFederate (version 9, to be released in late December 2017) to get the admin APIs to 100% coverage of use cases. I'm not sure if we're going to make it or not (we code freeze late November 2017), but it's going to be close. As the product sits today (version 8.4.3), there are a couple of key use cases that aren't covered by the admin API - the largest being WS-Trust configuration. On the flip side, we're not putting time and effort into ConfigCopy anymore either. The reasoning for this is because the API was really designed for enabling customers to develop mechanism by which their customers or partners could create the connections necessary via scripting against the API. As an example, think of any large SaaS provider that offers SAML integration. You log in to the admin portal, you add a certificate, set up an entity ID, export metadata, import metadata, etc. You don't deal with a human (unless you run into issues). With the admin API, you can do the same thing in PingFed. This is all background, just so you understand where Ping was positioning things at the time of this writing. So, where does that leave you...
In my opinion, the admin API is the way to go. This is the interface with a future in PingFed. Scripting against it isn't "simple", but, the fact that what comes out of it is text and is changeable, allows you to push things from environment to environment.
Now, having said that? If all you're doing is storing stuff in SVN for "backup" purposes... Go for it. Because here's the thing that I've found about this product in working with a number of our customers. YOU might have six (or however many) environments... But what kind of testing can you do? End to end testing includes your partners... And they might have two public environments (if you're lucky). How many "levels" of user datastores do you have access too? One? Two? So, really, what are you going to do with the your other four (or whatever) environments? "Oh, good - it deployed without an error"... Because that's all that you likely validate.
Have a conversation with your account's assigned architect. It is their job to help present you with choices, and help tailor those choices to your business' needs. If you don't know who that is, as your salesman to get your architect in touch with you.