使用LDAP进行问题跟踪/ SCM

Question

我当前的项目涉及使用LDAP（Active Directory），我正在为我的所有项目使用问题跟踪，因此我想到了将两者结合起来的想法。为了满足StackOverflow的要求，我会尝试将其作为问题来制定，但我承认，这更多的是关于获得一些意见，请原谅我:)：

我认为问题跟踪和SCM（软件配置管理）通常是LDAP的一个很好的应用程序，原因如下：

• 易于集成到现有基础架构中（无需额外的用户管理）
• 项目/问题等的细粒度访问控制。
• 即用型分层，面向属性的存储（通常是SCM /问题跟踪器所需）
• 带有几乎所有语言/技术绑定的标准API
• 搜索/索引，大多数LDAP解决方案中已存在的备份/复制功能
• 可扩展模式已经成为LDAP技术的一部分（可以很容易地向问题/项目等添加属性。）

所以我的问题是：

• 您是否了解为问题跟踪转换定义（标准）架构的任何现有尝试。 SCM（即问题，项目，版本，发布，修订等的类定义）
• LDAP通常管理相对缓慢变化的数据。当前的实现（OpenLDAP，ActiveDirectory）如何处理通常经常变化的数据（主要是在性能和​​数据量方面）？
• 你能想到这种解决方案还有其他缺点吗？

当然

• 谁想尝试开始这样的项目:) ...

Answer 1

OP准备：

  

问题不在于使用具有LDAP身份验证的现有问题跟踪器（redmine可以执行此操作），
  但关于存储门票/问题等。直接在LDAP树中......
  目前，每个问题跟踪器都有自己的API来访问数据，所有可通过LDAP访问的数据都可以使编写工具（例如集成到IDE等）变得更加容易

答案很简单。

别。

LDAP是 不 （重复，而不是）为此而做的，SCM或问题跟踪器还有很多，而不仅仅是一堆分层数据。< / p>

• SCM必须提出一种方法来有效地存储/引用增量，整个树，分支，标签。
• 一个问题跟踪器是关于一个项目和其他几个项目之间的多个关系（几个父项/子项，相关的，重复的......），还必须以某种方式管理代码的紧密引用（或者更确切地说，变更集，集合）版本修改）

虽然通过添加所有许多新的objectClass类型是正确的，但最终可能会得到类似的结构，你基本上会采用 Lightweight Directory（即仅针对只读进行了优化）并将其转换为 huge referential（具有大量读/写操作和复杂数据结构）。

如果您正在寻找一个统一的API，那么一个通用的API（不只是针对SCM或错误跟踪）是 OSLC (Open Services for Lifecycle Collaboration) ，这是一个目前用于{{3}的开源协议} Change Management。