DG Git Version Control in Pricefx

Pavel Matyasko - pavel.matyasko@pricefx.com - Version 21.06

Table of Contents

Estimated time to read: 30 minutes

Why do we use Git

source of truth
- every finished feature/user-story must be resident in Git
- if there’s a difference between Git and partition content, Git is expected to have the correct version
versioning of project configuration
cooperation of several developers on the project
used for deployment of project to the partition

What files do we store to Git

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

Files we version

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

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 developer 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’re 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.

Branches

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

Partitions

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.

Branches vs. Partitions

You will notice that branches do not match exactly to partitions. Specifically, the dev and feature/XXXX-XXXX branches are sharing 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 one to one relation could be 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 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 don’t 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 situation exists since there is no way to use the previous release without the partition. A release commit can be tagged with a release name.

References

Knowledge Base

Pricefx Git Best Practices

External Sources

GitFlow