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.
...
State Level: - MDMS - Config -- state level seed files - Additional module customizations - Front-End-UI
New structure:
Repo Structure
Branching Strategy
Review Process
Core:
egov-accesscontrol
egov-common-masters
egov-common-workflow
egov-custom-consumer
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
Image Modified
No other branches except MASTER, no state specific branch here
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 Modified
Everyone creates pull request and only code-owners checks approves merge to master.
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
collection-receipt-voucher-consumer +CE
water wtms +CE
severage stms +CE
BPA/DCR +CE
finance +CE
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 and states.
There should be a codeowners who maintains master branch
State teams also have designated codeowners including the
