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:(Ranjeet's doc)
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.
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.
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:
hrbilling-employeeservice
collection-v2serviceshr
egf-mastersinstrument
egf-v2mastercollection
egov-servicesbillingapportion-service
egfegov-instrument
egf-master
Image Removed
hrms
finance-collections-voucher-consumer
Image Added
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 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 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
Libraries: DONE
mdms-client
tracer
services-common
enc-client
Image RemovedImage 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
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.
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
Web: Frontend (CommonUI):
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.
The repository hosts sidecar modulesextensions 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.