Page History

...

• The JOC Cockpit database holds the configuration objects:
  • each JOC Cockpit instance is connected to its own database.
  • each Git Repository is connected to one or more JOC Cockpit instances, e.g. dev rollout.
• Each Git branch makes use of its own versions of configuration objects.
• Each user (client) makes use of an individual JS7 instance using JOC Cockpit and database, Controller and Agents.

Transfer between Environments (dev, test, prod)

Scenario

• Use Case
  • Each environment makes use of an individual JS7 instance using JOC Cockpit and database, Controller and Agents.
  • Environment dev: 
    • A configuration object, e.g. a workflow, is created or changed by a developer
    • when finished and tested (deployed) by the developer in his environment the configuration object will be stored to the local dev repository
    • the change to the local repository will be commited and pushed to the remote dev repository
  • Environment test:
    • A test user with access to the developers env repository, pulls the current changes.
    • The current changes will be copied from the developers env repository (source) to the test users test repository (target).
    • The test user updates his JOC instance with the current changes from his local test repository.
    • The test user deploys the changed workflow to his environment and runs the desired tests.
    • When finished and approved the current changes from the test users local test repository are commited and pushed to the remote test repository
      • additionally the latest commit can be tagged with a label, e.g. "v2_approved"
  • Environment prod:
    • A production user with access to the test users test repository, pulls the current changes and checks out the tag "v2_approved".
    • The current changes will be copied from the test users test repository (source) to the production users prod repository (target).
    • The production user updates his JOC instance with the current changes from his local prod repository and checks the updated changes before deployment.
    • When checked, the current changes from the production users local prod repository are commited and pushed to the remote prod repository
    • The new change will be tagged with a label, e.g. "v2"
    • The production user deploys the changed workflow to the production environment.

Requirements

• The JOC REST Web Service API will provide web services to interact with local git repositories (read, store, update, delete).
• The JOC REST Web Service API will provide web services to interact between local (add, reset, commit, checkout) and remote git repositories (clone, push, pull).
• The JOC REST Web Service API will provide web services to interact between local git repositories (read source/target, copy source/target) for transfer between environments (dev, test, prod).
  • All 3rd party git tool cover the interaction between local (clone) git repositories and remote (origin) git repositories also.
  • Most 3rd party git tools do not cover interaction between local repositories, e.g. local dev → local test