15 lat Adobe Experience Manager - historia
W dniu dzisiejszym minęło 15 lat, odkąd Adobe sfinalizowało zakup Day Software, nabywając w ten sposób produkt, który wszyscy znamy teraz jako "AEM".
Dla każdego z Was, którzy (tak jak ja) pracują z tą platformą od lat, mam nadzieję, że ten post będzie zabawną(lub bolesną) podróżą w dół wspomnień, gdy ponownie przyjrzymy się, dlaczego Adobe kupił Day i co się zmieniło (i nie zmieniło!) w ciągu 15 lat.
Komunikat dnia - przed przejęciem przez Adobe
Day Software to szwajcarska firma z siedzibą w Bazylei, która stworzyła swój przełomowy Communique CMS na niestandardowej platformie opartej na systemie plików, ale później przekształciła się w system oparty na repozytorium treści Java, który znamy dzisiaj.
Pierwsza wersja CQ była zbiorem skryptów CGI dla Netscape Enterprise Server (ręce do góry, jeśli kiedykolwiek go używałeś!) na początku 2000 roku i została przepisana jako aplikacja Java dla CQ2, a następnie serwer HTTP został z niej wydzielony dla CQ3 (geneza CQSE).
Aż do CQ4 zawartość była nadal przechowywana w plikach w lokalnym systemie plików, ale w 2005 r., wraz z wydaniem CQ 4.0, została przełączona ze starszego systemu przechowywania plików "Content Bus" na repozytorium "Content Repository eXtreme" (lub CRX) w wersji 1.0, którego ewolucja nadal zasila AEM - 20 pełnych lat później.
CQ5 był MASYWNĄ AKTUALIZACJĄ & podstawą dzisiejszego AEM
CQ5 stanowił niemal kompletną przeróbkę produktu.
Istnieje wiele funkcji &, które dziś mogą wydawać się powszechne, a które były ogromnymi i rewolucyjnymi elementami platformy CQ5. Uroczy artykuł CMSwire z 2008 roku odnotował "Podczas gdy niektórzy dostawcy CMS unikają Web 2.0, myśląc, że implozja Web 2.0 jest nieuchronna; Day koncentruje się na nim w dużym stopniu". Ile osób w tamtych czasach & mogło nawet zdefiniować Web 2.0? Ale ogromne nowe funkcje wydane w CQ5 zasadniczo sprawiły, że stała się ona zupełnie nową platformą i większość z nas nie wyobraża sobie CQ/AEM bez niej, np:
-
Interfejs użytkownika Sidekick & Author: graficzny interfejs użytkownika i tworzenie WYSIWG w CQ były wówczas ogromnym atutem, a fakt, że można było pracować z komponentami w środowisku bogatym w grafikę, był ogromnym krokiem naprzód w stosunku do innych ofert CMS w tamtym czasie.
-
Przepływy pracy: Wraz z tą wersją dodano silnik przepływu pracy, który również zachwycił ludzi, ponieważ można było wizualizować przepływ pracy BEZPOŚREDNIO W CMS i rozwijać logikę biznesową bezpośrednio w systemie zarządzania treścią. Mogę sobie wyobrazić, że już sama ta funkcja skłoniła wielu klientów korporacyjnych do przejścia na ten system
-
Tagi CQ: Czy wyobrażasz sobie pracę w CQ bez tagów? Dodanie obsługi tagów w końcu wprowadziło w pełni funkcjonalną taksonomię do CQ.
-
DAM: CQ5 otrzymał w tym wydaniu menedżera zasobów cyfrowych, umieszczonego w ścieżce
/content/dam, którą wszyscy dobrze znamy. Nawet w tej wczesnej erze wprowadzono oparte na przeglądarce (nie Flash!) obracanie obrazu &.
-
Klastrowanie: Jest to coś, co przetrwało tylko przez wydanie CQ5 i nie trafiło do AEM6, na dobre lub na złe. CQ5 posiadał dość zaawansowany klastring, który pozwalał na konfigurację klastrów hot active-active lub active-passive zarówno dla autorów, jak i wydawców. Widziałem dokładnie jednego klienta korzystającego z klastrowania wydawców, to był okropny pomysł i nie mam pojęcia, dlaczego to zrobił. Klastrowanie autorów było jednak dobrym pomysłem "" pozwalającym teoretycznie na tworzenie na klastrze master i propagowanie tych edycji do klastra slave (terminologia, która została wycofana). Klasteryzacja była jednak zawsze OGROMNYM bólem głowy związanym z niezawodnością.
-
Środowisko programistyczne CRX: W tamtym czasie Day udostępnił środowisko programistyczne oparte na Eclipse, w którym można było pracować, aby uzyskać szczegółowy widok repozytorium treści Java po stronie klienta. Wydali również lekki interfejs oparty na przeglądarce, który mógł być używany zamiast Eclipse o nazwie "CRX Development Environment Lite" lub crxde, który przetrwał do dziś w niemal dokładnie takiej samej formie.
Nie jest to nowość w tej wersji, ale warto o tym wspomnieć - oddzielne poziomy tworzenia & publikacji CQ sprawiły, że ograniczenia wydajności lub niestabilność po stronie tworzenia nie spowodowały awarii witryny publicznej i odwrotnie. Posiadanie CQ na fundamencie OSGI i Sling oznaczało niezwykle elastyczny silnik treści, zdolny zarówno do bogatych dynamicznych odpowiedzi, jak i renderowania stron, a także możliwość podłączenia ciężkiego podnoszenia w Javie dla wszelkiego rodzaju aplikacji, które wcześniej mogły być uruchamiane na własnym stosie serwerów aplikacji.
Oś czasu wydań CQ & Zmiany
Do momentu przejęcia przez Adobe historia wersji CQ wyglądała następująco:
-
Day CQ 3.5 (2002)
-
Day CQ 4.0 (2005)
-
Day CQ 4.1 (2006)
-
Day CQ 4.2 (2008)
-
Day CQ 5.0 (2008) - udostępniony tylko klientom wewnętrznym jako wersja zapoznawcza
-
Day CQ 5.1 (2008) - pierwsze ogólnodostępne wydanie CQ5. Pierwszy dodatek do Workflows, DAM, Tags, CRXDE, Clustering i Sidekick
-
Day CQ 5.2 (2009):
- Ulepszone zarządzanie zasobami cyfrowymi (DAM) z ulepszoną obsługą metadanych
- Ulepszenia silnika przepływu pracy dla przetwarzania treści
- Lepsza integracja z usługą Adobe Analytics
- To tutaj po raz pierwszy na świecie pojawił się Multi-Site Manager (MSM).
-
Day CQ 5.3 (2010)
- Wprowadzenie funkcji Społeczności do współpracy społecznościowej (i warto zauważyć, że AEM 6.5 LTS właśnie ostatecznie zdeprecjonował i usunął tę funkcjonalność!)
- "Optymalizator witryny" do testów A/B i wielowariantowych (wkrótce usłyszymy TĘ nazwę ponownie).
- Ulepszone przepływy pracy tłumaczeń i obsługa internacjonalizacji
Przejęcie Day Software przez Adobe & CQ
Adobe ogłosiło w lipcu 2010 roku, że zamierza kupić Day Software, a wraz z nim produkt CQ. W tym momencie Adobe prowadziło już własną stronę internetową na CQ, a biorąc pod uwagę ich nowy nacisk na budowanie linii biznesowej technologii marketingowych, miało to sens. Adobe właśnie przejęło Omniture we wrześniu 2009 roku za 1,8 miliarda dolarów i Scene7 w 2007 roku - było więc jasne, że Adobe zaczyna poważnie myśleć o czymś więcej niż tylko o swojej działalności związanej z oprogramowaniem kreatywnym.
Przejęcie przez Adobe zostało sfinalizowane we wrześniu 2010 roku za 240 milionów dolarów w ramach transakcji gotówkowej, 7 razy taniej niż zapłacono za Omniture - co z perspektywy czasu było niezłą kradzieżą.
Nie jestem pewien, jak ty, ale pamiętam dokładnie, gdzie byłem, gdy ogłoszono umowę. W tym czasie byłem w trakcie uruchamiania CQ 5.2 dla AARP (korzystali z CQ od wersji CQ 4.2). CQ w tamtym czasie było dla mnie w równym stopniu "ogromny ból głowy" i "czy to jest to, dokąd zmierza CMS?" Biorąc pod uwagę, że wciąż próbowaliśmy ustalić, które usługi powinny pozostać w JBoss, a które mogłyby równie dobrze działać w CQ5, teraz, gdy CQ ma tak solidny framework serwera aplikacji Java.
Ale CZY TERAZ ZAKUPIONE PRZEZ ADOBE? To zmieniło dla mnie całą matematykę, czy nadal inwestować czas w naukę CQ5, ponieważ oczywiście z Adobe za nim, to prawdopodobnie MIAŁO NOGI. I tak się stało!
"Branding Day Software" wewnątrz aplikacji został wkrótce zmieniony na "Adobe CQ", choć wszystko inne pozostało takie samo.
-
Adobe CQ 5.4 (2011)
- repozytorium CRX2 dla lepszej wydajności i skalowalności (był to mój pierwszy duży projekt CQ, migracja repozytorium z CQ 5.3 do 5.4)
- Ulepszone funkcje społecznościowe i zarządzanie społecznością
- Lepsze możliwości tworzenia na urządzeniach mobilnych
-
Adobe CQ 5.5 (2012)
- Konektory do Adobe Creative Suite, Scene7 i Search&Promote
- Bezpośrednie tworzenie aplikacji mobilnych
- Partnerstwo z Hybris dla integracji eCommerce
- Funkcja Cofnij/Przywróć w edytorze
- Fragmenty treści po raz pierwszy pojawiły się tutaj jako niestandardowe rozwiązanie dla klienta, z którym pracowałem, a później zostały wydane jako pakiet funkcji.
Zmiana marki na "Adobe Experience Manager"
Adobe wiedziało, że nie będzie się ono wiecznie nazywać "CQ", więc podjęło kilka nieudanych prób rebrandingu, najpierw nazywając go "Adobe WCM", a następnie "Web Experience Manager", zanim zdecydowano się nazwać go "Adobe Experience Manager". W połowie wersji 5.6 ekran logowania został zmieniony i po zalogowaniu się do CQ wyświetlany był ekran "Adobe Experience Manager".
-
AEM 5.6 (2013)
- TouchUI został wprowadzony dla środowiska autorskiego (ile znasz aplikacji, które nadal używają ClassicUI?).
- Obsługa witryn i aplikacji mobilnych
- Ulepszona personalizacja i targetowanie
- Ulepszony DAM z profilami wideo
-
AEM 6.0 (2014)
AEM 6 był ZNACZĄCYM przepisaniem wielu podstaw AEM. Dla każdego z nas w biznesie migracje CQ5 -> AEM6 pochłonęły zdecydowaną większość naszego czasu, ponieważ były BARDZO pracochłonne.- AEM 6 zmienił bazowe repozytorium z Apache Jackrabbit na Apache Oak, co wymagało migracji na dużą skalę.
- Aktywny klaster CQ nie był już dostępny, chociaż Adobe wprowadziło backend pamięci masowej MongoMK dla AEM, który teoretycznie (w tym momencie BARDZO TEORETYCZNIE) mógł zapewnić poziomo skalowanych autorów AEM. Był on jednak wyjątkowo podatny na błędy, a nasza jedyna implementacja zakończyła się katastrofą i przejściem na pojedynczego autora TarMK
- Większa powierzchnia TouchUI dla większości stron
- Inteligentne tagi dla zasobów
-
AEM 6.1 (2015)
- Wiele poprawek błędów, ale 6.1 wciąż nie był szczególnie stabilnym wydaniem.
- Obsługa Vanity URL pojawiła się w wersji 6.1
- ContextHub dla personalizacji
- Zestaw SDK dla aplikacji mobilnych
- Wprowadzono AEM Communities, a wraz z nim wiele opcji infrastruktury i przechowywania treści generowanych przez użytkowników. Z czasem zostanie to ulepszone, ale niestety nie przetrwa przejścia na usługę w chmurze.
- Aplikacja AEM Desktop została wydana dla 6.1, udało mi się 100% DDOS środowiska autorskiego za pomocą tej aplikacji :(
-
AEM 6.2 (2016)
- Wiele poprawek błędów i ulepszeń stabilności - nadal nie jest to szczególnie stabilne wydanie, ale OSTATECZNIE lepsze niż 6.1 lub 6.0.
- Powszechne wprowadzenie fragmentów treści (wcześniej można to było zrobić za pomocą pakietu funkcji, ale teraz jest to część produktu)
- Obsługa SSL wewnątrz AEM
- Zmiany w interfejsie użytkownika - nawigacja została przeniesiona na górę z bocznego paska.
-
AEM 6.3 (2017)
- Core Components został wprowadzony jako gotowy do produkcji "" .
- Duże ulepszenia pamięci masowej w wersji 6.3 sprawiają, że jest to pierwsza bardzo stabilna wersja AEM 6. Było to wprowadzenie oddzielnych stron
datastoreisegmentstoreoraz niezawodnego mechanizmu zarządzania wersjami online (tar compaction). - Wprowadzane są fragmenty doświadczenia
- Edytor pojedynczej strony (SPA) jest przeznaczony dla aplikacji jednostronicowych.
- "Adobe Sensei" zaczyna przenikać do AEM Assets jako branding AI Adobe, z (w tamtym czasie) dość przełomowymi elementami funkcjonalności AI. Inteligentne przycinanie, inteligentne tagowanie itp. trafiły do aplikacji Assets.
-
AEM 6.4 (2018)
- 6.4 był pierwszą rundą restrukturyzacji repozytorium "" zaprojektowaną w celu ułatwienia aktualizacji i ostatecznie utorowania drogi do przejścia na usługę w chmurze.
- Przepływy pracy przeniesione do TouchUI
- Szereg ulepszeń w usługach tłumaczeniowych
- Inteligentne przycinanie wideo w zasobach
-
AEM 6.5 (2019)
- Wiele restrukturyzacji repozytorium
- Connected Assets to potencjalna opcja łączenia zdalnych środowisk zasobów z oddzielnym środowiskiem AEM Sites. Działa jednak tylko w przypadku obrazów.
- Ogromne ulepszenia edytora SPA
- GraphQL dla handlu
- A ponieważ 6.5 istnieje już od 6 lat (najdłużej ze wszystkich wersji AEM/CQ do tej pory!), istnieje TONA nowych funkcji, które zostały wydane za pośrednictwem dodatku Service Pack. W tym momencie korzystamy z dodatku Service Pack 23, a podsumowanie wszystkich nowych funkcji, które pojawiły się od 2019 roku, zasługuje na osobny wpis na blogu.
-
AEM jako usługa w chmurze (2020)
Po raz pierwszy zaprezentowany na adaptTo() 2019 (większość z nas nie wiedziała wtedy, na co tak naprawdę patrzymy!). AEM jako usługa w chmurze została udostępniona światu w styczniu 2020 roku i zajęłaby centralne miejsce na szczycie Adobe Summit 2020... gdyby w 2020 roku odbył się osobisty szczyt Adobe Summit. Tym większa szkoda. AEM jako usługa w chmurze została stworzona, aby rozwiązać szereg długotrwałych niedociągnięć AEM & CQ i odniosła w tym zakresie różne sukcesy, co w rzeczywistości doprowadziło do dzisiejszego krajobrazu ofert AEM. To, co oferuje, to:- W pełni oparte na usługach środowisko AEM w chmurze
- Automatyczne skalowanie na poziomie autora & wydawcy
- Wbudowany CDN
- Znacznie zaktualizowany przepływ pracy & możliwości pozyskiwania danych dzięki silnikowi pozyskiwania zasobów opartemu na mikrousługach
- Nowe możliwości wyszukiwania, z wyszukiwaniem opartym na sztucznej inteligencji (opartym na RAG), zostały właśnie wydane & omówione w adaptTo()
-
AEM 6.5 LTS
AEM 6.5 LTS to długoterminowa opcja dla osób, które planują kontynuować samodzielny hosting lub hosting AMS swoich obciążeń AEM 6.5 po 2025 r. W zależności od tego, czy rozmawiasz z inżynierami, czy marketingowcami, AEM 6.5 LTS jest nazywany "AEM 6.6" lub "AEM 6.5 LTS". Java 11 wkrótce zostanie wycofana z użytku, więc jedyną opcją jest uruchomienie AEM na Java 17 lub Java 21.
Jest to z pewnością ostatni PRAWDZIWY SUKCESOR pełnego produktu, który ukazał się w 2009 roku, ponieważ wiele jego części (tj./crx/packmgri/crx/dei/etc/replication.htmli tak dalej) są prawie DOKŁADNIE takie same, jak w oryginalnej wersji CQ5. -
Usługi Edge Delivery & DA
Jaka jest przyszłość AEM? Prawdopodobnie zarówno funkcjonalnym, jak i "duchowym" następcą AEM w przyszłości będą usługi Edge Delivery Services na poziomie dostarczania oraz Document Authoringna poziomie zarządzania treścią i autoryzacji. Jest to absolutnie dyskusyjne, ale DA stanowi bardzo mocny argument za kierunkiem, w którym AEM będzie podążać w nadchodzących latach.
O autorze
Podoba ci się to, co usłyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami