Page Comparison

...

Estimated time to read: 30 minutes

Why do we use Git

...

• 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 - The POM file is not needed for standard work using the Fetch/Test/Deploy actions, but it is a good practice to have the file in the project anyway. This file can be generated by the Pricefx studio plugin.
    

    Code Block

    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’s

    debug

    functionality.

  • config.json - this file should generally NOT be in the version system, but as it does not contain any sensitive information, it could be beneficial for the team members to share this file too. 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.
    

    Code Block

    Note:

    the

    config.json

    contains

    information

    for

    connection

    of

    Studio

    to

    Pricefx

    partition

    -

    particularly

    partition

    name

    and

    server

    URL.

    The

    username

    and

    password

    is

    stored

    in

    IntelliJ,

    not

    in

    the

    file.

Files we do NOT version

• data

  • data are managed by customers, so we cannot have them in the version control system

  • backup of data is always in the database backup of the server

• exception to the rule

  • the only exception is the data used as "project/partition settings", which are managed by the solution implementation team (not by customer) and are not changed regularly

  • such data are usually stored in Price Parameters, and Studio supports deployment of such CSV data to the Price Parameter table

...

• master - used to store production version of the project. This version is also deployed on Production partition.

• qa - stores version of project deployed on QA server and being tested by customer. This version is also deployed on QA partition.

• dev - the latest working version of development with all finished features.

• feature/XXXX-XXXX - keeps project version specific for development of one User Story or Feature. Each UserStory or Feature (usually one JIRA ticket) should be versioned in one feature branch. The JIRA ticket number is then used as the name of the feature branch (the ticked ID is represented here by XXXX-XXXX) Every feature needs to be tested during the development on the customer-dev partition

...

Every project has commonly 3 partitions:

• customer - partition named based on the customer name. It is used for production version of the project, and customer’s end-users are using it on daily operations.

• customer-qa - partition with suffix "-qa" is typically used for UAT (User Acceptance Testing) of new features by customer

• customer-dev - partition used by implementation and integration team for testing of newly developed features/user stories.

...