Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Configuration

    • Tables definition metadata, e.g. folders:

      • PricingParameter

      • ProductAttribute

      • ProductExtension

    • Logics definition and Groovy code, e.g. folders:

      • CalculationLogic

      • Workflow Formula

    • Configuration settings, e.g. folders:

      • AdvancedConfiguration

      • Preference

      • QuoteType

      • SavedChart

  • Project settings

    • .gitignore – This is vital, so that developers do not accidentally commit files not relevant to the Pricefx project.

    • pom.xml – This file is vital for standard work using the Fetch/Test/Deploy actions and adding Groovy API. This file can be generated by the Pricefx studio plugin.
      Note: The Project Object Model file (POM) is an XML file that contains information about the project and configuration details used by Maven to build the project. We use it for referencing of our unit testing (TDD4C) libraries and for Studio debug functionality.

    • config.json – This file should generally be in the version system.
      Beware: The previous version of the file – config.groovy – should never appear in the version control because it contains information which is specific per developer.
      Note: config.json contains information for connection of connecting Studio to Pricefx partition – particularly partition name and server URL. The username and password is are stored in IntelliJ’s password safe store, not in the file.

...

  • For the PROD environment the master branch is used.

  • The feature branches should be merged to dev using merge requests. It is recommended to rebase the feature branches before merging (using a button in the GitLab merge request) and possibly squash them (a checkbox at GitLab web), especially if there is a lot of intermediate commits. Always add the Solution Architect and/or other engineers on the project as reviewers for the merge request (so that everyone in the technical team is aware of this development change) and require at least 1 approval before merge.
    This guideline does not apply when the developer is the only technical person on the project.

  • The cherry Cherry picking is not recommended at all, we should use merge when making the releases. If the customer is asking asks to take single features from QA to PROD, this should be avoided.

...