Page Comparison

Git Basics

...

– External Resources

• Essential Git

• Git for Beginners

Why

...

Use Git

• source Source of truth

  • every Every finished feature / user - story must be resident is stored in Git

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

• versioning Versioning of project configuration

• cooperation Cooperation of several developers on the a project

• used for deployment of Used to deploy a project to the a partition (manual manually or automaticautomatically)

What

...

Files to Store in Git

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

Versioned Files

...

• configurationConfiguration

  • tables Tables definition metadata, e.g. folders:

    • PricingParameter

    • ProductAttribute

    • ProductExtension

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

    • CalculationLogic

    • Workflow Formula

  • configuration Configuration settings, e.g. folders:

    • AdvancedConfiguration

    • Preference

    • QuoteType

    • SavedChart

• project Project settings

  • .gitignore - this – 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. – 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. 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.

  • config.json - this – This file should generally NOT be in the version versioning system, but as it does not contain any sensitive information, it could be beneficial for the team members to share this file too. Beware: Note that the previous version of the file - (config.groovy - ) should never appear in the version control, because it contains information which is specific per to a specific developer. The config.json contains information for connection of connecting Studio to a Pricefx partition - – particularly partition name and server URL. The username and password is stored in IntelliJ, not in the file.

Not Versioned Files

...

• dataData

  • data Data are managed by customers, so we do not store it in the version control system due to their size and volativityvolatility.

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

• exception to the rule

  the

  Exceptions

  • 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 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 interacts with other tools.

...

Local GIT repository:

• stored Stored on developer computer (in .git folder under project working folder)

• used regularly during day Used on daily basis to store snapshots of the working versions of the project user stories or features

Remote GIT repository:

• stored Stored on DevOps/Source Collaboration platform

• used Used for synchronization/cooperation among developers

...

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

If you’re 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.

...

Branches

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

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

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

• feature/XXXX-XXXX - keeps – Keeps project version specific for development of one User Story user story or Featurefeature. Each UserStory user story or Feature 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 typically partitions:

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

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

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

...

You will notice that branches do not match exactly to partitions. Specifically, the dev and feature/XXXX-XXXX branches are sharing 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 one to one relation could can be 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 another’s somebody else’s configuration.

Pricefx "GitFlow"

...

• hotfix branch is not really needed since we don’t 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 situation exists since is because there is no way to use the previous release without the partition. A release commit can be tagged with a release name.

References

...

...