Discussion Thread: Upgrading Production Instances of Axelor

We would like to start a discussion around the issues pertaining to upgrading Axelor in production.

We build and deploy from source to Docker for use in Kubernetes. We are attempting to create an automated CICD pipeline for our deployments. We are especially interested in migrating existing production databases to new versions as they are released using Liquibase. We intend to create test scripts to verify that the database has been migrated successfully. If the db migration is successful, we then intend to run automated testing on the UI.

Anyone who has any information about how to do this, or who would like the join the discussion, please feel free.

By « migrating existing databases » you mean updating the schema for the new version of Axelor. Is anyone actually using and supporting Axelor in the community? Or is the « community edition » perhaps incorrectly named?

Hi Michael, thanks for responding.

We want to upgrade from version to version, so « upgrade » is probably better than « migrate ».

To your question: Is anyone supporting Axelor in the community? Yes, but it seems to be dying down a little. However, I think ChatGPT can help pick up the slack…

Here’s what ChatGPT says about creating a baseline version of a database;

Creating a baseline version of a database using Liquibase, an open-source database schema change management tool, involves several steps. The baseline version represents the starting point for managing your database schema changes with Liquibase. Here’s how you can create a baseline:

  1. Install Liquibase:
    Ensure Liquibase is installed and properly configured on your system. You can download it from the official website.

  2. Database Setup:
    Make sure you have access to the database you want to baseline. It could be a development, testing, or production database.

  3. Create Liquibase Project:

    • Create a new directory for your Liquibase project.
    • Inside this directory, create a liquibase.properties file to store database connection properties, such as URL, username, password, etc.
  4. Generate ChangeLog:
    Liquibase can generate a changelog file representing the current state of your database schema. Run the following command:

    liquibase generateChangeLog

    This command will create a changelog file with the current database schema. The changelog file can be in various formats like XML, JSON, YAML, or SQL.

  5. Review and Edit ChangeLog:

    • Open the generated changelog file.
    • Review and make any necessary edits. You may want to organize or simplify the changes, add context or descriptions, etc.
  6. Create Baseline:
    Once you’re satisfied with the changelog, you can create a baseline. This step is crucial if the database was already in use before adopting Liquibase. You can use the changelogSync or changelogSyncSQL command, which marks all changes in the changelog as executed in your database without actually applying them. This sets the baseline.

    liquibase changelogSync
  7. Version Control:
    It’s a good practice to put your changelog file(s) under version control. This way, you can track changes over time and collaborate with others.

  8. Future Changes:
    From this point forward, any new database changes should be added as new changesets in your changelog file. Liquibase will manage these changes, ensuring your database schema is version controlled and changes are applied consistently.

Remember, the above steps are a general guide. Depending on your specific environment, database, and requirements, you might need to adjust some steps. Also, always make sure to backup your database before making significant changes like establishing a baseline.

Perhaps we can just add some community-sourced documentation here.

Very interesting, for me it would be necessary to automate the recovery of database changes, so as not to have to do it manually.

Definitely. Using Liquibase, it should be relatively easy to add this to a CICD pipeline in Jenkins. You would just keep adding ChangeSets to the master.xml file as new versions are created.

Does anyone else have any experience with doing this with Axelor?

1 « J'aime »