Step 2-Local Development

In this section:

Step 1 - Check Your Rights in Gitlab (Optional)

You should have assigned required rights in the relevant project.

Step 2 - Check out Project Locally

As you are part of the project now, you need to create an access token to your account:

Now, clone the project to your local machine:

git clone https://xxx:yyyy@gitlab.pricefx.eu/integration-k8s/int_dev_1/eu-west-1/pim-mst-2022-02-22-02

(The address is subject to change according to the project name and location.)

Open the project in IntelliJ Idea (or another IDE):

Now it is necessary to switch to a proper environment – we switched to dev:

⚠ The branch in the Git project is the same as environment in PlatformManager. In this example, we have environments dev and prod, so there are branches dev and prod.

Step 3 - Run Project Locally

Using the LocalAppRunner class, we are able to run the application:

You can see in the log that the route (defined in PlatformManager) is deployed and triggered.

Step 4 - Edit Route

In the project window, we have to navigate to the routes folder where all routes are stored. Now, we will edit the route:

When we run the application, you can see in logs that the route is deployed and triggered – the output confirms it.

Now, you can edit as needed in the resources folder – routes, mappers, connections, certificates, etc.

⚠ Any change in resources upon commit and push will result in applying this change to the environment.

⚠ Remote connections do not work locally – that is due to security reasons.

Step 5 - Commit Changes

Once done with changes, create a new feature branch and push your changes there:

Step 6 - Process Merge Request

To apply your changes to the environment, you have to create a merge request:

⚠ Check that reviewer is set and also target branch is set to the desired environment.

Once created, you can check the merge request also in PlatformManager:

Once the reviewer approves your changes, you can merge the request:

Merging the changes will result in an immediate change in the environment. If you do not want to “deploy” the changes immediately, you should merge later.

Step 7 - Check Changes in PlatformManager

As the merge finishes and the environment is updated, you can now see updated resources in PlatformManager. You can check the log that it contains the changes:

Overriding Connection Secrets (since 3.5.0)

Connection secrets (passwords) are not decrypted in local development environment, since the encryption key is not shared. If it is necessary to use connections during local development, you need to put passwords to the src/main/resources/local-secret.properties file. This file is git-ignored, so it is not pushed to Git.
Property format:
{<env>}.connections.<connection_name>.<property_name>=value

Example of local-secret.properties:

# this override is applied when running LocalAppRunner from dev branch
dev.connections.default-smtp-connection.password=password123

# this override is applied when running LocalAppRunner from other branches
connections.default-smtp-connection.password=password123

LocalAppRunner adds Spring profiles local, local_app_<env> automatically, where <env> is evaluated by reading .gitlab-ci.yml:variables/IM_PROFILE, and it represents the used environment/branch.

Overriding the connection property default-sftp-connection/password with the local property dev.connection.default-sftp-connection.password.

Overriding the connection property kukucon/password with the local property connection.kukucon.password (no specific environment is defined for this property, so get the common one).

Overriding Others Secrets (since 4.9.0)

Next to overriding connection properties, it is possible to override other properties in the application.properties file during local development. It works in a similar way.

Example: If you have a property sap-password=ENC{dsdssd} in application.properties and would like to override it for your local testing, just add sap-password=this-is-my-password to the local-secret.properties file and it will be overridden.