Home

Project Folder Structure

├── src
│   ├── task_generator
│   ├── loadflow_engine
│   │   ├── model_validator
│   │   ├── model_merger
│   │   └── model_scaler
│   ├── model_publisher
│   ├── report_publisher
│   └── common
│       ├── settings_module
│       ├── logging_module
│       ├── xslt_engine
│       └── integrations
│           ├── opdm
│           ├── qas
│           ├── minio
│           └── elastic
├── docker
│   ├── task_genrator
│   ├── model_validator
│   ├── model_merger
│   ├── model_scaler
│   ├── model_publisher
│   ├── report_publisher
│   ├── model_retriever (OPDM -> ELK/MINIO)
│   └── schedule_retriever (EDX -> ELK/MINIO)
├── config
│   ├── task_genrator
│   ├── model_validator
│   ├── model_merger
│   ├── model_scaler
│   ├── model_publisher
│   ├── report_publisher
│   ├── model_retriever (OPDM -> ELK/MINIO)
│   └── schedule_retriever (EDX -> ELK/MINIO)
├── package.json
├── package-lock.json
├── readme.txt
└── .gitignore

Branching guidelines

Gitflow is an alternative Git branching model that involves the use of feature branches and multiple primary branches. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete.

Branch types

• Regular branches:
  • main/master - branch stores the official release history (convenient tag all commits with version number).
  • dev - branch serves as an integration branch for features.
• Temporary branches:
  • Feature - feature branches use dev as their parent branch. When a feature is complete, it gets merged back into dev. feature branches are generally created off to the latest dev branch.
  • Release - Once dev has acquired enough features for a release, you fork a release branch off of dev. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Then branch is merged to main and back to dev.
  • Hotfix - branches are used to quickly patch production releases. They are based on main branch. As soon as the fix is complete, it should be merged into both main and dev.
  • Or any other ad-hoc purpose branch.

Branch naming convention

• Start branch name with group word like bug or WIP (work-in-progress); e.g. bug-logo-alignment-issue
• Use Unique ID in branch names if issue tracking system is used; e.g. wip-8712-add-testing-module
• Use Hyphen (-) separators that will increases the readability and helps to avoid confusion
• Use author name if necessary; e.g. rajeev.bera_feature_new-experimental-changes
• Avoid using all naming convention simultaneously
• Avoid long descriptive names for long-lived branches