Existing mono-repo is fattened, need to break it down into multiple mono repos and structure it to manage the open-source and the internal developer community.
Need a simple and efficient branching strategy to handle core and state-specific changes.
Enhance the code-review through pull requests.
...
Proposed Repository Structure:
We will have a repository structure same as our layered architecture. We will have multiple repositories divide into followings:
1. Corecore/Infra 2. Business services [Collections, Billing etc] 3. Individual Modules Municipal services[PGR,PT, TL, FNOC etc] 4. MDMS (Application Bootstrapping Configs) 5. Front end (Single Repository with multiple module wise folders) 6. Config (Any other configurations - Centralised) 7. Seed files for products 8. Config files for persister, indexer, report 9. Libraries [Tracer, mdms-client etc] 10. Docs → Swagger/Open API contracts, web sequence diagrams etc.
State Level: - MDMS - Config -- state level seed files - Additional module customizations - Front-End-UI
No other branches except MASTER, no state specific branch here
user-otp zuul
Image Added
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. Everybody should still be using branches to isolate individual features
3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.
Anything in MASTER is deployable, all CI/CD pipelines are only from master.
Image RemovedImage Added
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-v2billing-service
collection-services
billing-service
egf-instrument
egf-master
Feature modules:
pt-calculator-v2
pt-services-v2
tl-calculator
tl-services
rainmaker-pgr
collection-receipt-voucher-consumer +CE
water wtms +CE
severage stms +CE
BPA/DCR +CE
finance +CE
Image Removed
egov-apportion-service
egov-hrms
finance-collections-voucher-consumer
Image Added
Master branch holds the core /common code and will maintain it own release and review cycle.
State branches are create from the master and continue as an isolated and specific custom code.
Needing the reusable components, there could be the PR to share the code b/w Master & States.
There should be a codeowners who maintains master branch
State teams also have designated codeowners including the 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.
Image Added
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
Image Added
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.
Image Added
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 createspull requestandonly code-ownerschecks & approves merge to master. Everyone else can still comment.
Can elect thecode-ownersbased on tech/files or overall code base and architectural knowledge.
Code quality check withcodacyis mandatory and runs as part of every pull request.
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) 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/webDone
Core
Business
Features
Web
Mob
Option to have it published in confluence
WebFrontend (UI):
citizen
employee
employee-tradelicence
ui-uploader
report
Image Removed
Mob: (Android)Frontend (Mobile):
PuraSeva, AP Municipal
PGR, mSeva
Image Removed
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.
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.
