JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 42

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version 43

changes.mady.by.user Andreas Püschel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • JS7 JOC Cockpit can be configured to interface with Git repositories to store and to rollout its configuration objects such as workflows and jobs.
    • JS7 supports use of Git compliant servers to manage remote repositories such as GitLab, GitHub.
    • JS7 makes use of a Git CLI Client that has to be provided by the user.
  • Configuration objects can be versioned (tagged) with Git and can be rolled out to different JS7 environments via Git. This allows to create and to test workflows in a development environment and to perform rollouts to a production environment by use of a Git repository.
  • A connection to a Git repository is considered an additional option to manage versions and rollouts of JS7 configuration objects.
  • The Git Repository Interface is made available in two steps:
    • Display feature availability
      StartingFromRelease2.3.0
       
    • Release 2.3.0: Make JS7 objects available from the file system to allow use of Git tools.
      • Jira
        serverSOS JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverId6dc67751-9d67-34cd-985b-194a8cdc9602
        keyJOC-1144
    • Release 2.4.0: Offer the GUI functionality from JOC Cockpit to manage JS7 objects with Git.

      Object Mappings

      Configuration Objects

      Rollout Objects

      JS7 configuration objects that are independent from a specific environment (dev, test, prod) and that can be rolled out across environments include

      • Workflows
      • Locks
      • File Order Sources
      • Notice Boards

      Such objects can be managed with JS7 in a way that allows to re-use the objects - without any changes - across rollout environments such as dev, test, prod.

      Local Objects

      The following configuration objects typically hold values that are specific for an individual environment (dev, test, prod) and therefore usually are added to a separate repository. Such objects are not rolled out across environments.

      • Job Resources
      • Calendars
      • Schedules

      Configuration Mappings

      The JS7 inventory is organized by folders.

      • Folders hold configuration objects such as workflows etc. and any level of sub-folders.
      • Folders are the basic unit for JS7 - Permissions, for example, users can be granted access to specific folders only.
      • Folders allow to perform bulk operations such as to deploy, to release, to remove and to rename configuration objects.

      Folders can be mapped to Git repositories managed by the same or by different Git servers like this:

          • Jira
            serverSOS JIRA
            columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
            serverId6dc67751-9d67-34cd-985b-194a8cdc9602
            keyJOC-1213
          • Jira
            serverSOS JIRA
            columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
            serverId6dc67751-9d67-34cd-985b-194a8cdc9602
            keyJOC-1214
          • Jira
            serverSOS JIRA
            columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
            serverId6dc67751-9d67-34cd-985b-194a8cdc9602
            keyJOC-1215

      Object Mappings

      Configuration Objects

      JS7 handles the below separation of Rollout Objects and Local Objects. JOC Cockpit offers to configure per object type which category is applied.

      Rollout Objects

      JS7 configuration object types that are independent from a specific environment (dev, test, prod) and that can be rolled out across environments include

      • Workflows
      • Locks
      • File Order Sources
      • Notice Boards
      • Scripts

      Such objects can be managed with JS7 in a way that allows to re-use the objects - without any changes - across rollout environments such as dev, test, prod.

      Local Objects

      The following configuration object types typically hold values that are specific for an individual environment (dev, test, prod) and therefore usually are added to a separate repository. Such objects are not rolled out across environments.

      • Job Resources
      • Calendars
      • Schedules

      Folder Mappings

      The JS7 inventory is organized by folders.

      • Folders hold configuration objects such as workflows etc. and any level of sub-folders.
      • Folders are the basic unit for JS7 - Permissions, for example, users can be granted access to specific folders only.
      • Folders allow to perform bulk operations such as to deploy, to release, to remove and to rename configuration objects.

      Folders can be mapped to Git repositories managed by the same or by different Git servers like this:


      Flowchart
      USER1 [label="User: 1",fillcolor="lightskyblue"]
USER2 [label="User
      Flowchart
      USER1 [label="User: 1",fillcolor="lightskyblue"]
USER2 [label="User: 2",fillcolor="lightskyblue"]
USER3 [label="User: 3",fillcolor="lightskyblue"]

FOLDER1 [label="Folder: 1",fillcolor="white"]
FOLDER1a [label="Sub-folder: 1.1",fillcolor="white"]
FOLDER1b [label="Sub-folder: 1.2",fillcolor="white"]
FOLDER2 [label="Folder: 2",fillcolor="whitelightskyblue"]
FOLDER3USER3 [label="FolderUser: 3",fillcolor="whitelightskyblue"]

REPOSITORY1LFOLDER1 [shape="ellipse",label="RepositoryFolder: 1-local\njob resources etc.",fillcolor="darkolivegreen1white"]
REPOSITORY1RFOLDER1a [shape="ellipse",label="RepositorySub-folder: 1-rollout\nworkflows etc.1",fillcolor="darkolivegreen1white"]
REPOSITORY2LFOLDER1b [shape="ellipse",label="RepositorySub-folder: 2-local\njob resources etc.1.2",fillcolor="darkolivegreen1white"]
REPOSITORY2RFOLDER2 [shape="ellipse",label="RepositoryFolder: 2-rollout\nworkflows etc.",fillcolor="white"]
FOLDER3 [label="Folder: 3",fillcolor="darkolivegreen1white"]
REPOSITORY3L
REPOSITORY1L [shape="ellipse",label="Repository: 31-local\njob resources etc.",fillcolor="darkolivegreen1"]
REPOSITORY3RREPOSITORY1R [shape="ellipse",label="Repository: 31-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]

USER1 -> FOLDER1REPOSITORY2L [labelshape="  can access  "]
USER2 -> FOLDER1 [label="  can access  "]
USER2 -> FOLDER2 [label="  can access  "]
USER3 -> FOLDER3 [label="  can access  "]

FOLDER1 -> FOLDER1a [label="  includes  "]
FOLDER1 -> FOLDER1b [label="  includes  "]
FOLDER1a -> REPOSITORY1Lellipse",label="Repository: 2-local\njob resources etc.",fillcolor="darkolivegreen1"]
REPOSITORY2R [shape="ellipse",label="Repository: 2-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]
REPOSITORY3L [shape="ellipse",label="Repository: 3-local\njob resources etc.",fillcolor="darkolivegreen1"]
REPOSITORY3R [shape="ellipse",label="Repository: 3-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]

USER1 -> FOLDER1 [label="  mapscan toaccess  "]
FOLDER1aUSER2 -> REPOSITORY1RFOLDER1 [label="  mapscan toaccess  "]
FOLDER1bUSER2 -> REPOSITORY1LFOLDER2 [label="  mapscan toaccess  "]
FOLDER1bUSER3 -> REPOSITORY1RFOLDER3 [label="  mapscan toaccess  "]

FOLDER2FOLDER1 -> REPOSITORY2LFOLDER1a [label="  maps toincludes  "]
FOLDER2FOLDER1 -> REPOSITORY2RFOLDER1b [label="  maps includes  "]
FOLDER1a -> REPOSITORY1L [label="  maps to  "]
FOLDER3FOLDER1a -> REPOSITORY3LREPOSITORY1R [label="  maps to  "]
FOLDER3FOLDER1b -> REPOSITORY3RREPOSITORY1L [label="  maps to  "]

      The mapping of folder objects to repositories implies

      
FOLDER1b -> REPOSITORY1R [label="  maps to  "]

FOLDER2 -> REPOSITORY2L [label="  maps to  "]
FOLDER2 -> REPOSITORY2R [label="  maps to  "]
FOLDER3 -> REPOSITORY3L [label="  maps to  "]
FOLDER3 -> REPOSITORY3R [label="  maps to  "]


      The mapping of folder objects to repositories implies

      • user access:
        • users
        user access:
        • users with JS7 access permissions to manage folders and to access the Git repository can manage configuration objects in JOC Cockpit and can commit, push, pull configuration objects to/from Git,
        • users with JS7 access permissions to manage folders and to access the Git repository can manage configuration objects in JOC Cockpit and can commit, push, pull configuration objects to/from Git,
        • users with JS7 access permissions to manage folders but without access to the Git repository can manage configuration objects in JOC Cockpit,
        • users with JS7 access permissions to view folders do not require Git access.
      • folder usage:
        • if a single Git repository should be used then all folders have to be available from a single root folder,
        • for use with a number of Git repositories each folder maps to a different repository,
        • folders can remain without Git integration for local management and deployment.

      ...

      • Security level LOW maps to use of a single Git account used by all users. Credentials are stored with the root account's profile in the JS7 database.
      • Security level MEDIUM maps to use of an individual Git account per user. Credentials are stored with each user account's profile in the JS7 database.
      • Security level HIGH does not allow to store Git credentials with JOC Cockpit. Operations on the remote Git repository have to be performed with tools external to JOC Cockpit such as Git Extensions.

      ...

      • The local repository for a JS7 root-level folder is created when a user performs the checkout or or clone operation for the Git repository via JOC Cockpit.
      • The local repository is persistent and is updated from the JOC Cockpit database (store operation) and from the remote Git repository (pull operation).
      • The remote Git repository is updated from the local repository by use of the push operation.
      • The JS7 - Cleanup Service removes any local repositories if the JS7 root-level folder no longer exists, i.e. if a root-level folder is dropped from JOC Cockpit.

      ...

      • git-tag
        • tags a commit with a version label
      • git-push
        • see above

      Rollout

      Rollout between different JS7 instances is performed by use of the Git functionality. The JS7 REST Web Service API manages the processes for checkout and cloning.

      ...

      • git-checkout
        • checks out a specific branch or tag from the Git remote repository to the local repository
      • git-clone
        • initially clones a Git remote repository to a local repository
      • git-pull
        • pulls recent changes from the Git remote repository to the local repository

      JOC Cockpit

      ...

      Operations

      The synchronization of configuration objects between the JOC Cockpit database and the local repositories are managed by the JS7 JOC REST Web Service API and are available from the JOC Cockpit GUI.

      The following JS7 REST Web Service operations are available:

      • ./inventory/repository/read
        • reads file tree of the local repository file system folder and updates the JOC Cockpit database
      • ./inventory/repository/store
        • stores a set of configuration objects from the JOC Cockpit database to the file system folder of the local repository
      • ./inventory/repository/delete
        • deletes a set of configuration objects from the file system folder of the local repository
      • ./inventory/repository/update
        • adds or updates a set of configuration objects in the JOC Cockpit database with the configuration objects from the local repositories repository's file system folder

      ...

      Scenarios

      Single Client - Multiple Repositories

      ...

      • Architecture
        • A dedicated JOC Cockpit instance is used with Controller and Agents for each rollout environment such as dev, test, prod.
        • A set of two Git repositories are used per folder and per rollout environment:
          • one repository holding local objects such as job resources that are specific for a rollout an environment,
          • one repository holding rollout objects such as workflows that are rolled out across environments.

        • The JOC Cockpit database holds the JS7 configuration objects:

          • each JOC Cockpit instance is connected to its own database,
          • each repository is mapped to an individual JOC Cockpit instance,
          • the database can be updated from a local repository.
      • Users
          Users
          • All users act in the same JOC Cockpit instance of the respective rollout environment that is a single client to the Git server.
          • Changes to the Git repositories are performed on behalf of the users' individual accounts and are added to the remote repositories.
        • Rollout
          • Deployments are performed from a single source (JOC Cockpit) to each Controller and Agents per rollout environment (dev, test, prod).
          • Rollouts are performed by copying rollout objects from a local Git repository to a remote Git repository of the target rollout environment (dev => test => prod).

        ...

        Flowchart
        USER1a [label="  User: 1a  ",fillcolor="lightskyblue1"]
USER1b [label="  User: 1b  ",fillcolor="lightskyblue1"]
USER2 [label="  User: 2  ",fillcolor="lightskyblue2"]
USER3 [label="  User: 3  ",fillcolor="lightskyblue3"]

JOC1 [label="  JOC Cockpit: dev  ",fillcolor="lightskyblue1"]
JOC2 [label="  JOC Cockpit: test  ",fillcolor="lightskyblue2"]
JOC3 [label="  JOC Cockpit: prod  ",fillcolor="lightskyblue3"]

FOLDER1 [label="  Folder: 1 (dev)  ",fillcolor="white"]
FOLDER2 [label="  Folder: 1 (test)  ",fillcolor="white"]
FOLDER3 [label="  Folder: 1 (prod)  ",fillcolor="white"]

DATABASE1 [shape="ellipse",label="  Database: dev  ",fillcolor="lightskyblue1"]
DATABASE2 [shape="ellipse",label="  Database: test  ",fillcolor="lightskyblue2"]
DATABASE3 [shape="ellipse",label="  Database: prod  ",fillcolor="lightskyblue3"]

REPO1ENVREPO1L [shape="ellipse",label="Repository: 1-dev-local\njob resources etc.",fillcolor="darkolivegreen1"]
REPO1ROLREPO1R [shape="ellipse",label="Repository: 1-dev-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]
REPO2ENVREPO2L [shape="ellipse",label="Repository: 1-test-local\njob resources etc.",fillcolor="darkolivegreen2"]
REPO2ROLREPO2R [shape="ellipse",label="Repository: 1-test-rollout\nworkflows etc.",fillcolor="darkolivegreen2"]
REPO3ENVREPO3L [shape="ellipse",label="Repository: 1-prod-local\njob resources etc.",fillcolor="darkolivegreen3"]
REPO3ROLREPO3R [shape="ellipse",label="Repository: 1-prod-rollout\nworkflows etc.",fillcolor="darkolivegreen3"]

{ rank = same; JOC1 -> DATABASE1 }
{ rank = same; JOC2 -> DATABASE2 }
{ rank = same; JOC3 -> DATABASE3; }

JOC1 -> FOLDER1 
FOLDER1 -> REPO1ENVREPO1L [label="  commit\n  push/pull  "]
FOLDER1 -> REPO1ROLREPO1R [label="  commit\n  push/pull  "]

JOC2 -> FOLDER2
FOLDER2 -> REPO2ENVREPO2L [label="  commit\n  push/pull  "]
FOLDER2 -> REPO2ROLREPO2R [label="  commit\n  push/pull  "]

JOC3 -> FOLDER3 
FOLDER3 -> REPO3ENVREPO3L  [label="  commit\n  push/pull  "]
FOLDER3 -> REPO3ROLREPO3R  [label="  commit\n  push/pull  "]

REPO1ROLREPO1R -> REPO2ROLREPO2R [label="  copy  "]
REPO2ROLREPO2R -> REPO3ROLREPO3R [label="  copy  "]

USER1a -> JOC1;
USER1b -> JOC1;
USER2 -> JOC2;
USER3 -> JOC3;

        Git Repository Operations

        ...

        JOC Cockpit Operations
        The JOC Cockpit database holds the JS7 configuration objects:
        • each JOC Cockpit instance is connected to its own database,
        • each Git repository is mapped to an individual JOC Cockpit instance,
        • the database can be updated from a local Git repository.
        Multiple Clients - Multiple Repositories
        Scenario
        • Architecture
          • A dedicated JOC Cockpit instance is used with Controller and Agents
            • for each user in the dev environment,
            • for all users in the test and prod environments.
          • A set of two Git repositories are used per folder and per rollout environment (dev, test, prod):
            • one repository holding local objects such as job resources that are specific for a rollout environment,
            • one repository holding rollout objects such as workflows that are rolled out across environments.
        • Users
          • Users act in individual JOC Cockpit instances of the dev environment as multiple clients to the Git server.
          • Users act in the same JOC Cockpit instance of the test and prod environments as a single client to the Git server.
          • Changes to the Git repositories are performed on behalf of the users' individual accounts.
        • Rollout
          • Deployments are performed from multiple sources (JOC Cockpit) to the connected Controller and Agents per rollout environment.
          • Rollouts are performed by copying rollout objects from a local Git repository to a remote Git repository of the target rollout environment (dev => test => prod).
        Repositories holding local objects are excluded from rollout. Repositories holding rollout objects are copied across repositories and environments.
        following operations are provided from the JS7 REST Web Service API and from the JOC Cockpit GUI: 
        • Job Management
          • Manage changes to configuration objects such as workflows and jobs.
          • Deploy configuration objects to Controller and Agents.
        • Repository Management
          • Store and commit changes to a set of local repositories, push changes to a set of remote repositories.
            • one repository holding local objects such as job resources that are specific for an environment
            • one repository holding rollout objects such as workflows that are rolled out across environments.
          • Pull changes from a remote repository to a local repository and update JOC Cockpit from the local repository.
          • Tag changes (commits) for versioning purposes in a remote repository.
        Git Operations
        The following operations can be performed with a Git Client outside of JOC Cockpit:
        • Operations similarly available from JOC Cockpit
          • Push changes from a local repository to a remote repository.
          • Pull changes from a remote repository to a local repository.
          • Tag changes (commits) for versioning purposes in a remote repository.
        • Operations not available from JOC Cockpit
          • Manage branches in a remote repository.
          • Checkout branches to a local repository.
        Multiple Clients - Multiple Repositories
        Scenario
        • Architecture
          • A dedicated JOC Cockpit instance is used with Controller and Agents
            • for each user in the dev environment,
            • for all users in the test and prod environments.
          • A set of two Git repositories are used per folder and per rollout environment (dev, test, prod):
            • one repository holding local objects such as job resources that are specific for an environment,
            • one repository holding rollout objects such as workflows that are rolled out across environments.
        • Users
          • Users act in individual JOC Cockpit instances of the dev environment as multiple clients to the Git server.
          • Users act in the same JOC Cockpit instance of the test and prod environments as a single client to the Git server.
          • Changes to the Git repositories are performed on behalf of the users' individual accounts.
        • Rollout
          • Deployments are performed from multiple sources (JOC Cockpit) to the connected Controller and Agents per rollout environment.
          • Rollouts are performed by copying rollout objects from a local Git repository to a remote Git repository of the target rollout environment (dev => test => prod).
        Repositories holding local objects are excluded from rollout. Repositories holding rollout objects are copied across repositories and environments.

         Flowchart
        USER1a [label="  User: 1a  ",fillcolor="lightskyblue1"
         Flowchart
        USER1a [label="  User: 1a  ",fillcolor="lightskyblue1"]
USER1b [label="  User: 1b  ",fillcolor="lightskyblue1"]
USER2a [label="  User: 2a  ",fillcolor="lightskyblue2"]
USER2b [label="  User: 2b  ",fillcolor="lightskyblue2"]
USER3 [label="  User: 3  ",fillcolor="lightskyblue3"]

JOC1a [label="JOC Cockpit: dev 1a",fillcolor="lightskyblue1"]
JOC1b [label="JOC Cockpit: dev 1b",fillcolor="lightskyblue1"]
JOC2  [label="JOC Cockpit: test",fillcolor="lightskyblue2"]
JOC3  [label="JOC Cockpit: prod",fillcolor="lightskyblue3"]

DATABASE1a#DATABASE1a [shape="ellipse",label="Database: dev 1a",fillcolor="lightskyblue1"]
DATABASE1b#DATABASE1b [shape="ellipse",label="Database: dev 1b",fillcolor="lightskyblue1"]
DATABASE2#DATABASE2  [shape="ellipse",label="Database: test",fillcolor="lightskyblue2"]
DATABASE3#DATABASE3  [shape="ellipse",label="Database: prod",fillcolor="lightskyblue3"]

REPO1ENV1REPO1L1 [shape="ellipse",label="Repository: dev-local-1a\njob resources etc.",fillcolor="darkolivegreen1"]
REPO1ENV2REPO1L2 [shape="ellipse",label="Repository: dev-local-1b\njob resources etc.",fillcolor="darkolivegreen1"]
REPO1ROLREPO1R  [shape="ellipse",label="Repository: dev-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]
REPO2ENVREPO2L  [shape="ellipse",label="Repository: test-local\njob resources etc.",fillcolor="darkolivegreen2"]
REPO2ROLREPO2R  [shape="ellipse",label="Repository: test-rollout\nworkflows etc.",fillcolor="darkolivegreen2"]
REPO3ENVREPO3L  [shape="ellipse",label="Repository: prod-local\njob resources etc.",fillcolor="darkolivegreen3"]
REPO3ROLREPO3R  [shape="ellipse",label="Repository: prod-rollout\nworkflows eetc.",fillcolor="darkolivegreen3"]

#{ rank = same; JOC1a -> DATABASE1a }
#{ rank = same; JOC1b -> DATABASE1b }
#{ rank = same; JOC2 -> DATABASE2 }
#{ rank = same; JOC3 -> DATABASE3; }

JOC1a -> REPO1ENV1REPO1L1 [label="  commit/push/pull  "]
JOC1a -> REPO1ROLREPO1R  [label="  commit/push/pull  "]
JOC1b -> REPO1ENV2REPO1L2 [label="  commit/push/pull  "]
JOC1b -> REPO1ROLREPO1R  [label="  commit/push/pull  "]
JOC2  -> REPO2ENVREPO2L  [label="  commit/push/pull  "]
JOC2  -> REPO2ROLREPO2R  [label="  commit/push/pull  "]
JOC3  -> REPO3ENVREPO3L  [label="  commit/push/pull  "]
JOC3  -> REPO3ROLREPO3R  [label="  commit/push/pull  "]

REPO1ROLREPO1R -> REPO2ROLREPO2R [label="  copy  "]
REPO2ROLREPO2R -> REPO3ROLREPO3R [label="  copy  "]

USER1a -> JOC1a
USER1b -> JOC1b
USER2a -> JOC2
USER2b -> JOC2
USER3 -> JOC3
        Git Repository Operations
        • management
        • versioning
        • rollout
        JOC Cockpit Operations
        • 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.
        • Each user 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
        
USER1b -> JOC1b
USER1a -> JOC1a
USER2a -> JOC2
USER2b -> JOC2
USER3 -> JOC3

        JOC Cockpit operations and Git operations are the same as for the above Scenario: Single Client - Multiple Repositories.
        Use Cases
        Lifecycle Support for Workflow Changes
        Use Case
        Each environment dev, test, prod makes use of an individual JS7 instance using JOC Cockpit and database, Controller and Agents.
        • Job Development in a dev environment 
          • JOC Cockpit Operations
            • A number of configuration objects, e.g. workflows, are created or changed by a job developer.
            • On completion of the change the job developer deploys the workflows to Controller and Agents to perform functional tests in the dev environment.
            • With functional tests being successful the developer
              • stores changes of workflows and related rollout objects to the local dev-rollout repository, commits changes and pushes changes to the remote dev-rollout repository.
              • optionally stores changes of local objects such as job resources to the local dev-local repository, commits changes and pushes changes to the remote dev-local repository.
        • Integration Testing in a test environment:
          • Git Operations
            • A tester with access to the job developer's remote dev repository adopts current changes. 
            • The tester copies changes from the job developer's remote dev-rollout repository (source) to the remote test-rollout repository (target) by Git operations that are performed with a Git Client outside of JOC Cockpit.
          • JOC Cockpit Operations
            • The tester pulls changes from the remote test-rollout repository to the local test-rollout repository and updates the JOC Cockpit instance from the local test-rollout repository.
            • The tester adjusts local objects such as job resources as required by the change.
            • The tester deploys changed workflows and related local objects to Controller and Agents to perform integration testing.
            • On completion of integration tests with changes being approved the tester
              • tags the latest commit in the remote test-rollout repository with a label, e.g. v2.3-approved.
                • Should the tester modify workflows then the tester commits changes to the local test-rollout repository and pushes changes to the remote test-rollout repository before tagging.
                • Some users might deny object modifications to be performed in a test environment and instead prefer to apply modifications in dev environments only.
              • optionally stores changes of local objects to the local test-local repository, commits changes and pushes changes to the remote test-local repository.
        • Production Rollout to a prod environment
          • Git Operations
            • An operator with access to the tester's test repository adopts the current changes and checks out the tag v2.3-approved.
            • The operator copies changes from the remote test-rollout repository (source) to the remote prod-rollout repository (target) by Git operations that are performed with a Git Client outside of JOC Cockpit.
            • The operator tags changes in the remote prod-rollout repository with a label, e.g. v2.3.
          • JOC Cockpit Operations
            • The operator pulls changes from the remote prod-rollout repository tag v2.3 to the local prod-rollout repository and updates the JOC Cockpit instance from the local prod-rollout repository.
            • The operator adjusts local objects such as job resources as required by the change. The operator optionally stores changes of local objects to the local prod-local repository, commits changes and pushes changes to the remote prod-local repository.
            • The operator deploys changed workflows and local objects to Controller and Agents for production use.
        References
        •  Jira
          serverSOS JIRA
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          serverId6dc67751-9d67-34cd-985b-194a8cdc9602
          keyJOC-1213
        •  Jira
          serverSOS JIRA
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          serverId6dc67751-9d67-34cd-985b-194a8cdc9602
          keyJOC-1214
        Rollout by a CI/CD Pipeline
        Use Case
        Each environment dev, test, prod makes use of an individual JS7 instance using JOC Cockpit and database, Controller and Agents.
        • Job Development and Integration Testing are explained from the above Use Case: Lifecycle Support for Workflow Changes.
        • Production Rollout
          • Operations performed by a Git Client external to JOC Cockpit
            • Copy changes from the remote test-rollout repository (source) to the remote prod-rollout repository (target).
            • Tag changes with a label in the prod-rollout repository.
          • Operations performed by use of the JS7 REST Web Service API
            • Pull changes from the remote prod-rollout repository identified by the respective tag to the local prod-rollout repository.
            • Update the JOC Cockpit instance from the local prod-rollout repository.
            • Deploy changed workflows to Controller and Agents for production use.
        Automation
        Automation of the CI/CD pipeline can be achieved by scripting:
        • Operations performed by a Git Client are scriptable by shell scripts.
          • The indicated Git operations can be performed on any platform, no access to the JS7 production environment is required.
        • Operations performed by the JS7 REST Web Service API are scriptable
          • from the JS7 - PowerShell Module,
          • from any scripting language that supports a REST Client, executing curl from a shell script might be sufficient.
          • Operations can be performed on any platform, no direct access to the JS7 production environment is required, however, credentials have to be provided to connect to the JS7 REST Web Service.
        References
        •  Jira
          serverSOS JIRA
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          serverId6dc67751-9d67-34cd-985b-194a8cdc9602
          keyJOC-1215
        • The JOC REST Web Service API will provide web services to interact with the local filesystem of the local git repository.
          • Web Serivce APIs
            • read
            • store
            • update
            • delete
        • The JOC REST Web Service API will provide web services to interact with the local git repositories.
          • The Web Serivce APIs will make use the git CLI.
            • Git Commands
              • add
              • restore
              • reset
              • commit
              • checkout
        • The JOC REST Web Service API will provide web services to interact with remote git repositories.
          • The Web Serivce APIs will make use the git CLI. 
            • Git Commands
              • 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) to support transfer of configuration objects 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