CI/CD utility for low-code solutions

Custom solutions can be developed in short iterations to maintain their integrity and versioning. This approach can be implemented using the Develop > Test > Production cycle. In this cycle, the solution goes through three stages, each of which is performed in a separate company: the dev company is used for development, the test company is used for testing, and the prod company is used for the operation of the finished solution.

This cycle is performed by using the principles of Continuous integration and Continuous delivery and deploy or CI/CD.

BRIX provides several tools that can be used independently of each other to implement the CI/CD approach:

• Low-code CI / CD) tool provides the exchange of components between companies from different environments based on standard export and import processes. All configuration is done in the ELMA365 interface. Two companies should be bound to each other. Then an exchange profile is created: configuration components are selected, the type of operation is specified, etc. The profile is saved, which allows the exchange operation to be performed several times. You can also compare the configurations of the two companies and analyze the results of the operation. The exchange process is performed in the background. For more information about the tool, see the Low-code CI/CD;
• elma365pm utility is an auxiliary independent command line utility used in conjunction with external version control and pipelines configuration services, such as GitLab. The utility allows you to export a company configuration component (workspace, module, or solution) to a file. The work is then performed in an external service, thus making it possible to use operations from high-code development. The component is updated to a new version, packed into a file, and imported into another company.

This article describes the main principle of working with the elma365pm utility and available commands.

Download utility

Use these links to download the elma365pm utility for various operating systems, compatible with BRIX SaaS deliveries and the latest version of BRIX On-Premises:

• Linux;
• Windows;
• macOS (Intel x64 architecture);
• macOS (ARM x64 architecture), M1 processor).

After downloading, unpack the .exe file.

Available utility commands

The elma365pm utility is operated by running commands on the command line. Commands can be used with available flags. They are written after the command name.

After downloading the utility, you can request help information by executing the command:

elma365pm --help

To get detailed instructions on each command, run the following:

elma365pm <command> --help

The following features are currently available:

Utility features

Pay attention to the features of the elma365pm utility:

1. The utility cannot be used to export or import paid system solutions.
2. To export a solution with configured links to components of another solution,the --allow-deps соparameter with the value true is applied in the export command:

elma365pm export solution --token=TOKEN --host=https://dev-elma365.myorg
--out=my_solution --code=my_solution_code --allow-deps=true 

If you do not use the --allow-deps parameter or you set it to false, the solution with associated components will not be exported.

Utility use example

For example, the GitLab service is used as a source code storage and continuous delivery infrastructure. This is the most popular product with the ability to deploy its server in a closed loop.

Let’s consider the main stages of continuous delivery and deploy on the example of the Memos (Internal_Documents) solution.

1. The solution developer performs the work in the company with dev environment.
2. After development is complete, the solution must be uploaded to the repository folder in the file system. To do this, the following command is used:

elma365pm export solution --token=TOKEN --host=https://dev15-elma365.myorg
--out=Internal_Documents --code=Internal_Documents

The export and import token are created by the system administrator in Administration > Tokens.

After executing this command, the /Internal_Documents folder will contain the Memos solution files.

3. The developer then uses the git repository tools according to internal rules.

In our example, the developer commits the changes to a separate working branch  and pushes them to a shared repository on the GitLab service. Next, a request is created on the server in the working repository to merge its branch into the common develop branch.

4. After the developer branch is checked and approved, the merge is performed.
5. In the process of automatic solution delivery on the develop branch, the following is performed:

• packing the solution artefact into an .e365 file for testing:

elma365pm pack --src=procurement --out=dist/procurement.e365

• uploading the solution to a company with a test environment:

elma365pm import --token=TEST-TOKEN --host=https://test-elma365.myorg
--src=Internal_Documents --version-up --force

To ignore import errors and force an import, the --force flag is used in the example.

6. After testing, the solution is uploaded for operation in a prod environment company:

elma365pm import --token=PRODUCTION-TOKEN --host=https://elma365.myorg
--src=Internal_Documents --version-up

File structure of a solution

When you unpack the solution into files by using the elma365pm export command, you will see the structure of the solution in the target folder. As an example, we use the prebuilt business solution Memos.

File structure

The top level consists of service folders, as the system architecture is microservice-based. Each service folder usually has the manifest.json file and 2 folders entities and resources. The root also stores the package.json file that includes the main data of the exported solution or workspace.

Generally, there are three types of files in the structure:

1. Configuration files are .json files or files with no extension (that are also .json files). These files include information about apps’ fields and settings, as well as processes, widgets, and modules.
2. Script files are .ts files that contain the code of scripts from processes, widgets, and modules.

Script files are unpacked only for easy viewing and code review. The content of these files is not included into the package when the solution is imported.

Please note, that starting from version 2022.11 you can edit unpacked script files and use autocomplete files to make working in code editors more convenient.

3. Other resource and localization files are usually stored in the resources folder. Solution package localization is going to be considerably reworked, so now localization files are used only once during the import of a package. You can make changes directly to these files. They will be used to form a new package that can be imported with the utility.

Was this helpful?

Thanks for your feedback!

Please specify why:

Recommendations did not help meArticle is hard to understandDidn`t answer my questionContent does not match the topicOther

How we can improve it?

YesNo

Please specify whyRecommendations did not help meArticle is hard to understandDidn`t answer my questionContent does not match the topicOther