You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 19
Next »
Background
- 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.
Relevant data
Proposed Repository Structure: ()
We will have a repository structure same as our layered architecture. We will have multiple repositories divide into followings:
1. Core/Infra
2. Business services [Collections, Billing etc]
3. Individual Modules [PT, TL etc]
4. MDMS
5. Front end (Single Repository with multiple module wise folders)
6. Config
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
| Repo Structure | Branching Strategy | Review Process |
|---|
- 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 workflow is 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: | - 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 workflow is 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
|
Libraries: DONE - mdms-client
- tracer
- services-common
| 
- 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.
|
- 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
|
- 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 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 |
|
|
|
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/web Done - 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.
| https://levelup.gitconnected.com/using-pre-commit-and-pre-push-git-hooks-in-a-react-project-6c83431ef2bd |
Config-Files: (Common) - Seed files
- Migration files
- Persister – Service repo
- Indexer - Service repo
| |
|
|
|
|
State or Implementation Team Repos:
| Repo Structure | Branching Strategy | Review Process |
|---|
State Extentions: - 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 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.
|
Action items
- Branching strategies graphs
- All repositories are to be private?
- Digit open source fork from private repo
- namespace sidecar
| Task | Notes |
|---|
| 1 | Break the repos as per the above and duplicate into the same or new org |
|
| Create a POC with the |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Outcome
