Overview of the DXP Cloud Deployment Workflow¶
DXP Cloud provides a robust framework for achieving a highly efficient CI/CD strategy. With Git and Jenkins integrations, you can automatically trigger CI builds that you can then deploy to project environments. Alternatively, you can skip the CI service’s build process altogether and directly deploy local changes to project environments using the Command Line Interface (CLI) tool.
Although there are multiple paths for deployment, workflows generally follow these three stages:
Develop and Configure¶
All workflows begin with making changes to your project’s Git repository (i.e., GitHub, Bitbucket, or GitLab). This repository serves as the basis for any custom additions to your project, including the Liferay DXP service instance itself. This Git repository provides shared version control for configuration and customization of project services, a single source of truth for project deployments, and a shared workspace for building DXP modules, themes, and extensions.
Configure a service’s LCP.json file, or make environment-specific and project-wide changes to a service via its
configs/ folder. To learn more about each service’s configuration options, see their respective documentation:
Build and Test¶
Depending on the configuration of your project’s Git repository, you can trigger automatic CI builds by merging commits into your project’s central repository or opening a new pull request with your changes. While this process is automatic, you can modify the CI service in the
infra environment to include additional pipeline steps, including testing. See Continuous Integration for more information.
To access a full history of builds across all project environments, navigate to the Builds page in the DXP Cloud console. Here you can view all builds initiated by either the CI service or CLI tool, along with their general information and status (i.e., pending, passed, or failed).
With DXP Cloud, there are three ways to deploy services: deploying via the CLI tool (manually), deploying via the DXP Cloud Management Console (manually), or configuring certain CI builds to deploy automatically.
Option 1: Deploying Through the Command Line Interface¶
Using the CLI tool is the quickest way to deploy local changes to a service. With it, you can deploy from your terminal and skip pushing your changes to a remote repository or triggering a Jenkins build altogether. However, unlike other deployment methods, the CLI tool can only deploy local changes for one service at a time.
To do this, log in to the CLI tool in your terminal, and navigate to the folder for the service you want to deploy. Then, initiate the deployment process by running
lcp deploy, and select which project and environment to deploy to (e.g.,
prd). For the deployment to be successful, you must have permissions to deploy to the chosen environment. See Deploying Changes via the CLI Tool for a walk through of this deployment workflow.
While you can directly deploy backup, CI, database, search, and webserver services, you must first create a gradle build of the Liferay service before running the
lcp deploy command. See Deploying to the Liferay Service for more information.
Option 2: Deploying From the DXP Cloud Console¶
The DXP Cloud console is the primary way for deploying changes to your project. With it, you can view and select from successful builds and deploy them to the environments of your choice. These include builds generated by both the CI service and CLI tool and can be accessed via the Builds page in the DXP Cloud console. See Deploying Changes via the DXP Cloud Console for a walk through of this deployment workflow.
Option 3: Automatically Deploying Builds to
If desired, you can set up your CI service to automatically deploy builds to your project’s
dev environment. Add an environment variable to the CI service that initiates automatic deployments for builds made from your specified branch. See Setting Up Automatic Deployment for more information.