Here we discuss the DevOps for openIDL.

Since this is a distributed collection of nodes there are network and node level needs.

There are three areas to the dev ops architecture 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 reference configuration for each type of node.  In the data call app, this is a Multi-Tenant Node, a Carrier Node and an Analytics Node.

The node owners will each establish a repository to hold their configuration.  This should be linked somehow to the administrator repository, so that updates can be merged using git workflows.

Updates to the configuration for a node in git trigger a workflow that can include a consent step for te 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.