Developing for openIDL
openIDL is an open source project. We will follow best practices for such projects.
Info | ||
---|---|---|
| ||
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
All pull/merge requests must reference the issue number. |
Tagging and Versioning
Use github releases to manage the iterations of the project in the different branches.
GitFlow
Let's follow GitFlow: https://datasift.github.io/gitflow/IntroducingGitFlow.html
...
Info | ||
---|---|---|
| ||
Development on Local MachineCreate 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 Appsidentify 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 Packageupdate version of common lib package.json pull request merge into main CI/CD auto deploys new version to github packages Update and retest dependentsfor 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
Ansible
Helm
Here we discuss the DevOps for openIDL.
...
- Manage
- Develop / Build / Test
- Configure / Provision / Deploy
Manage
Managing the configuration in Git is one of the tenets of the architecture.
...
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.