...
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.
...
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 not needed vital for standard work using the Fetch/Test/Deploy actions , but it is a good practice to have the file in the project anywayand 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 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: 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 IntelliJIntelliJ’s password safe store, not in the file.
Files NOT To Be Versioned
...
Let’s recap here how Git fits into the landscape and how it interact with other tools.
...
Local 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. So when it comes to the master branch, this 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.
...
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:
...
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.
Hotifxes Hotfixes are typically very small changes, if you want create a merge request, you can use a hotfix branch "hotfix/XXXX-XXXX".