active-directory - 推荐本地 LDAP 存储进行开发

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




9年前关闭。




我们的项目使用 LDAP 存储库来存储用户。在生产中，这将是 Active Directory。对于开发，我们似乎有两种选择:

安装每个人都使用的 AD LDS 实例

在每台开发人员机器上安装 AD LDS 实例

我们试图让“F5”体验尽可能轻巧，所以安装东西或依赖中央广告商店不是我最喜欢的想法。

还有其他 LDAP 服务器，例如 Open LDAP。我希望可能有一个简单地与 XML 文件对话的 LDAP 服务器。这将允许我们将 XML 文件存储在源代码管理中，并拥有一些快速且有效的东西。我们的夜间构建仍将使用 AD 来找出任何差异，但希望是因为我们使用的是 LDAP，所以它应该可以正常工作。

您能否推荐一个适用于零配置无共享开发的 LDAP 实现？

Answer 1

我将 ADAM 然后 LDS 用于相当大规模的站点(多个 DC，数百万委托(delegate)人，~1000 auth/profile-get TPS)。

在开发过程中，我们运行了一个类似 DB 的工程环境，涉及到了两个提议的选项:

生产 - 分布式，稳定，发布拥有，发布部署，仅生产客户。

测试 - 分布式、稳定、测试拥有、测试部署、与生产类似的硬件。

集成 - 共享、 volatile 、测试拥有、测试部署、与生产类似的硬件，根据周期需求构建。

开发 - 共享、易变、测试拥有、开发部署。每周通过变更脚本汇总进行重建。

私有(private) - 个人，非常不稳定，私有(private)拥有，私有(private)部署。使用 checkin 的更改脚本按需构建。

我们严重依赖脚本在环境之间部署、迁移模式和示例数据。有时编写脚本以推广到共享开发有点像 PITA，但它确实迫使我们在我们周期的早期就进入模式和测试数据生成的源代码控制心态。

虽然这在 v1 中是相当大的开销，但在后续版本中，它使实时系统的升级和修补变得非常自然。

集成盒的角色在开发周期中随时间而变化，在周期结束时携带模式的当前版本或 future 版本。

可能会瓦解其中一些角色——取决于工程水平、集成要求和犯错的后果。让我们的系统脱机的成本可能高达数百万 - 严格是值得的。