Page Comparison

• egov-accesscontrol
• egov-common-masters
• egov-commondata-workflowuploader
  egov-dataenc-uploaderservice
  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
  useregov-otptelemetry
  egov-user
  egov-workflow-v2
  libraries
  report
  tenant
  
• telemetry
• telemetry-kafka-streams

Image Removed

• user-otp
  zuul

Business Modules:

• egovbilling-hrmsservice
• collection-servicesbilling-service
• egf-instrument
• egf-masteregf-account-details
• egov-apportion-service
• egov-hrms
• finance-collections-voucher-consumer

• 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.

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

• 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

• Property Tax

• Trade License

• 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 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

Config-Files: (Common)

• Seed files
• Migration files 
• Persister  – Service repo
• Indexer - Service repo