Po opracowaniu szablonu serwisu można, korzystając z narzędzi CLI (Command-Line Interface) z zestawu OCE Toolkit, przekazywać szablon ze środowiska rozwojowego do testowego, a następnie do produkcyjnego na swoich serwerach Oracle Content Management.
Propagację zmian można przeprowadzić za pomocą poleceń z zestawu Toolkit, używając ich do tworzenia serwisów i zarządzania cyklem ich życia na serwerach rozwojowych, testowych i produkcyjnych. Zmian w serwisach można dokonać na serwerze produkcyjnym, a następnie przekazać te zmiany do środowisk testowego i produkcyjnego. Ten zestaw narzędzi opartych na wierszu polecenia można także wprowadzić do swoich środowisk skryptowych w celu zarządzania swoimi wdrożeniami. Korzystając z narzędzi CLI, można tworzyć nowe elementy, takie jak zasoby i składniki czy aktualizacje istniejącej zawartości.
Poniższa procedura pokazuje, jak za pomocą narzędzia CLI z zestawu OCE Toolkit przeprowadzać propagację zmian ze środowiska rozwojowego do testowego i produkcyjnego:
Skonfigurować serwery rozwojowy, testowy i produkcyjny z użyciem tego samego repozytorium i tego samego założenia systemowego dot. lokalizacji.
Aby umożliwić propagację zmian z serwera rozwojowego do serwera testowego, a następnie do serwera produkcyjnego, trzeba na każdym z nich skonfigurować repozytorium o tej samej nazwie i z tym samym założeniem systemowym dot. lokalizacji. Domyślnym założeniem systemowym dot. lokalizacji jest en-US, lecz można użyć innego pod warunkiem, że będzie ono identyczne na każdym z tym trzech serwerów.
Zarejestrować serwery rozwojowy, testowy i produkcyjny za pomocą usługi Oracle Content Management.
Przed przystąpieniem do propagacji zmian serwisu trzeba zarejestrować każdy z tych serwerów. Serwer można zarejestrować, używając polecenia cec register-server z zestawu OCE Toolkit:
cec register-server <name>
Określić następujące opcje polecenia:
-e <punkt_końcowy> dla adresu URL serwera.
-u <użytkownik> i -p <hasło> dla połączenia z serwerem.
-t <typ> (opcjonalne) w celu określenia typu serwera. Wartością domyślną jest pod_ec.
Łącząc się z dzierżawą Oracle Content Management w publicznej chmurze Oracle, należy używać jedynie typu pod_ec.
Na przykład poniższe polecenie służy do zarejestrowania serwera będącego dzierżawą w publicznej chmurze Oracle:
cec register-server DEV -e https://DEV.example.com -u user1 -p <password>
Poniższe polecenie służy do zarejestrowania autonomicznej rozwojowej instancji Oracle Content Management:
cec register-server DEV -e https://DEV.git.oraclecorp.example.com -u user1 -p <password>
Po zarejestrowaniu serwera Oracle Content Management można wyszczególnić jego zawartość, używając polecenia cec list z zestawu Toolkit.
Poniższe polecenie służy do wyszczególnienia zawartości serwera rozwojowego:
cec-compontents> cec list -s DEV - Logged in to remote server: <host:port> Channels: Name Token StarterSite <site-id> Components: Name Type Published FooterBar Component group StarterComponent Local component StarterFooter Component group StarterNavMenu Local component Localization policies: Name Required languages Optional Languages en-US en-US Repositories: Name r Sites: Theme Type Published Online Name StarterSiteTheme Enterprise Templates: Name Theme Type StarterTemplate StarterTheme Standard
Wysłać szablon serwisu do serwera rozwojowego, po czym utworzyć serwis, używając tego szablonu.
Szablon serwisu można utworzyć za pomocą polecenia cec create-template, po czym można wysłać uzyskany szablon do serwera rozwojowego. Można wówczas utworzyć serwis z szablonu, używając polecenia cec create-site. Poniższe polecenia służą do utworzenia i wysłania szablonu:
- cec create-template blog -f BlogTemplate - cec upload-template blog -s DEV
Poniższe polecenie służy do utworzenia — z wysłanego szablonu — serwisu o nazwie blog:
cec-components> cec create-site blog -t blog -r r -l "en-US" -d "en-US" --server DEV - Logged in to remote server: <https:<host:<port> - establish user session - get template - get repository - get localization policy - creating enterprise site . . . name blog template blog site prefix blog repository r localization policy en-US default language en-US - submit create site site - create site in process: percentage 95 - create site in process: percentage 95 - create site in process: percentage 95 - create site in process: percentage 95 - create site in process: percentage 95 - site created
Opublikować serwis i przełączyć go do trybu online na serwerze rozwojowym.
Po utworzeniu serwisu można go opublikować i przełączyć do trybu online, używając polecenia cec control-site:
cec-components> cec control-site Usage: cec contrl-site <action> Perform <action> on site in CEC server. Specify the site with -s <site> Specify the server with -r <server>. publish unpublish bring-online take-offline Options: --site, -s <site> Site --server, -r <server> The registered CEC server --help, -h Show help Examples: cec control-site publish -s Site1 Publish site Site1 on the server cec control-site publish -s Site1 -r UAT Publish site Site1 on the registered server UAT cec control-site unpublish -s Site1 -r UAT Inpublish site Site1 on the registered server UAT cec control-site bring-online -s Site1 -r UAT Bring site Site1 online on the registered server UAT cec control-site take-offline -s Site1 -r UAT Take site Site1 offline on the registered server UAT Not enough non-option arguments: got 0, need at least 1 cec-components> cec control-site publish --site blog --server DEV - Logged in to the remote server: https://<host>:<port> - establish user session - get site: runtimeStatus: offline publishStatus: unpublished - submit publish site - publish in process: percentage 20 - publish in process: percentage 40 - publish in process: percentage 49 - publish in process: percentage 49 - publish in process: percentage 50 - publish in process: percentage 50
Aby przenieść serwis ze środowiska rozwojowego (DEV) do środowiska testów akceptacyjnych (UAT), trzeba ten serwis spakować. Modelem pakowania, umożliwiającym przenoszenie serwisów między serwerami, jest szablon. Utworzyć nowy szablon z serwisu utworzonego na serwerze rozwojowym, po czym ten szablon pobrać.
Za pomocą polecenia cec create-template-from-site, użytego w poniższym przykładzie, jest z serwisu blog tworzony szablon o nazwie blog2.
cec create-template-from-site blog2 -s blog
Pobrać z serwera rozwojowego utworzony szablon, używając polecenia cec download-template:
cec-components: cec download-template blog2 --server DEV - Logged in to remote server: https://<host>:<port> - establish user session - export template - template download to /Users/<user-name>/devenv/git/webclient/developer/sites-toolkit/cec-components/dist/blog2.zip - the template will be at /Users/<user-name>/devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/templates/blog2 - the theme for the template will be at /Users/<user-name>/devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/themes/blogTheme - create link _scs_theme_root_ - create link _scs_design_name_ - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Author-Summary - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Post-Content - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Post-Header - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Post-Search-Result - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Post-Post-Sidebar - override component /Users/<user-name>devenv/git/webclient/developer/sites-toolkit/cec-components/src/main/components/Starter-Blog-Post-Summary - set themeName to blogTheme in siteinfo.json - unzip tmplate content file *** template is ready to test: https://localhost:8085/templates/blog2 cec upload-template blog2 --server UAT
Wysłać szablon w celu utworzenia typów zawartości i map układów zawartości.
cec upload-template blog2 --server UAT
Wysłać szablon, wykluczając z niego elementy zawartości (szablon zawartości).
cec upload-template blog2 --server UAT -x
Takie postępowanie ma na celu utworzenie serwisu z zawartością mającą identyfikatory GUID identyczne z występującymi w oryginalnym serwisie. Jeśli serwis zostałby utworzony z szablonu z zawartością, to cała zawartość w nowym serwisie miałaby nowe identyfikatory GUID. Ponieważ chcemy zezwolić na aktualizację zawartości (a nie tworzenie nowej), trzeba wykluczyć zawartość z szablonu.
Utworzyć serwis z szablonu.
cec create-site blog -t blog2 -r r -l "en-US" -d "end-US" --server UAT
Wysłać szablon zawartości do kanału i kolekcji serwisu. Trzeba to zrobić, ponieważ szablon zawartości został wykluczony (w punkcie 7) z szablonu serwisu.
cec upload-content blog2 -t -r r -c blog -l "blog site" --server UAT
Opublikować serwis i przełączyć go do trybu online na serwerze testowym.
Opublikować serwis i przełączyć go do trybu online, używając polecenia cec control-site:
cec-components> cec control-site publish --site blog --server UAT - Logged in to the remote server: https://<host>:<port> - establish user session - get site: runtimeStatus: offline publishStatus: unpublished - submit publish site - publish in process: percentage 20 - publish in process: percentage 40 - publish in process: percentage 49 - publish in process: percentage 49 - publish in process: percentage 50 - publish in process: percentage 50 - publish blob finished
Jeśli na serwerze DEV zostaną dokonać jakieś zmiany w serwisie blog, można przeprowadzić ich propagację do serwisu utworzonego na serwerze UAT.
Utworzyć kolejny szablon z serwisu (aby szablon zawierał dokonane zmiany).
cec create-template-from-site blog3 -s blog --server DEV
Pobrać szablon.
cec download-template blog3 -s DEV
Wysłać szablon, po czym — aby przeprowadzić propagację zmian do środowiska testowego — utworzyć z tego szablonu serwis.
cec upload-template blog3 -s UAT
To polecenie tworzy lub aktualizuje wszelkie składniki i motywy, które zostały zmienione, lecz wyklucza zawartość.
Użyć polecenia update-site, aby wydzielić zawartość i zaktualizować strony.
cec update-site blog -t blog3 - UAT
Na przykład:
cec-components> cec update-site blog -t blog3 --server UAT Updating site: blog3 - Logged in to remote server: https://<host>:<port> - pages : updating file# 6 of 6 files - content : updating file# 3 of 3 files - System Files : updating file# 5 of 5 files - controller : no files in update, removing files on server - favicons : no files in update, removing files on server - misc : no files in update, removing files on server - seo : no files in update, removing files on server - system : no files in update, removing files on server - created content file /Users/<user-name>/devenv/git/webclient/developer/sites-toolkit/cec-compnents/dist/blog3_export.zip - upload content file - get CSRF token - submit import job, updating content - import job in progress. . . - import job in progress. . . - import job in progress. . . - content imported: Update Site Results: - Site Pages : completed with 0 errors. - Embedded Content : completed with 0 errors. - System Files : completed with 0 errors. - Settings Files : completed with 0 errors. - Content Update : completed with 0 errors.
Sprawdzić serwis, aby upewnić się, że zmiany zostały wprowadzone.
Przeprowadzić propagację z serwera UAT do serwera PROD, postępując jak przy przenoszeniu serwisu z serwera DEV do UAT.
Utworzyć serwis na serwerze produkcyjnym, przełączyć serwis do trybu online, po czym sprawdzić zmiany.
Można, używając polecenia cec list — wyszczególnić zawartość serwisu produkcyjnego i upewnić się, że zawiera zmiany, które zostały dokonane w środowisku rozwojowym. Można także sprawdzić serwis, aby potwierdzić propagację zmian do wersji produkcyjnej.