Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-76478

Tools to move updates on configuration/code/data from one environment to the other



      In short the question is do we provide tools for large enterprises to move updates on configuration/code/data from one environment to the other?

      We've had a conversation with a large enterprise where they struggle with keeping things in sync as automatic as possible.

      – Customer questions –
      1. How can we move updates in the configuration from DEV to QA to PROD? e.g. mails-server-settings.
      2. How do we move update to code/modules from DEV to QA to PROD?
      3. How do we make changes in a controlled way on data changes, e.g. additional fields/tables in the database.

      – LR response from the field –
      We are trying to create some of these practices with Docker/Jenkins/Maven for a customer. What we are doing is to create a pipeline in Jenkins which compiles and generates new artifacts (JARS/WARS) as soon as there's a commit. Then we deploy it to some directories in Nexus and we restart Docker from the affected level (we have a multi-level Docker File (SO, APPSERVER, LIFERAY, FIXES, DEVELOPMENTS)). Then the new Docker Image (not the Docker File) gets generated and running in INT and also pulled into a Docker Registry.
      Now we can replace Docker Image in PRE and PRO (in a controlled way, with a manual intervention as it is PRE and PRO, not with CI/CD) with the one already generated in Docker Registry.
      So we can assume that the three enviroments use same Docker Image. We also need a way to send configuration stuff (portal-ext.properties, *.config, etc.) to the Docker before start (Enviroment Variables and so on). Of course all of the files are stored in GIT (DockerFiles, Configuration Files, etc.)

      In our case the configuration is stored in a Git repo in three folders per customer request (INT, PRE, PRO), and the appropriate configuration gets pushed into the Docker image at runtime via a shared volume. We integrate code and base software in the Docker image, and whatever is variable gets pushed at runtime, so we can have the same software stack across environments and only change the config.

      Worst case is a DB backup of PROD and restore in DEV or the other way around.

      Be aware of data privacy issues when moving data from PROD to QA/DEV (GDPR is coming soon!).

      – Customer response –
      As to the questions I had shared with SE, I understand the attempts to help a customer setting this up. But, I would be interested to know/learn whether this will be "productized" and offered as a capability to other customers. By the way, we are preparing for GDPR, so thanks for the heads up.




            david.truong David Truong
            jan.verweij Jan Verweij
            0 Vote for this issue
            1 Start watching this issue




                Version Package