Adobe Experience Manager 15 年：AEM 版本历史课

Adobe Experience Manager 15 年发展史

从今天开始，Adobe 完成对 Day Software 的收购已经过去了 15 年，从而获得了大家现在都知道的产品"AEM" 。

对于那些（像我一样）多年来一直使用这一平台的人来说，希望这篇文章能成为一次有趣（或痛苦）的回忆之旅，让我们重温一下 Adobe 收购 Day 的原因，以及 15 年来发生了哪些变化（和没有发生变化的地方！）。

日公报--Adobe 接管之前

Day Software是一家总部位于瑞士巴塞尔的公司，他们在一个基于自定义文件系统的平台上创建了突破性的 Communique CMS，但后来又演变成了我们今天所熟知的由 Java 内容存储库支持的系统。

2000 年初，CQ 的第一个版本是网景企业服务器（Netscape Enterprise Server，如果你用过，请举手！）的 CGI 脚本集，后来在 CQ2 中被改写成 Java 应用程序，在 CQ3 中又将 HTTP 服务器分离出来（CQSE 的起源）。

在 CQ4 之前，内容仍存储在本地文件系统的文件中，但在 2005 年 CQ 4.0 发布后，内容从旧的"Content Bus" 文件系统存储转换为"Content Repository eXtreme" （或 CRX）版本 1.0 的存储库，20 年后的今天，AEM 仍在使用该存储库。

CQ5 是一次重大升级& 当今 AEM 的基础

CQ5 几乎完全重写了该产品。

& 有许多功能在今天看来可能司空见惯，但在 CQ5 平台上却具有巨大的革命性意义。CMSwire 2008 年的 一篇 迷人文章 指出："一些 CMS 供应商对 Web 2.0 退避三舍，认为 Web 2.0 的内爆迫在眉睫 ；而 Day 则非常重视 Web 2.0 " 。在那个& 时代，有多少人能够 定义 Web 2.0？但是，CQ5 发布的大量新功能基本上使其成为一个全新的平台，我们中的大多数人甚至无法想象没有它的 CQ/AEM 会是什么样子，例如：

• Sidekick& Author UI：CQ 的图形用户界面和所见即所得的创作方式在当时是一个巨大的卖点，而且你可以在一个图形丰富的环境中使用组件，这比当时其他的 CMS 产品高出一大截。

  

• 工作流：该版本新增的工作流引擎也让人大开眼界，你可以在内容管理系统中直接可视化工作流，并在内容管理系统中直接开发业务逻辑。我可以想象，仅这一项功能就吸引了很多企业客户转用该系统。

  

• CQ 标签：您能想象在没有标签的 CQ 中工作吗？添加标签支持最终为 CQ 带来了全功能分类法。

• 数字资产管理器：CQ5 在此版本中增加了数字资产管理器，位于我们现在都非常熟悉的/content/dam 路径中。即使在早期，它也带来了基于浏览器（不是 Flash！）的图像裁剪& 旋转功能。

  

• 集群：无论好坏，这个功能只在 CQ5 版本中出现过，并没有在 AEM6 中出现。CQ5 具有相当先进的集群功能，可为作者和出版商提供热主动-主动或主动-被动集群设置。我只见过一个客户使用 Publisher 集群，这是个糟糕的主意，我不知道他们为什么要这么做。不过，作者集群曾是"" 的一个好主意，理论上可以让一个人在集群主站上进行创作，并将这些编辑传播到集群从站（该术语已被淘汰）。然而，聚类始终是一个非常令人头疼的可靠性问题。

• CRX 开发环境：当时，Day 发布了一个基于 Eclipse 的开发环境，您可以在该环境中工作，获得 Java 内容存储库的客户端视图。他们还发布了一个基于浏览器的轻量级界面，可用于替代 Eclipse，名为"CRX Development Environment Lite" 或 crxde，至今仍以 几乎完全相同的形式 存在。

这不是新版本，但值得一提--CQ 的独立创作& 发布层使创作端的性能限制或不稳定不会导致面向公众的网站瘫痪，反之亦然。CQ 位于 OSGI 和 Sling 的基础之上，这意味着它是一个非常灵活的内容引擎，既能进行丰富的动态响应和页面渲染，又能为以前可能需要在自己的应用服务器堆栈中运行的各种应用程序插入 Java 重载功能。

CQ 发布时间表& 更改

在 Adobe 被收购之前，CQ 的版本历史是这样的：

• 日 CQ 3.5（2002 年）

• 日 CQ 4.0（2005 年）

• 日 CQ 4.1（2006 年）

• 日 CQ 4.2（2008 年）

• Day CQ 5.0（2008 年）--仅作为预览版向内部客户发布

• 日 CQ 5.1（2008 年）--CQ5 首次全面发布。首次添加工作流程、DAM、标签、CRXDE、集群 和Sidekick

• 日 CQ 5.2（2009 年）：

  • 改进了元数据处理，增强了数字资产管理（DAM）
  • 改进内容处理的工作流程引擎
  • 更好地集成 Adobe 分析功能
  • 多站点管理器（MSM）就是在这里首次向世界发布的。

• 日 CQ 5.3（2010 年）

  • 引入用于社交协作的社区功能（注意，AEM 6.5 LTS 才刚刚弃用并移除该功能！）。
  • "Site Optimizer" 用于 A/B 和多元测试（我们很快就会再次听到这个名字）。
  • 增强翻译工作流程和国际化支持

Adobe 收购 Day 软件& CQ

Adobe 于 2010 年 7 月宣布将收购 Day Software，并随之收购 CQ 产品。此时，Adobe 已经在 CQ 上运行自己的网站，考虑到他们全新的重点是建立营销技术业务线，这也是合情合理的。2009 年 9 月，Adobe 刚刚以 18 亿美元的价格收购了 Omniture，并于 2007 年收购了 Scene7，因此很明显，Adobe 开始重视的不仅仅是其创意软件业务。

Adobe 于 2010 年 9 月以 2.4 亿美元的全现金交易完成了对 Omniture 的收购，这比他们收购 Omniture 的价格便宜了 7 倍--事后看来，这是一笔相当划算的交易。

我不知道你怎么想，但我清楚地记得交易宣布时我在哪里。当时我正在为美国退休人员协会运行 CQ 5.2（他们从 CQ 4.2 开始就使用 CQ）。当时的 CQ 对我来说，是"巨大的头痛" 和"这就是 CMS 的发展方向吗？"考虑到 CQ 拥有如此强大的 Java 应用服务器框架，我们仍在努力确定哪些服务应保留在 JBoss 上，哪些服务可以在 CQ5 中轻松运行。

但 现在是 ADOBE 购买的吗？ 这改变了我对是否继续投入时间学习 CQ5 的所有计算，因为很明显，有 Adobe 在背后支持，CQ5 很可能会有后劲。它确实做到了！

"Day Software" 应用程序内的品牌标识不久更改为"Adobe CQ" ，但其他大部分内容仍保持不变。

• Adobe CQ 5.4 (2011)

  • CRX2 版本库提高了性能和可扩展性（这是我的第一个大型 CQ 项目，从 CQ 5.3 升级到 5.4 的版本库迁移）。
  • 增强社交功能和社区管理
  • 更好的移动创作能力

• Adobe CQ 5.5 (2012)

  • 与 Adobe Creative Suite、Scene7 和 Search&Promote 的连接器
  • 直接制作移动应用程序
  • 与 Hybris 合作实现电子商务集成
  • 编辑器中的撤销/重做功能
  • 内容片段首次出现在这里，实际上也是为我的一位客户定制开发的，后来作为功能包发布。

重塑品牌"Adobe Experience Manager"

Adobe 知道这不会永远被称为"CQ" ，因此他们尝试了几次流产的品牌重塑尝试，先是将其称为"Adobe WCM" ，然后又将其称为"Web Experience Manager" ，最后确定将其称为"Adobe Experience Manager" 。在 5.6 版本中，登录屏幕发生了变化，现在登录 CQ 时，您可以看到"Adobe Experience Manager" 。

• AEM 5.6 (2013)

  • 为作者环境引入了 TouchUI（您知道有多少应用程序仍在使用 ClassicUI？）
  • 支持移动网站和应用程序
  • 改进个性化和目标定位
  • 通过视频配置文件增强 DAM

• AEM 6.0（2014 年）
  AEM 6 对 AEM 的许多基础进行了重大改写。对于我们这些业务人员来说，CQ5 -> AEM6 迁移占用了我们绝大多数的时间，因为这些工作非常耗费精力。

  • AEM 6 将底层存储库从 Apache Jackrabbit 换成了 Apache Oak，需要进行大规模迁移。
  • 尽管 Adobe 为 AEM 引入了 MongoMK 存储后端，但 CQ 的主动-主动集群功能已不再可用，理论上（此时理论上）可以提供横向扩展的 AEM Authors。然而，它的漏洞极多，我们在此基础上进行的唯一一次实施以灾难告终，并转向 TarMK 单个作者
  • 大多数页面的触摸界面占用空间更大
  • 资产智能标签

• AEM 6.1 (2015)

  • 虽然修复了很多错误，但 6.1 仍不是一个特别稳定的版本。
  • 6.1 版支持虚荣 URL
  • 个性化的 ContextHub
  • 移动应用程序 SDK
  • AEM Communities的推出，为用户生成的内容提供了大量基础设施和存储选项。随着时间的推移，将对其进行改进，但遗憾的是，它无法在迁移到云服务后继续使用。
  • AEM 桌面应用程序是为 6.1 发布的，我用这个应用程序成功地 100% DDOS 了一个作者环境 :(

• AEM 6.2 (2016)

  • 修复了更多错误并提高了稳定性--这仍然不是一个特别稳定的版本，但比 6.1 或 6.0 要好得多。
  • 广泛引入内容碎片（以前可以通过功能包完成，但现在已成为产品的一部分）
  • AEM 内部的 SSL 支持
  • 用户界面改变为我们现在习惯的方式--导航从侧边栏移到顶部

• AEM 6.3 (2017)

  • 核心组件作为"生产准备就绪的" 推出。
  • 6.3 中的大量底层存储改进最终使其成为第一个非常稳定的 AEM 6 版本。这就是引入分离的datastore 和segmentstore 以及在线版本管理的可靠机制（tar 压缩）。
  • 经验片段介绍
  • 单页编辑器（SPA）是针对单页应用程序推出的。
  • "Adobe Sensei" 开始渗透到 AEM Assets 中，成为 Adobe 的人工智能品牌，具有（当时）相当突破性的人工智能功能。智能裁剪、智能标记等功能已进入 Assets。

• AEM 6.4 (2018)

  • 6.4 是"存储库重组的第一轮" ，旨在使升级更容易，并最终为迁移到云服务铺平道路。
  • 工作流程移至 TouchUI
  • 翻译服务的若干改进
  • 资产中的视频智能裁剪

• AEM 6.5（2019 年）

  • 大量资源库重组
  • 连接资产"为将远程资产环境连接到单独的 AEM Sites 环境提供了一个潜在选项。但仅适用于图像。
  • 大幅改进 SPA 编辑器
  • 用于商务的 GraphQL
  • 而且，由于 6.5 已经运行了 6 年（是迄今为止所有 AEM/CQ 版本中运行时间最长的！），因此通过 Service Pack 发布了大量新功能。目前 ，我们正在使用 Service Pack 23 ，自 2019 年以来推出的所有新功能都值得我们撰写自己的博文。

• 作为云服务的 AEM（2020 年）
  在 2019 年的 adaptTo() 会议上首次预告（当时我们大多数人都不知道我们到底在看什么！）。作为云服务的 AEM 于 2020 年 1 月向全球发布，并将在 2020 年 Adobe 峰会上占据中心位置......如果 2020 年有亲临现场的 Adobe 峰会的话。更遗憾的是AEM 作为一种云服务，是为了解决 AEM& CQ 长期以来的一些缺陷而创建的，并在这方面取得了不同程度的成功，真正形成了今天的 AEM 产品格局。它能提供什么？

  • 云中基于服务的 AEM 环境
  • 自动缩放作者& 出版商层级
  • 内置 CDN
  • 通过基于微服务的资产摄取引擎，大规模更新工作流程& 数据摄取功能
  • 新的搜索功能，刚刚发布的人工智能增强型（基于 RAG 的）搜索& 在 adaptTo() 中进行了讨论

• AEM 6.5 LTS
  6.5 LTS 的名称有多种，如"AEM 6.6" 或"AEM 6.5 LTS" ，这取决于您是在与工程人员还是营销人员交谈，6.5 LTS 是计划在 2025 年之后继续自行托管或 AMS 托管其 AEM 6.5 工作负载的人员的长期选择。Java 11 即将报废，因此在 Java 17 或 Java 21 上运行 AEM 是唯一的选择。
  
  可以肯定的是，这是 2009 年推出的完整产品仅存的最后一款真正的 SUCCESSOR，因为它的许多部分（如："....../crx/packmgr /crx/de 和 等等）与最初发布 CQ5 时几乎完全相同。/etc/replication.html

• 边缘交付服务& DA
  AEM 的未来是什么？可以说，AEM 未来的功能和"精神" 继任者将是 交付层的边缘交付服务（Edge Delivery Services ）和内容管理与作者启用层的 文档编写 （Document Authoring ）。这一点绝对值得商榷，但 DA 为 AEM 未来几年的发展方向提供了非常有力的论据。

关于作者

喜欢你听到的吗？对什么适合您有疑问？我们很乐意与您交谈！联系我们