Versions Compared

Old Version 4

changes.mady.by.user Ken Sayers

Saved on

compared with

New Version Current

changes.mady.by.user Ken Sayers

Saved on

Key

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

...

Developing for openIDL

openIDL is an open source project.  We will follow best practices for such projects.

Info
titleGeneral Guidelines

This page describes the practices for developing / contributing to openIDL

All commits should correspond to an issue in the GItHub repository.

All commits should mention the issue number at the beginning of the commit.  Use the format

#8 Updated the x to fix y

All pull/merge requests must reference the issue number.

Pull Requests

All pull requests must be reviewed by someone other than the developer.

All pull requests require DCO - this requires local machine pull signoff and push.  Follow directions in the pull request DCO details.

Tagging and Versioning

Use github releases to manage the iterations of the project in the different branches.

See https://docs.github.com/en/github/administering-a-repository/releasing-projects-on-github/managing-releases-in-a-repository

GitFlow

Let's follow GitFlow: https://datasift.github.io/gitflow/IntroducingGitFlow.html

the branches are:

  • main - protected branch from which the UAT and Production builds are sourced
  • test - protected branch from which the integration test environment is built
  • dev - each developer has their own branch which may correspond to a cloud account

pull requests are used to promote from dev to test and from test to main

github actions are used to build, run unit tests, and deploy to the environment

README.md files provide help in. understanding each sub project and how to test it locally

the repository is a monorepo.  It holds all the different components in subdirectories.  Each one can be built and tested separately.

common components are developed following this process:

Info
titleCommon Component Development

Development on Local Machine

Create a branch

make update to the common code

make dependency from dependent code as relative path

run tests

commit to branch in git

Testing with Dependent Apps

identify all apps that are dependent and should be updated

for each we need to test them

pull the changed common component code

use relative path dependency

run tests

Deploying as Package

update version of common lib package.json

pull request

merge into main

CI/CD auto deploys new version to github packages

Update and retest dependents

for each dependent including original app that drove the change

update package.json to use the versioned dependency

rerun tests

commit and push updates to dependent app

pull request

merge

CI/CD auto whatever


DevOps Diagram

Technologies

Hashicorp Terraform

Blockchain Automation Framework

Sets up the blockchain nodes etc.

Helm

Image Added

Image Added

Here we discuss the DevOps for openIDL.

...

  1. Manage
  2. Develop / Build / Test
  3. Configure / Provision / Deploy

Manage

Managing the configuration in Git is one of the tenets of the architecture.

The git repository is multi-part.  The network administrator manages a reference configuration that is used to set up any of the types of nodes.  One There is one reference configuration for each type of node.  In the data call app, this there is a Multi-Tenant Node, a Carrier Node and an Analytics Node.

...

Updates to the configuration for a node in git trigger a workflow that can include a consent step for te the node owner before configuration kicks off.

Develop / Build / Test

The Develop / Build / Test phase produces usable artifacts for the Deploy stage.

Developing for openIDL can be done locally.  You can create images and save them in your minikube docker or you can just run the particular component out of code.

Configure / Provision / Deploy

The Deploy stage assumes that the assets required (terraform, helm, container images) are all built and properly packaged.