All documentation pertaining to how developers can contribute to NDS Labs.

New to NDS Labs?

Start here: New Developer Workflow

Develop Workflows

An Example

https://github.com/bodom0015/developer-workflow

More Detail

Release Workflows

New Unstable "Test" Release

Prerequisites

Developer's Process (Semi-automatic)

  1. "Start Progress" on one of your assigned tickets (assign a new one if you have none assigned)
  2. If you haven't already, fork the upstream repository (you will only need to do this once per repository)
  3. Clone your fork onto your local machine
  4. Create / switch to a development branch (named after one the JIRA ticket associated with the work being done, i.e. NDS-XXX)
  5. Make any necessary changes to fulfill the JIRA ticket
  6. Commit all associated changes and push them to GitHub
  7. Mark ticket as "In Review" and assign to an available Tester
  8. Wait for the ticket to be assigned back to you
  9. Review the Tester's results

Tester's Process (Manual)

New Unstable "Latest" Release

Prerequisites

Process (Automatic)

Official Tagged Version Release (Stable)

Prerequisites

Process (Semi-automatic)

  1. For each repo: branch off of develop to create a release branch

OR

  1. Roll versions forward
    1. ndslabs
      1. gui/swagger.yaml: NDS Labs swagger API spec version number
      2. apiserver/build.sh: NDS Labs API Server Docker image version tag
      3. gui/Dockerfile: NDS Labs UI / webserver Docker image version tag
      4. gui/package.json: NDS Labs UI  / webserver NPM package version number
      5. gui/ConfigModule.js: NDS Labs UI Angular app build version number
    2. workbench-helm-chart
      1. values.yaml: NDS Labs API Server + UI Docker image version tags
    3. kubeadm-bootstrap
      1. install-kubeadm.bash: Kubernetes / Docker version numbers
      2. init-master.bash: Helm version numbers
    4. kubeadm-terraform
      1. kubeadm-bootstrap git release/tag: assets/bootstrap.sh
  2. PR from release branch to master
    1. Thorough testing, then more testing, then merge to master
  3. Tag master with new version number (freshly tested and stable)
    1. Any new merges and tags will trigger new Docker images to be built
  4. Wait for newly-tagged resources to automatically finish building and pushing Docker images
    1. Run a quick smoke test with newly-tagged resources
    2. Fix any last-minute errors directly on master and recreate release
  5. Backport any missing changes from release-x.x.x into develop
    1. This should include, at the very least, a commit from the release branch that rolls forward to new version numbers
    2. git checkout develop && git pull origin master && git push origin develop? Why does this not work with a PR...
Legacy Process
  1. Regenerate Swagger API / Client from spec (this can be skipped if the spec has not changed)
  2. Roll forward version numbers in ndslabs-deploy-tools and ensure that all values match the version number you are about to create:
  3. Create a new tag from master in GitHub for the new version (i.e. 1.0.0, 1.0.1, etc):
    1. Repositories should be tagged in the following order when possible:
      1. ndslabs (API server / REST API / CLI / UI)
      2. ndslabs-specs (service specs - starting with 1.2.0, this can be versioned separately from Workbench, but it should be noted upon a new release which version of Workbench the specs release will target)
      3. workbench-helm-chart (Helm deployment to Kubernetes)
      4. gluster (global file system - deprecated, no longer used)
      5. cluster-backup (cron job for backing up glfs / etcd / kubectl dump - starting with 1.2.0, this can be versioned separately from Workbench)
      6. ndslabs-nrpe (nagios monitoring - these can now be versioned separately from the rest of Labs Workbench)
      7. ndslabs-startup (dev-cluster startup - deprecated, no longer used)
      8. ndslabs-deploy-tools (ansible scripts - deprecated, no longer used)
      9. kubeadm-bootstrap (kubernetes deployment scripts - versioned separately, but it should be noted upon a new release which version of Workbench the release will target)
      10. kubeadm-terraform (terraform deployment procedure - versioned separately, but it should be noted upon a new release which version of Workbench the release will target)
      11. ndslabs-devenvs (developer environments - these can now be versioned separately from the rest of Labs Workbench)
        • NOTE: ndslabs-devenvs contains a large number of cascading images that will quickly fill up the build queue, that's why we do it last
    2. New versioned Docker images are automatically built from the upstream tags created on GitHub.
    3. All new tags that are created will trigger a build
  4. Roll forward version numbers in source and ensure that all values match on upstream master on GitHub: