ABN AMRO是荷兰的一家银行，历史悠久，可追溯到 19 世纪中叶。。在过去的 25 年中，我们发展了深受客户重视的数字渠道，并已成为主导渠道。2015 年，欧盟为欧洲银行通过PSD2 指令通过 API 向第三方开放支票账户信息设定了最低要求。ABN AMRO 通过建立更广泛的企业对企业 API 渠道，远远超出了这些要求。我们还设立了一个外部开发者门户，以促进第三方利用我们的金融服务。当然，这一切都需要一个组织良好的内部 IT 组织来支持。
我的开发服务部门的职责是通过持续集成/持续交付 (CI/CD) 设施为开发人员提供便利，这些设施必须满足开发人员要求、监管要求和非开发人员利益相关者的要求。在实践中，这意味着协助开发工具并支持许多特定平台以创建可追溯性和透明度以及相关报告。
下面的文章解释了一些起点以及我们如何设想在企业范围内支持 DevOps。
文章内容：
集中组织和基于产品
10 多年前，在合并期间，我被要求查看组织的支持和开发工具。ABN AMRO 那时仍然是一个以项目为导向的组织，其中 Dev 和 Ops 组是分开的。根据以往的经验，我们已经很清楚，主要的工具，包括版本控制、源代码质量控制、管道支持和工件管理，都应该集中管理。这主要是为了满足非开发人员的要求，例如可追溯性和集中报告的能力。至少应遵守最低限度的统一性。另一个重要的选择是产品定位。过去在又一次重组后面临孤立的源代码存储库，我很清楚按照组织结构组织开发数据并不是一个好的选择。由于正在开发的东西的生命周期通常比开发者长得多，因此选择了基于产品的方法。
快进到今天，该组织正在（正在）转变为 DevOps 结构，大约有 400 个开发团队负责开发和运营。10 年前只有少数人的工具支持已经发展成为开发服务，有 200 多人支持更多。这些包括：
- 软件开发标准和指南
- 所有与开发相关的工具
- 内部和外部开发人员门户
- 基于设计模式的代码初始化
- 管道的标准构建块和常用技术的模板管道
- CI/CD 辅导
- 为许多供应商特定平台提供托管服务并支持技术行会
- 作为开发工具的一部分，从一开始就使用了 Landscape Nexus Repository Manager <link>，随后是 Nexus Lifecycle。
IT4IT 数据模型
缺少源代码、开发数据、CI/CD 数据和服务管理数据之间的结构关系，随着我们以产品为导向，管理人员围绕开发数据发展，显示使用哪些工具开发了哪些应用程序。这包括 Bitbucket、Jenkins、SonarQube、Fortify、Nexus Lifecycle 和 Nexus Repository Manager。在服务管理方面，开发了一个应用程序组合来支持常规服务管理流程以及监管和企业架构流程。
我还目睹了一种反复出现的模式，即主要的生命周期管理和基础设施项目查询应用程序的详细信息。时不时地，开发组织不得不将技术细节收集到大型 Excel 表格中，以满足那些重大项目或计划的数据需求。在项目结束时，信息丢失了，在下一个项目中重复了这个练习。我们的应用工程数据根本无法以结构化的形式提供，开发团队以外的利益相关者也无法访问。
与此同时，市场上出现了IT4IT倡议。这个概念强化了整个 IT 价值链中的数据应该被更好地定义以支持任何规模化方法的想法，无论是大规模敏捷、大规模 DevOps 还是大规模数字化转型。敏捷和 DevOps 转型中的一个风险是管理层无法了解正在发生的事情。
工具入职
CI/CD 环境最初包括 Bitbucket、Jenkins、SonarQube、Nexus Repository Manager，最重要的是我们管理所有相关访问组的中央 LDAP。需要技术问题来初始化对 Nexus 存储库管理器中存储库内的适当存储库和路径的访问。
随着 Fortify 和 Nexus Lifecycle 的引入，很明显需要在另一个级别上进行引导。虽然我们的应用程序组合假设应用程序是一个完整的解决方案，包括所有软件和基础设施，但 Fortify 和 Nexus Lifecycle 等工具则着眼于软件/可部署单元。我们做出了一些与命名约定相关的半心半意的决定，这些约定将载入的项目与总体应用程序联系起来。将 SonarQube 加入相同的可部署单元是在管道中自动完成的。如果向 SonarQube 提供带有未知标识符的扫描结果，它会动态地在数据库中创建一个新条目。
应管理层的要求，我们部门的另一个团队针对一些 CI/CD/DevOps 指标和代码质量创建了仪表板。为此，创建了另一个管理来链接团队、应用程序和软件组件。此应用程序关联并收集了来自 SonarQube、Fortify 和 Nexus Lifecycle 的数据。
连接点
IT 的主要目的是实现公司的业务目标，但围绕 IT4IT 的一些概念侧重于 IT 的需求。在这个过程中有一些巨大的改进，以及相关的业务目标。
大多数开发工具起源于单个团队-单个项目的情况，企业支持大多是事后才加入的。从数字产品的角度来看，与单个产品或产品中的单个组件相关联的工程数据分散在许多面向功能的工程工具中。没有明确标识数字产品或数字组件的中央管理机构。它也不会以一致且技术中立的方式交叉引用工具中的相关工程数据。在设计时也没有对数字产品组合的结构化洞察。我们也缺乏对操作配置项与其来源的工程数据之间的关系的理解。
开发团队的自助服务设施不应仅限于入职，而必须涵盖数字产品及其组件的整个生命周期。这些设施应提供完全直通式处理，以避免开发团队和支持工具的团队之间出现任何不必要的依赖关系。
从价值链/供应链的角度来看，了解我们为客户提供的数字产品的构成更为重要。一个 DevOps 团队可以完全负责其产品的所有方面，这是一种错觉。从敏捷的角度来看，完全独立是理想的，但在企业层面呢？它根本无法扩展。而且，就人力资源而言，这将是非常昂贵的。
了解产品组成以及上游和下游依赖关系对于大规模实施敏捷或 DevOps 至关重要。
理论上的解决方案
鉴于具有所有权的概念级别（产品组合）和工程级别（DCI），包括组合关系，团队之间出现了生产者-消费者关系。
DCI 按类型分类，对于每种类型，都标识了必需的数据元素（这意味着必需的工具）。然后，确定这些元素的内部关系。例如，根标识符与派生标识符。
例如，基本标识符为组 ID、工件 ID 和版本 (GAV) 的 Java 组件在 POM.XML 文件中定义。在这种情况下，对于 ABN AMRO 创建的组件，其他命名约定适用。必须使用 SonarQube、Fortify、Nexus Lifecycle 和 Nexus Repository Manager。这些工具中关联对象的标识符来自 GAV。例如，SonarQube::Project、Fortify::Application、NexusLifecycle::Application、NexusRepositoryManager::Artifact 的标识符。
目前的解决方案
首先，我们将自己限制在一种产品、应用程序和一小组 DCI：仅应用程序和软件组件。我们现在也忽略了多个版本。
在产品组合级别，所有应用程序都已经在概念级别 (S2P) 注册，封装了应用程序的整个生命周期。在工程层面（R2D），大致做了以下工作：
- 对于现有应用程序，会创建相应的 DCI。
- 提供以下直接处理应用程序载入服务：为名为<application acronym>的新应用程序创建 CI/CD 环境
- 对于新的自主软件组件，提供以下服务：将 组件<组件列表>添加到应用程序<应用程序首字母缩略词>
请注意，此上下文中的“应用程序”是完整的最终用户解决方案，包括所有必需的软件和基础设施。
对于场景 2，这意味着在服务管理中创建了 DCI 记录，并且将触及应用程序需要载入的任何工具。例如：
- 在 LDAP 中创建特定于应用程序的访问组
- 在适当的 Nexus Repository 存储库中创建特定于应用程序的访问路径
- 在 SonarQube 中创建应用程序级访问
服务管理中已知拥有此应用程序的团队成员将自动获得访问权限。
对于场景 3，这意味着可以添加新的软件组件列表，并且对于每个软件组件，都会创建一个 SonarQube 项目、Fortify 应用程序和 Nexus Lifecycle 应用程序。此外，还会在服务管理中创建新的 DCI 记录。同样，为正确的团队成员授予对新创建项目的适当访问权限。
服务管理现在保存应用程序和软件组件的 DCI 记录，以及父 DCI（现在的应用程序）和它们的子 DCI（现在的软件组件）之间的关系。父 DCI 是指应用程序组合管理。
每个 DCI 注册器：
- 是标识符
- 用户需要的其他输入
- 哪些工具已载入
- 入驻状态
因此，通过使用约定，公司中的任何利益相关者都可以找到工具中相关工程数据的给定数字产品。
技术实现
解决方案的架构应支持 ABN AMRO 使用的所有 CI/CD 工具。所有 CI/CD 工具都由多个团队在一个部门管理，每个团队负责多个工具。因此，该架构有两个不同的层：一个中央服务，它公开一个供客户端进程使用的 API。
对于每个工具，都有一个特定的服务将中央服务期望的 API 转换为特定于工具的 API 调用。每项工具服务都将我们的 IT4IT 运营模型（如我们的服务管理中所表示的）转化为特定于工具的概念，反之亦然。例如，我们要求到SonarQube服务和Nexus仓库管理器服务并重：ç reate一个新的应用程序CI / CD环境 与给定的名称。对于 SonarQube 和 Nexus Repository Manager，这个请求意味着不同的东西。对于 SonarQube，基于这一请求进行了 16 次 API 调用。
目前，我们已经在我们的内部网上为上述两项服务实施了一个客户端流程和两个请求表。表单根据团队成员资格和应用程序所有权过滤选项列表，如服务管理中所知。从技术角度来看，每项服务都实现为一个容器，并部署在同一个 k8s（Kubernetes）集群上。
三个团队现在参与提供这些服务，这些服务涵盖了 ABN AMRO CI/CD 工具的大部分。