Versions Compared

Old Version 1

changes.mady.by.user Gajendran C (Unlicensed)

Saved on

compared with

New Version Current

changes.mady.by.user Gajendran C (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


Info

Add your comments directly to the page. Include links to any relevant research, data, or feedback.

...

Status
colourYellow
titleIn progress

...

Status
colourRed
titleHIGH
  

...


Page Properties


Target release2019-M1
Epic
Jira Legacy
serverSystem JIRA
serverIdf37df377-51a7-3f0b-bde6-77fa6960492d
keyEDOP-70
Document status
Status
colourYellow
titleINPROGRESS
Document owner

Gajendran C (Unlicensed)



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.

...

Proposed Repository Structure: 

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.

State Level:
- MDMS
- Config -- state level seed files
- Additional module customizations
- Front-End-UI

...


Platform Repos:

Repo StructureBranching StrategyReview Process
Core: 
  • egov-accesscontrol
  • egov-common-masters
  • egov-
common
  • data-
workflow
  • uploader
    egov-
custom
  • enc-
consumer
  • service
    egov-
data-uploaderegov-
  • 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
  • egov-
otp
  • telemetry
    egov-user
    egov-workflow-v2
    libraries
    report
    tenant

New branching structureImage Removed

No other branches except MASTER, no state specific branch here

  • user-otp
    zuul

Image Added

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

    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

    Business Modules:

    • billing-service
    • collection-services
    • egf-instrument
    • egf-master
    • egov-apportion-service
    • egov-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 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 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.

    Business Modules:

    • hr-employee-v2
    • hr-masters-v2
    • collection-services
    • billing-service
    • egf-instrument
    • egf-master

    Feature modules:

    finance +CE
    - Authors, Reviewers, peers, approver


    Libraries:   DONE

    • mdms-client
    • tracer
    • services-common
    • 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:   DONE

    • egov-user-event
    • property-services
    • pt-calculator-v2
    • pt-services-v2
    • rainmaker-pgr
    • tl-calculator
    • tl-services
  • rainmaker-pgr
  • collection-receipt-voucher-consumer +CE
  • water wtms +CE
  • severage stms +CE
  • BPA/DCR +CE



    • 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
    WebMob: (Android)


    Frontend (UI):

    • citizen
    • employee
    • employee-tradelicence
    • ui-uploader
    • report
    Image Removed

    Frontend (Mobile):

    • PuraSeva, AP Municipal
    • PGR, mSeva
    Image Removed


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

    Private

    Common)

    MDMS, MDMS client

    • Seed files
  • migration files ++ ap 
  • Persister
  • Indexer
  • JenkinsFiles ++ ap 
  • Dockerfiles ++ ap 
  • Tracers

    • Infra-services: (private)

    • zuul
    • nginx --- seperate config for each service
    • telemetry
    • telemetry-kafka-streams
    • rainmaker-custom-service
    • es
    • kibana

    Image Removed

    Action items

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







    State or Implementation Team Repos:

    Repo StructureBranching StrategyReview 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

    1Break the repos as per the above and duplicate into the same or new org

    		Create a POC with the 


















    Outcome