Git Version Control in Pricefx

Why We Use Git

• Used as source of truth.

  • Every finished feature / user story / bugfix must be stored in Git.

  • If there is a difference between Git and partition content, Git is expected to have the correct version.

• Provides versioning of project configuration.

• Allows cooperation of several developers on the project.

• Used for deployment of a project to the partition.

Base Requirements

• Git is used on every project.

• Whoever contributes to the configuration, must commit their changes to the project Git repo. This is valid even for resources from the customer.

• Each environment (DEV, QA, PROD etc.) should have a dedicated branch in the Git repo.

• Every finished feature / user story must be committed immediately after completion. Changes done in the partition only without committing to Git are not allowed (except for feature branch development described below).

• The actual version (of the configuration) should be possible to be deployed from Git to the partition at any point in time. That means that every commit to the branch should be deployed to the partition.

What Files Are Stored in Git

Generally, all project configuration must be in Git to facilitate potential recreation of the partition from scratch.

Files To Be Versioned

• 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 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 connecting Studio to Pricefx partition – particularly partition name and server URL. The username and password are stored in IntelliJ’s password safe store, not in the file.

Files NOT To Be Versioned

• Data

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

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

The only exception to the rule 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 Company Parameters, and Studio supports deployment of such CSV data to the Company Parameter table.

Interaction of Git with Other Tools

Let’s recap here how Git fits into the landscape and how it interact with other tools.

Local GIT repository:

• Stored on the developer’s computer (in .git folder under project working folder).

• Used regularly during day to store snapshots of the working versions of the project user stories or features.

Remote GIT repository:

• Stored on DevOps/Source Collaboration platform.

• Used for synchronization/cooperation among developers.

Pricefx Git Workflow

While implementing a solution, all developers should use the same common flow of work with Git. You can see all important aspects of the workflow in the picture.

If you are familiar with GitFlow, you will find this flow quite similar. The main reason for differences is that in Pricefx case, the configuration can only be tested against some partitions.

Note: Deployment to PROD is usually done during the GO LIVE preparation phase. This diagram demonstrates the situation mainly after GO LIVE and when additional sprints are planned, focusing on the master branch. During development, before the PROD environment is established, the master branch is not maintained. It should be set to the corresponding version once the PROD environment becomes available.

Branches

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

• qa – Stores version of the project deployed on QA server which is tested by the 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 user story 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.

Partitions

Every project has typically 3 partitions:

• customer – Partition name based on the customer name. It is used for production version of the project, and customer’s end-users use it daily.

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

• customer-dev – Partition used by the implementation and integration teams for testing of newly developed features / user stories.

Branches vs. Partitions

You will notice that branches do not exactly match partitions. Specifically, the dev and feature/XXXX-XXXX branches which share the same partition for testing purposes.

This is because it is not practical (and sometimes not even possible) to have one partition for each feature branch. One reason for not having a 1-1 one relation is the size of data you might need to replicate for each partition.

The development team should establish some rules regarding the dev partition. Thought should be given to how the team will share the dev partition, while testing different feature configurations, while not overriding one another’s configuration.

Pricefx "GitFlow"

When working in Git, a common flow should be used. GitFlow was considered but since there are some specifics to the Pricefx development, we adopted GitFlow with a few changes. The main reason for these differences is that the configuration can only be tested against some partitions.

Differences to standard GitFlow:

• hotfix branch is not really needed since we do not have a matching environment. Hotfixes therefore can be committed to the master branch.

• We do not use multiple release branches, we only use a single qa release branch holding the latest release. This is because there is no way to use the previous release without the partition. A release commit can be tagged with a release name.

Additional comments:

• 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.

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

Testing

Every feature needs to be tested during the development on the xx-dev partition. There are some limitations which can cause a clash in testing. The common cases are described here:

• Configuration engineer works on a completely new logic. => No problem since there is no conflict with others.

• Two configuration engineers work on the same logic. => Temporarily rename the logic by adding a suffix, e.g. author's username. This logic can then be assigned to e.g.  LPG, PL, dashboard etc., but should not be committed to Git! The name should be reverted back before committing.

• Two configuration engineers work on the same Groovy Library logic => Good communication in the team is the golden key in this case. Before developing the Groovy logic or deploying it to the xx-dev partition, do a fetch of the Groovy library from the partition first, so that you get the potential unfinished changes from your co-workers. You can also utilize the merge functionality in Studio (in the Fetch tool window) Then apply your changes there (e.g. from Stash) and then deploy changes together. Commit only your changes to Git once you are done.

Hotfixes

When a critical PROD bug is found after the project goes live, there needs to be a hotfix. The PROD hotfixes need to be tested and accepted by the customer. Since it is not possible to test on PROD once the customer is live, the hotfix needs to be developed and tested on QA, even though it can already contain features from the next sprint. In that case, there can be a gap in testing, since the testing will be done on a different configuration than on PROD. Unfortunately there is no other way to go around this, so you need to be extremely careful and individually evaluate if there can be a potential clash. Once the test is done on QA: 

1. It should be committed and deployed to PROD branch master.

2. The master branch needs to be merged into qa.

3. Then qa needs to be merged into dev.

Merging master to qa should be possible at any point in time and without conflicts. This is ensured by merging from qa to prod and not committing any commits directly to master.

Hotfixes are typically very small changes, if you want create a merge request, you can use a hotfix branch "hotfix/XXXX-XXXX".

See also Automated Deployment Using Pipelines.