Last updated: 2024-11-07 21:05:31.050885 File source: link on GitLab

Feature environment

Purpose and audience

Branch: As per NuNet GIT Workflow, all individual development will happen on the feature branches created from develop branch and related to each issue assigned via the team process and development board. When the developed feature is requested to merge to the develop branch, selected stages of the CI/CD pipeline are triggered on merge request (so that reviewers and approvers if it complies to relevant acceptance criteria). The Feature environment is used to run these stages.

Architecture

Most of the stages require only static environment (i.e. can be executed via gitlab-runners on NuNet servers), but some of them may require distributed deployment of the platform components. Note also, that the feature network may branch in a number of channels (see compute provider onboarding for details) for testing specific features or use-cases which need sourcing specific hardware.

CI/CD stages

Feature environment is used to run the following CI/CD pipeline stages on merge request and on merge:

• static analysis;

• unit tests;

• static security tests;

• build (if needed by the feature);

• functional tests / API tests (if needed by the feature);

Triggering schedule

Since merge requests are be frequent, Feature environment mostly runs on GitLab servers triggered by CI/CD pipeline stages. However, it is also augmented by a small network of NuNet team owned hardware (still geographically distributed in private offices), which can be automatically updated and triggered in a centralized manner via CI/CD pipeline stages.

When necessary, a developer can request and run tests in NuNet's virtual machines and containers hosted in NuNet cloud servers or can run preliminary tests on their local machines before pushing into GitLab (always prefered). This environment is dotted in the above diagram since it is not exactly defined in the NuNet infrastructure.

Last updated: 2024-11-07 21:05:30.491277 File source: link on GitLab

environments

Contain all files and scripts that are needed in order to spawn each environment that is used in testing stages (also to start the production environment -- which is the mainnet!)

Summary

Similarly to other decentralized computing projects (as blockchains), the network is running on the hardware provisioned via independent devices. In NuNet case, there is an additional complexity due to the fact that test networks have to resemble heterogeneity of the population of devices, operating systems and setups. Therefore, large portion of the NuNet CI/CD pipeline have to run not on centralized servers (e.g. in our case, via gitlab-ci runners), but on the geographically dispersed network. In order to manage the full life-cycle of the platform, including testing of separate features and iterations of the network components, NuNet is using isolated channels categorized into four environments:

• feature environment is used to run ci/cd pipeline on each merge request from individual developers' feature branches;

• development environment runs the ci/cd pipeline on the develop branch of the NuNet repositories;

• staging environment runs extensive pre-release testing on the frozen features in the staging branch;

• production environment runs the final releases of NuNet network, exposed to end users;

Last updated: 2024-11-07 21:05:31.318115 File source: link on GitLab

Production environment

Note: Transferred from old Wiki page; to be updated as per new developments.

Purpose and public

This is the live environment used by the community to onboard machines/devices or to use the computational resources available on the NuNet platform.

CI/CD pipeline

No CI/CD pipeline stages are running on production environment. However, all users are provided with tools and are encouraged to report any bugs or file feature requests following the [https://gitlab.com/nunet/documentation/-/wikis/Contribution-Guidelines].

Architecture

The Production environment contains all community machines/devices connected to production network.

Production Release

When the tests in the Testnet (staging environment) are finished with success and approved by the testers, the module(s)/API(s) should be released to production. The following processes are being defined:

• versioning process: versioning of modules and APIs;

• compatibility/deprecation process: releasing modules/APIs that do not have compatibility with others modules/APIs currently running on the platform should be avoided since NuNet is a highly decentralized network; however old versions should be deprecated so maintaining the compatibility will not create other problems related to security, performance, code readability, etc.

• communication process: how the community is notified of modules updates, bugs, security issues

• updating process: how the modules/APIs are updated.

Last updated: 2024-11-07 21:05:30.792707 File source: link on GitLab

Purpose and audience

The development environment is composed of a somewhat larger (than feature) network of heterogeneous devices sourced from the community. Since NuNet, as a decentralized network, will not have control of the devices sourced from community, the development environment will encompass communication channels with the community members who will participate in the NuNet testers program.

CI/CD stages

Branch: develop branch

Develop environment is used to run the following CI/CD pipeline stages according to the pre-defined schedule, to be communicated to community testers:

• static analysis;

• unit tests;

• static security tests;

• build (if needed by the feature);

• functional tests / API tests (if needed by the feature);

• security tests

• automatic regression tests

Architecture

The development environment contains:

• virtual machines and containers hosted in NuNet cloud servers;

• machines owned by NuNet team members;

• machines provided by the community members on constant basis via NuNet Network private testers program;

Triggering schedule

The CI/CD pipeline in development environment is triggered in two cases:

1. automatically when a merge request is approved and merged into the developbranch (see all merged;

2. according to the pre-determined schedule for running stages that are more heavy on compute requirements -- which ideally may include the more advanced stages ; depending on the speed of development, NuNet may be schedule weekly or nightly builds and runs of the platform with the full pipeline (possibly including the latest stages of the CI/CD pipeline normally reserved for Staging environment only). In principle, Development environment should be able to run all automatic tests.

Last updated: 2024-11-07 21:05:31.569793 File source:

Staging environment

Note: Transferred from old Wiki ; to be updated as per new developments.

Purpose and public

Testnet is this network and is used by developers, QA/security engineers and community testers. Manged by the Product Owner.

CI/CD stages

Branch: staging branch, created from developby freezing features scheduled for release;

CI/CD pipeline runs the following stages automatically as well as manually where required:

• static analysis;

• unit tests;

• static security tests;

• build (if needed by the feature);

• functional tests / API tests (if needed by the feature);

• security tests

• regression tests

• performance and load tests

• live security tests

Architecture

The Staging environment contains:

• virtual machines and containers hosted in NuNet cloud servers

• machines owned by NuNet and NuNet team members

• extensive network of community testers' machines/devices provided via NuNet Network private testers, covering all possible configurations of the network and most closely resembling the actual NuNet network in production:

  • with different hardware devices

  • owned by separate individuals and entities

  • connected to internet by different means:

    • having IP addresses

    • behind different NAT types

    • having different internet speeds

    • having different stability of connection

    • etc

Triggering schedule

Testing on staging environment is triggered manually as per platform life-cycle and release schedule. When the staging branch is created from develop branch with the frozen features ready for release, the following actions are performed:

1. The staging environment / testnet is constructed by inviting community testers to join their machines in order to cover architecture described above;

2. All applications are deployed on the network (as needed) in preparation for automatic and manual regression testing and load testing;

3. Manual testing schedule is released and communicated to community testers;

4. CI/CD pipelsine is triggered with all automatic tests and manual tests;

5. Bug reports are collected and resolved;

6. Manual tests resulting in bugs are automated and included into CI/CD pipeline;

The above cycle is repeated until no bugs are observed. When this happens, the staging branch is marked for release into production environment.