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" (or CRX) repository version 1.0，其演進至今仍為 AEM 提供動力 - 整整 20 年之後。

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 的 GUI 和 WYSIWG 編輯在當時是一個很大的賣點，您可以在圖形豐富的環境中使用元件，這在當時比其他 CMS 產品高出一大步。

  

• 工作流程：此版本新增的工作流程引擎也讓人大吃一驚，因為您可以直接在 CMS 中視覺化工作流程，並直接在內容管理系統中開發業務邏輯。我可以想像，光是這項功能就讓許多企業客戶轉用此系統。

  

• CQ 標籤：您能想像在沒有標籤的 CQ 中工作嗎？新增標籤支援終於為 CQ 帶來全功能的分類系統。

• DAM: CQ5 在此版本中加入了數位資產管理器，位於我們現在非常熟悉的/content/dam 路徑中。即使在這個早期時代，它也帶來了以瀏覽器為基礎 (不是 Flash!) 的影像裁剪& 旋轉。

  

• 集群：無論好壞，這個功能只在 CQ5 版本中出現，並沒有在 AEM6 中出現。CQ5 具有相當先進的群集功能，可為作者和出版商提供熱主動-主動或主動-被動群集設定。我只看過一個客戶使用 Publisher 叢集，那是個糟糕的主意，我不知道他們為什麼要這麼做。不過，作者叢集曾經是一個很好的"" 主意，理論上可以讓一個人在叢集主站上進行作者編輯，並讓這些編輯傳播到叢集從站上（這個術語已經被廢除了）。然而，聚類總是讓人非常頭痛的可靠性問題。

• CRX 開發環境：當時，Day 發佈了一個基於 Eclipse 的開發環境，讓您可以在其中工作，從客戶端檢視 Java Content Repository。他們還發布了一個基於瀏覽器的輕量級介面，可以用來代替 Eclipse，稱為"CRX 開發環境 Lite" 或 crxde，至今仍以 幾乎完全相同的形式 存在。

這不是新版本，但值得一提 - CQ 獨立的撰寫& 發佈層級使撰寫端的效能限制或不穩定不會導致面向公眾的網站癱瘓，反之亦然。CQ 位於 OSGI 和 Sling 的基礎上，這意味著它是一個非常靈活的內容引擎，既能夠提供豐富的動態回應和頁面渲染，又能夠為以前可能需要在自己的應用程式伺服器堆疊中運行的各種應用程式插入 Java 重載功能。

CQ 發佈時間表& 變更

在 Adobe 收購之前，CQ 的版本歷史是這樣的：

• Day CQ 3.5 (2002)

• Day CQ 4.0 (2005)

• Day CQ 4.1 (2006)

• 日 CQ 4.2 (2008)

• Day CQ 5.0 (2008) - 僅作為預覽版發放給內部客戶

• Day CQ 5.1 (2008) - CQ5 的第一個通用版本。首次新增工作流程、DAM、標籤、CRXDE、群集 和Sidekick

• Day CQ 5.2 (2009)：

  • 強化的數位資產管理 (DAM)，改善元資料處理
  • 內容處理的工作流程引擎改良
  • 更好地與 Adobe 分析整合
  • Multi-Site Manager (MSM)就是在這時首次面世的。

• 日 CQ 5.3 (2010)

  • 引入社群功能以進行社群協作 (注意AEM 6.5 LTS 才剛剛廢棄並移除此功能！)
  • "Site Optimizer" 用於 A/B 和多元測試 (我們很快就會再聽到這個名字)
  • 強化翻譯工作流程與國際化支援

Adobe 收購日軟體& CQ

Adobe 於 2010 年 7 月宣佈收購 Day Software 及其 CQ 產品。當時 Adobe 已經在 CQ 上運行他們自己的網站，而且考慮到他們全新的重點是建立行銷技術業務線，這也是合情合理的。Adobe 剛於 2009 年 9 月以 18 億美元收購 Omniture，並於 2007 年收購 Scene7 - 因此很明顯 Adobe 開始認真看待他們的創意軟體業務以外的事情。

Adobe 於 2010 年 9 月以 2.4 億美元的全現金交易完成收購，比他們收購 Omniture 時所支付的價格便宜了 7 倍 - 事後看來，這是相當划算的。

我不確定您是否記得，但我記得很清楚，當交易宣佈時我在哪裡。當時我正在為 AARP 執行 CQ 5.2（他們從 CQ 4.2 開始就使用 CQ）。當時的 CQ 對我來說，等於"巨大的頭痛" 和"這就是 CMS 要去的地方嗎？"鑑於我們仍在嘗試找出哪些服務應該留在 JBoss 上，哪些服務可以輕鬆地在 CQ5 內執行，因為 CQ 已擁有如此強大的 Java 應用程式伺服器架構。

但現在 ADOBE 已經購買了？這改變了我對於是否要繼續投入時間學習 CQ5 的所有計算，因為很明顯，有 Adobe 在背後支持，它很有可能是有生命力的。它確實做到了！

"日軟體" 應用程式內的品牌很快就改成"Adobe CQ" ，雖然其他大部分都沒變。

• Adobe CQ 5.4 (2011)

  • CRX2 儲存庫改善了效能和可擴展性（這是我第一個主要的 CQ 專案，從 CQ 5.3 升級到 5.4 的儲存庫遷移）
  • 增強的社交功能和社群管理
  • 更好的行動撰寫功能

• Adobe CQ 5.5 (2012)

  • 與 Adobe Creative Suite、Scene7 和 Search&促進的連接器
  • 直接製作行動應用程式
  • 與 Hybris 合作進行電子商務整合
  • 編輯器中的復原/重做功能
  • Content Fragments第一次出現在這裡，其實也是為我合作的客戶所做的客製開發，後來以功能包的形式發行。

重塑品牌形象至"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，需要進行大規模的遷移。
  • CQ 的主動-主動群集已不再可用，雖然 Adobe 為 AEM 引進了 MongoMK 儲存後端，理論上 (在此時非常理論上) 可以提供水平擴充的 AEM Authors。然而，它的錯誤非常多，而且我們唯一的實作也是以災難收場，並轉換為 TarMK 單一作者。
  • 大部分頁面的 TouchUI 佔用空間較大
  • 資產的智慧標籤

• AEM 6.1 (2015)

  • 雖然修正了許多錯誤，但 6.1 仍然不是一個特別穩定的版本。
  • Vanity URL 支援在 6.1 中出現
  • 個人化的 ContextHub
  • 行動應用程式 SDK
  • AEM Communities的推出，為使用者產生的內容提供了大量的基礎架構和儲存選項。隨著時間的推移，我們會對其進行改進，但不幸的是，它無法在轉移到雲端服務後繼續運作。
  • AEM Desktop App 已釋出 6.1 版，我使用此應用程式成功 100% DDOS 一個作者環境 :(

• AEM 6.2 (2016)

  • 更多的錯誤修正和穩定性改進 - 仍然不是一個特別穩定的版本，但比 6.1 或 6.0 好很多。
  • 廣泛的內容片段介紹（以前可透過功能包完成，但現在已成為產品的一部分）
  • AEM 內的 SSL 支援
  • UI 變更為我們現在習慣的方式 - 導覽從側邊欄移至頂端

• AEM 6.3 (2017)

  • 核心元件以"生產就緒的" 形式推出。
  • 6.3 上的大型底層儲存改良終於使此版本成為第一個非常穩定的 AEM 6 版本。這就是分離的datastore 和segmentstore ，以及線上版本管理的可靠機制 (tar compaction)。
  • 經驗片段介紹
  • 單頁編輯器 (SPA) 是針對單頁應用程式所推出的。
  • "Adobe Sensei" 開始滲透 AEM Assets 作為 Adobe 的 AI 品牌，具有（在當時）相當突破性的 AI 功能。智慧型裁剪、智慧型標籤等功能已進入 Assets。

• AEM 6.4 (2018)

  • 6.4 是"儲存庫重組的第一輪" ，目的是讓升級更容易，並最終為移至雲端服務鋪路。
  • 工作流程移至 TouchUI
  • 翻譯服務的多項改進
  • 資產中的視訊智慧裁切

• AEM 6.5 (2019)

  • 大量儲存庫重組
  • Connected Assets提供了將遠端資產環境連接至獨立 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 as a Cloud Service 是為了解決 AEM& CQ 長期以來的一些缺點而創建的，並在這方面取得了不同程度的成功，真正形成了今天 AEM 產品的格局。它提供的是

  • 雲端中基於服務的完整 AEM 環境
  • 自動調整作者& 出版商層級
  • 內建 CDN
  • 大量更新的工作流程& 資料擷取功能與以微服務為基礎的資產擷取引擎
  • 新的搜尋功能， AI 增強型（基於 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 和/etc/replication.html 等等）幾乎與最初 CQ5 發行時完全相同。

• 邊緣交付服務& DA
  AEM 的未來是什麼？可以說，AEM 未來的功能以及"精神" 繼承者將會是 傳輸層的 Edge Delivery Services ，以及內容管理與作者啟用 層 的 Document Authoring 。這絕對是有爭議的，但 DA 為 AEM 未來幾年的發展方向提出了非常有力的論據。

關於作者

喜歡你聽到的嗎？對適合您的產品有疑問？我們很樂意與您討論！聯絡我們

您可能會喜歡的更多 AEM 文章