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
Image Removed
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:
Property Tax
Trade License
PGR
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
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.