State Level: - MDMS - Config -- state level seed files - Additional module customizations - Front-End-UI
...
Platform Repos:
Repo Structure
Branching Strategy
Review Process
Core: (Private)
egov-accesscontrol
egov-common-masters
egov-common-workflow
egov-data-uploader
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
user-otp
egov-user
tenant
telemetry
telemetry-kafka-streams
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 workflowis 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.
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:
hr-employee-v2
hr-masters-v2
collection-services
billing-service
egf-instrument
egf-master
Feature modules:
pt-calculator-v2
pt-services-v2
tl-calculator
tl-services
rainmaker-pgr
Master branch holds the core code and will maintain it own release and review cycle.Modules
Developers 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
short-lived feature & hotfix branches which are then merged onto master via PR.
Forking workflowis 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.
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
Sidecar / Custom modules:
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 sidecar modules 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.
Libraries:
mdms-client
tracer
services-common
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.
The repository hosts common libraries which are used across core and business modules.
The modules hosted in the repo are usually built and artifacts published to Nexus / Artifactory which are then re-used by other modules.
Artifacts release and versioning strategies to be followed strictly.
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
MDMS 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
Feature modules:
Property Tax
Trade License
PGR
Unlike other repos listed in this document, a separate repo will be maintained for each of the feature modules like Property Tax, Trade License etc.
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 createspull requestandonly code-ownerschecks & approves merge to master. Everyone else can still comment.
Can elect
state specific who will be gatekeepers.JSON format check
thecode-owners
/ implementation team
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.
based on tech/files or overall code base and architectural knowledge.
Code quality check withcodacyis mandatory and runs as part of every pull request.
Config-Files: (Private)
Seed files
Migration files
Persister
Indexer
WIP: should be used when there are subsequent commits
JIRA ticketshould be prefixed as a topic name for the PR
Anticipated PRs and the relevant discussions could be discussed on the dailySCRUM meetings.
- Authors, Reviewers, peers, approver
InfraOps: (Private)
Kubernetes manifests
Infra configs
nginx config
kibana config
Dockerfiles
Jenkins
The repository will contain all devops related source code (gitopsGitOps) such as kubernetes manifests, configs etc.
Each state State or individual deployment config is deployments is handled by a single 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.
The repository hosts sidecar modules 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.