TALY - The Allianz Library

Development Workflows

1. How to Test My Changes in a Generated Journey?

1.1. Use TALY Playground

We provide an application called playground inside the TALY workspace where you can test your changes locally by running

npx nx develop playground

This command will trigger the generate-and-serve executor implemented inside the taly-nx library directly. It will then generate the playground application based on the configuration files in the apps/playground/config folder. You can modify them to suit your use cases. Any changes in TALY libraries and configuration files will trigger a reload automatically.

💡 Keep in mind that since the playground application does not consume taly-nx or taly-sdk library at runtime, you must restart the npx nx develop playground command after making any changes to taly-nx and/or taly-sdk.

Test a Generated Web Component

There are two ways to test a generated web component:

Test the Generated Web Component Before It's Bundled

This approach is suitable for development. It is faster and allows for browser debugging.

For a regular web component, run:

npx nx develop playground --configuration webcomponent

For a runtime web component, run:

npx nx develop-runtime playground

Test the Web Component After It's Integrated into an App Shell

This approach can be used to check the final result of how your web component behaves inside an app shell.

For a regular web component, run:

npx nx start-wc playground

For a runtime web component, run:

npx nx start-wc-runtime playground

Open another terminal and run

npx nx start-shell playground

Access http://localhost:4502/

1.2. Regenerate Schemas

If your changes impact the schema, you should regenerate it. You can do this either through the NX Console in your IDE or by running the following CLI commands:

npx nx schema <project-name>

This command regenerates the schema for a specific project. Replace project-name with the name of the project you want to target (e.g. sdk). The schema target is defined in the project.json file of the respective project.

If you want to generate schemas for all projects, you can use this command:

npx nx run-many -t schema --all

Note: There is a pre-commit hook in place that ensures that the generated JSON schemas are always up to date, even if the schema command isn't run explicitly.

1.3. Use a Local TALY Package in Other Workspaces

In certain situations, testing your implementation inside the TALY workspace alone might not be enough. You can consider using the recipes workspace where there are multiple setups for different TALY features (e.g. web component integration, module integration, plugins). The best way to proceed is installing a package built locally.

First, let's build the library you want to test by running:

npx nx build <library-name>

Then go to the workspace that you want to test and install the recently built package:

# for workspace that uses yarn
yarn add <path to the built library e.g. ../../../taly-workspace/dist/libs/nx>

# for workspace that uses npm
npm i <path to the built library e.g. ../../../taly-workspace/dist/libs/nx> --install-links

💡 Note that --install-links flag should be used when installing a local package using npm. It ensures that npm will install a source copy of your package instead of a symbolic link

Every time you apply a change to the TALY package, you need to build and install the package again.

2. How to Test the Nightly Integration Tests with Locally-Built TALY libraries?

2.1. On your machine

  1. Apply the diff for the script to use the locally-built dependencies instead of the next version published in the registry:
git apply ci/integration-tests-resources/nightly-integration-tests-locally-built-taly-deps.diff
  1. Build all the TALY libraries with:
npx nx run-many --target=build --skip-nx-cache
  1. Go outside of the taly-workspace and run the tests:
cd .. && ./taly-workspace/ci/integration-tests-resources/nightly-integration-tests.sh

2.2. On Jenkins

Start on your local machine.

  1. Apply the diff for the script to use the locally-built dependencies instead of the next version published in the registry:
git apply ci/integration-tests-resources/nightly-integration-tests-locally-built-taly-deps.diff

  1. Comment out the sending of the last Slack message in ci/Jenkinsfile.nightly to avoid potential noise in the team channel if the pipeline fails.

  2. Push a test commit with those changes.

Now move to Jenkins.

  1. Create a copy of the nighly pipeline in Jenkins. Then, in the pipeline settings, point to your branch instead of main.

  2. Run the pipeline.

Once you are done, revert the commit you pushed before.

3. How to Test Trackify?

There are two ways to enable Trackify debug mode:

  1. Add the ?trackifydebug=true query param to the URL of any application.
  2. Open the browser console and type trackifyDebug=true.

You can choose either of these methods and begin interacting with the form elements to observe the tracking events being fired in the console.

4. How to Test TALY SDK?

The TALY SDK can be tested locally by running:

# build the package
npx nx build sdk

# execute the TALY SDK command
node ./dist/libs/sdk/src/cli/index.js <command> <options>

If you want to test it against other workspaces, please follow the steps in Use a Local TALY Package in Other Workspaces and run npx taly <command> <options>.

5. Nx Migrations

5.1. Local Testing of an Nx Migration

Follow these steps to run an Nx migration of a locally installed package manually.

  1. Create a migrations.json file in the root of the workspace. The content has to list the migrations that should run. For example:

    {
  "migrations": [
    {
      "package": "@allianz/taly-nx",
      "name": "update-policy-format",
      "version": "25.0.0",
      "implementation": "./src/migrations/update-policy-format/update-policy-format",
      "cli": "nx"
    },
    {
      "package": "@allianz/taly-nx",
      "name": "update-acl-defaults",
      "version": "25.0.0",
      "implementation": "./src/migrations/update-acl-defaults/update-acl-defaults",
      "cli": "nx"
    }
  ]
}

    The version mentioned in the migrations.json files do not have to match the version of the package.json file.

  2. Run it

NX_MIGRATE_SKIP_INSTALL=true npx nx migrate --run-migrations=migrations.json

results matching ""

    No results matching ""