New Git Strategy

• egov-accesscontrol

• egov-common-masters

• egov-data-uploader
  egov-enc-service
  egov-filestore
  egov-idgen
  egov-indexer
  egov-localization
  egov-location
  egov-mdms-service
  egov-notification-mail
  egov-notification-sms
  egov-otp
  egov-persister
  egov-pg-service
  egov-searcher
  egov-telemetry
  egov-user
  egov-workflow-v2
  libraries
  report
  tenant
  user-otp
  zuul

Open

• Anything in MASTER is deploy-able, all CI/CD pipelines are only from master.

• Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.

• Forking workflow is a convenient way to share branches with 3rd party/open-source developers.

• 3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.

Open

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect the code-owners based on tech/files or overall code base and architectural knowledge.

• Code quality check with codacy is mandatory and runs as part of every pull request.

• WIP: should be used when there are subsequent commits

• JIRA ticket should be prefixed as a topic name for the PR

• Anticipated PRs and the relevant discussions could be discussed on the daily SCRUM meetings.

- Authors, Reviewers, peers, approver

Business Modules:

• billing-service

• collection-services

• egf-instrument

• egf-master

• egov-apportion-service

• egov-hrms

• finance-collections-voucher-consumer

Open

• Master branch holds the core code and will maintain it own release and review cycle.

• Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.

• Forking workflow is a convenient way to share branches with 3rd party/open-source developers.

• 3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.

Open

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect the code-owners based on tech/files or overall code base and architectural knowledge.

• Code quality check with codacy is mandatory and runs as part of every pull request.

• WIP: should be used when there are subsequent commits

• JIRA ticket should be prefixed as a topic name for the PR

• Anticipated PRs and the relevant discussions could be discussed on the daily SCRUM meetings.

- Authors, Reviewers, peers, approver

Libraries:   DONE

• mdms-client

• tracer

• services-common

• enc-client

Open

• Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.

• The repository hosts common libraries which are used across core and business modules.

• The modules hosted in the repo are usually built and artefacts published to Nexus / Artifactory which are then re-used by other modules.

• Artefacts release and versioning strategies to be followed strictly. 

Open

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect the code-owners based on tech/files or overall code base and architectural knowledge.

• Code quality check with codacy is mandatory and runs as part of every pull request.

• WIP: should be used when there are subsequent commits

• JIRA ticket should be prefixed as a topic name for the PR

• Anticipated PRs and the relevant discussions could be discussed on the daily SCRUM meetings.

- Authors, Reviewers, peers, approver

Municipal services:   DONE

• egov-user-event

• property-services

• pt-calculator-v2

• pt-services-v2

• rainmaker-pgr

• tl-calculator

• tl-services

• Modules are expected to have hooks through which state specific requirements can be met via sidecars rather than introducing the changes into the platform code-base itself.

• Each of the feature module repos are to contain some sort of deployment packaging to help implementation teams / partners get up and running quickly. (Helm is one such)

• States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.

• Such forked repositories can sync with upstream and stay up to date with the platform's releases.

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect the code-owners based on tech/files or overall code base and architectural knowledge.

• Code quality check with codacy is mandatory and runs as part of every pull request.

• WIP: should be used when there are subsequent commits

• JIRA ticket should be prefixed as a topic name for the PR

• Anticipated PRs and the relevant discussions could be discussed on the daily SCRUM meetings.

- Authors, Reviewers, peers, approver

InfraOps: (Private)   DONE

• Kubernetes manifests

• Infra configs

• nginx config

• kibana config

• Dockerfiles

• Jenkins

• The repository will contain all devops related source code (GitOps) such as kubernetes manifests, configs etc.

• State or individual deployments is handled by one file per deployment, which in turn affects all other manifests.

• States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect state specific code-owners / implementation team who will be gatekeepers.

Doc:Swagger/Contracts/web  Done

• Core

• Business

• Features

• Web

• Mob

• Option to have it published in confluence

Frontend (UI):

• citizen

• employee

• employee-tradelicence

• ui-uploader

• report

Frontend (Mobile):

• PuraSeva, AP Municipal

• PGR, mSeva

• Modules are expected to have hooks through which state specific requirements can be met via sidecars rather than introducing the changes into the platform code-base itself.

• States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.

• Such forked repositories can sync with upstream and stay up to date with the platform's releases.

• States also have the option to use their own UI while using our APIs alone.

https://levelup.gitconnected.com/using-pre-commit-and-pre-push-git-hooks-in-a-react-project-6c83431ef2bd

Config-Files: (Common)

• Seed files

• Migration files 

• Persister  – Service repo

• Indexer - Service repo

State Extentions:

• rainmaker-custom-service

• custom-js-css-injection

• egov-custom-consumer + CE

• collection-receipt-voucher-consumer +CE

• water wtms +CE

• severage stms +CE

• BPA/DCR +CE

• finance +CE

• The repository hosts extensions which exist to carry out state specific requirements but are not common enough to be part of the platform.

• This repository is entirely state specific and is not part of the platform.

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect state specific code-owners who will be gatekeepers.

MDMS Data :

• Role Actions

• Feature Module Masters

• Business Module Masters

• Tenant Data

• Location Data

• The repository contains various master data which enable the functioning of core and business modules.

• The config files in this repository are pulled into the deployment directly and hence it also makes sense to have a separate repo or branch for environments such as UAT & PRD.

• This repository is state specific and is not part of the platform, although a repo with sample data will be maintained for DEV & QA.

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect state specific code-owners / implementation team who will be gatekeepers.

• JSON format check is mandatory and runs as part of every pull request.

Config-Files: 

• Seed files

• Migration files 

• Persister

• Indexer

• The repository maintains a folder based structure and holds DB migration seed files, module specific config files.

• The config files in this repository are pulled into the deployment directly and hence it also makes sense to have a separate repo or branch for environments such as UAT & PRD.

• This repository is state specific and is not part of the platform, although a repo with sample data will be maintained for DEV & QA.

• Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.

• Can elect state specific code-owners / implementation team who will be gatekeepers.

1

Break the repos as per the above and duplicate into the same or new org

Create a POC with the