Pingfederate 的自动部署
Automated deployment for Pingfederate
我想知道其他人如何通过不同的环境管理 Pingfederate 的部署。
我们将需要为它开发一些插件，我们也在创建模板等。目前正在推动的思路是我们将目录结构提交给 SVN（因为这就是我们拥有的）然后使用Octopus 通过环境推送任何更改（localDev -> devTest -> pre-prod -> prod）。以上所有环境都是单服务器，除了 prod 是负载平衡的。
我查看了配置实用程序，然后查看了管理员 API，但我的理解是，这是一种服务器到服务器的方法，我们需要从 SVN 获取并推送到开发测试。在我看来，我们被要求将源代码方法应用于可能运行良好或可能运行不佳的已安装系统。
还有谁在使用 PingFederate？您使用什么策略来跨环境部署和控制？在我看来，管理员 API 已经为此投入了大量工作，我们正在尝试重新发明该流程。
如果我们尝试它会面临什么问题？
这是一个有效的想法吗（SVN 方法），我们可以将所有相关文件置于源代码控制之下，我们可以将它们推送到下一个环境的管理员 API 中吗？
我们是否应该只对我们的插件开发和模板进行源代码控制，然后使用 Admin API 和 PingFederate 管理页面来实际管理服务器？
PingFederate 的下一次迭代（第 9 版，将于 2017 年 12 月下旬发布）中有大量工作要做，以使管理员 API 100% 覆盖用例。我不确定我们是否会成功（我们在 2017 年 11 月下旬冻结代码），但它会很接近。由于产品今天（版本 8.4.3），有几个关键用例未被管理员涵盖 API - 最大的是 WS-Trust 配置。另一方面，我们也不再将时间和精力投入到 ConfigCopy 中。这样做的原因是因为 API 的真正设计目的是让客户能够开发一种机制，通过这种机制，他们的客户或合作伙伴可以通过针对 API 编写脚本来创建必要的连接。例如，考虑任何提供 SAML 集成的大型 SaaS 提供商。您登录到管理门户，添加证书，设置实体 ID，导出元数据，导入元数据等。您不需要与人打交道（除非您 运行 遇到问题）。使用管理员 API，您可以在 PingFed 中执行相同的操作。这些都是背景，只是为了让您了解 Ping 在撰写本文时将事物定位在何处。那么，那会让你去哪里......
在我看来，管理员API是正确的选择。这是 PingFed 未来的接口。针对它编写脚本不是 "simple"，但是，它产生的是文本并且是可变的，这一事实允许您将事物从一个环境推到另一个环境。
现在，说了这么多？如果您所做的只是为了 "backup" 目的而将内容存储在 SVN 中……去吧。因为这是我在与我们的许多客户合作时发现的有关该产品的事情。您可能有六个（或任意多个）环境……但是您可以进行哪种测试？端到端测试包括您的合作伙伴...他们 可能 有两个 public 环境（如果您幸运的话）。您也可以访问多少 "levels" 个用户数据存储？一？二？那么，实际上，您打算如何处理其他四个（或其他）环境？ "Oh, good - it deployed without an error"... 因为这就是您可能验证的全部内容。
与您帐户的指定架构师交谈。他们的工作是帮助您提供选择，并帮助根据您的业务需求定制这些选择。如果您不知道那是谁，请作为您的推销员让您的建筑师与您联系。
我想知道其他人如何通过不同的环境管理 Pingfederate 的部署。
我们将需要为它开发一些插件，我们也在创建模板等。目前正在推动的思路是我们将目录结构提交给 SVN（因为这就是我们拥有的）然后使用Octopus 通过环境推送任何更改（localDev -> devTest -> pre-prod -> prod）。以上所有环境都是单服务器，除了 prod 是负载平衡的。
我查看了配置实用程序，然后查看了管理员 API，但我的理解是，这是一种服务器到服务器的方法，我们需要从 SVN 获取并推送到开发测试。在我看来，我们被要求将源代码方法应用于可能运行良好或可能运行不佳的已安装系统。
还有谁在使用 PingFederate？您使用什么策略来跨环境部署和控制？在我看来，管理员 API 已经为此投入了大量工作，我们正在尝试重新发明该流程。
如果我们尝试它会面临什么问题？
这是一个有效的想法吗（SVN 方法），我们可以将所有相关文件置于源代码控制之下，我们可以将它们推送到下一个环境的管理员 API 中吗？
我们是否应该只对我们的插件开发和模板进行源代码控制，然后使用 Admin API 和 PingFederate 管理页面来实际管理服务器？
PingFederate 的下一次迭代（第 9 版，将于 2017 年 12 月下旬发布）中有大量工作要做，以使管理员 API 100% 覆盖用例。我不确定我们是否会成功（我们在 2017 年 11 月下旬冻结代码），但它会很接近。由于产品今天（版本 8.4.3），有几个关键用例未被管理员涵盖 API - 最大的是 WS-Trust 配置。另一方面，我们也不再将时间和精力投入到 ConfigCopy 中。这样做的原因是因为 API 的真正设计目的是让客户能够开发一种机制，通过这种机制，他们的客户或合作伙伴可以通过针对 API 编写脚本来创建必要的连接。例如，考虑任何提供 SAML 集成的大型 SaaS 提供商。您登录到管理门户，添加证书，设置实体 ID，导出元数据，导入元数据等。您不需要与人打交道（除非您 运行 遇到问题）。使用管理员 API，您可以在 PingFed 中执行相同的操作。这些都是背景，只是为了让您了解 Ping 在撰写本文时将事物定位在何处。那么，那会让你去哪里......
在我看来，管理员API是正确的选择。这是 PingFed 未来的接口。针对它编写脚本不是 "simple"，但是，它产生的是文本并且是可变的，这一事实允许您将事物从一个环境推到另一个环境。
现在，说了这么多？如果您所做的只是为了 "backup" 目的而将内容存储在 SVN 中……去吧。因为这是我在与我们的许多客户合作时发现的有关该产品的事情。您可能有六个（或任意多个）环境……但是您可以进行哪种测试？端到端测试包括您的合作伙伴...他们 可能 有两个 public 环境（如果您幸运的话）。您也可以访问多少 "levels" 个用户数据存储？一？二？那么，实际上，您打算如何处理其他四个（或其他）环境？ "Oh, good - it deployed without an error"... 因为这就是您可能验证的全部内容。
与您帐户的指定架构师交谈。他们的工作是帮助您提供选择，并帮助根据您的业务需求定制这些选择。如果您不知道那是谁，请作为您的推销员让您的建筑师与您联系。