...

• System Architecture
  • In this scenario only one JOC Cockpit instance and one Controller is used. Agents are mapped to respective environments.
• Security Architecture
  • A single JOC Cockpit is used in a security level low or medium.
• Rollout
  • Rollout is performed within the single JOC Cockpit instance. This approach includes
    • to map environments to separate top-level folders in the JS7 - Inventory,
    • to copy scheduling objects between inventory folders and to modify Agent assignment for consideration of environments.
    • to deploy modified scheduling objects.
  • This approach denies use of Export/Import /Export and use of Git Integration for rollout.

...

JOC1 [label="JOC Cockpit",fillcolor="lightskyblue",fontname="Arial",fontsize="10pt"]

FOLDER1D [label="Folder: dev",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1T [label="Folder: test",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1P [label="Folder: prod",fillcolor="white",fontname="Arial",fontsize="10pt"]

CONTROLLER1D [shape="box",label="Controller: dev",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
CONTROLLER1T [shape="box",label="Controller: test",fillcolor="darkolivegreen1darkolivegreen2",fontname="Arial",fontsize="10pt"]
CONTROLLER1P [shape="box",label="Controller: prod",fillcolor="darkolivegreen1darkolivegreen3",fontname="Arial",fontsize="10pt"]

AGENT1D [shape="box",label="Agent: dev",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
AGENT1T [shape="box",label="Agent: test",fillcolor="darkolivegreen2",fontname="Arial",fontsize="10pt"]
AGENT1P [shape="box",label="Agent: prod",fillcolor="darkolivegreen3",fontname="Arial",fontsize="10pt"]

JOC1 -> FOLDER1D
JOC1 -> FOLDER1T
JOC1 -> FOLDER1P

{ rank = same; FOLDER1D -> FOLDER1T [label="rollout",fontname="Arial",fontsize="10pt"] }
{ rank = same; FOLDER1T -> FOLDER1P [label="rollout",fontname="Arial",fontsize="10pt"] }

FOLDER1D -> CONTROLLER1D [label="  deploy  ",fontname="Arial",fontsize="10pt"]
FOLDER1T -> CONTROLLER1T [label="  deploy  ",fontname="Arial",fontsize="10pt"]
FOLDER1P -> CONTROLLER1P [label="  deploy  ",fontname="Arial",fontsize="10pt"]

CONTROLLER1D -> AGENT1D [label="  deploy  ",fontname="Arial",fontsize="10pt"]
CONTROLLER1T -> AGENT1T [label="  deploy  ",fontname="Arial",fontsize="10pt"]
CONTROLLER1P -> AGENT1P [label="  deploy  ",fontname="Arial",fontsize="10pt"]

...

• System Architecture
  • In this scenario a number of Controllers are connected to a single JOC Cockpit instance. Agents are dedicated to respective Controllers.
• Security Architecture
  • A single JOC Cockpit is used in a security level low or medium.
• Rollout
  • Rollout is performed within the single JOC Cockpit instance. This approach includes
    • to map environments to separate top-level folders in the JS7 - Inventory,
    • to copy scheduling objects between inventory folders, but to retain Agent assignment as the same Agent Names can be used with each Controller and environment,
    • to deploy scheduling objects individually to the Controller that maps to the respective environment.
  • This approach denies use of Export/Import /Export and use of Git Integration for rollout.

...

• System Architecture
  • In this scenario dedicated JOC Cockpit instances are operated per environment. Each JOC Cockpit instance is assigned a dedicated Controller with dedicated Agents.
• Security Architecture
  • Each JOC Cockpit instance can be operated in any security level low, medium. or high.
• Rollout
  • Rollout is performed between JOC Cockpit instances using separate inventories. This approach includes
    • to map environments to separate JOC Cockpit instances with respective Controllers and Agents,
    • to rollout scheduling objects from one JOC Cockpit instance to the next and to retain Agent assignment as the same Agent Names be used with each Controller,
    • to deploy scheduling objects individually from each JOC Cockpit that maps to the respective environment.
  • This approach allows use of Export/Import /Export and use of Git Integration for rollout.

...

The Git approach will work fine with engineers being ready to acquire skills for Git repository management.

Rollout Considerations

Determine Rollout Objects and Local Objects

A number of objects suggest to be rolled out across environments without any changes. Most prominently this includes workflows/jobs.

However, a number of objects might be specific for an environment, for example JS7 - Job Resources that hold environment variables that are specific for a machine.

Find below suggested categories for Rollout Objects and Local Objects with assigned object types. The suggested assignment does not necessarily apply to all users.

Rollout Objects

This category includes JS7 object types that are independent from a specific environment (dev, test, prod) and that can be rolled out across environments:

• Workflows
• Resource Locks
• File Order Sources
• Notice Boards
• Script Includes

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 object types typically hold values that are specific for an individual environment (dev, test, prod). Such objects are not rolled out across environments.

• Job Resources
• Calendars
• Schedules

Prepare Objects for Rollout

The following measures are suggested per object type to allow rollout of a scheduling object without changes.

Workflows

• JS7 - Workflows should not include hard coded values such as paths.
• Workflows can be parameterized
  • from JS7 - Order Variables that are generated by JS7 - Schedules,
  • from JS7 - Job Resources.

Resource Locks

• Except for testing purposes with changing Resource Lock capacities there is no reason why not to use generic Resource Locks that can be rolled out across environments.

File Order Sources

...

Consider Agent Assignments

Agents are registered with a specific Controller, they are not shared between Controllers.

• Agents are assigned a Job in a Workflow by use their Agent Name.
• Agent Names frequently are specified from the host name for which the Agent is operated, such as drx6834. Such practice should be reconsidered as it forces to modify Agent assignment of a Job when the Workflow is rolled out across environments.
• Instead, during registration with a Controller in addition to the Agent Name Agents can be assigned one or more Alias Names.
  • It is good practice to use generic Alias Names, such as accountingAgent, During rollout the Job's Agent assignment can remain unchanged provided that for each environment we find an Agent with the same Alias Name.
  • This includes that in a dev environment we might find fewer Agent instances than in a prod environment. Using more Alias Names for the same Agents in the dev environment maps to use of more Agents in the prod environment.

Determine Rollout Objects and Local Objects

A number of objects suggest to be rolled out across environments without changes. Most prominently this includes Workflows/Jobs.

However, a number of objects might be specific for an environment, for example JS7 - Job Resources that hold environment variables that can be specific for a machine.

Find below suggested categories for Rollout Objects and Local Objects with assigned object types. The suggested assignment does not necessarily apply to all users.

Rollout Objects

This category includes JS7 object types that are independent from a specific environment (dev, test, prod) and that can be rolled out across environments:

• Workflows
• Resource Locks
• File Order Sources
• Notice Boards
• Script Includes

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

Local Objects

The following object types typically hold values that are specific for an individual environment (dev, test, prod). Such objects are not rolled out across environments.

• Job Resources
• Calendars
• Schedules

Prepare Objects for Rollout

The following measures are suggested per object type to allow rollout of scheduling objects without changes.

Suggested measures should not be considered a recommendation but a proposition that users might have perfect reasons not to apply.

Workflows

• JS7 - Workflows should not include hard-wired values such as directories.
• Workflows can be parameterized
  • from JS7 - Order Variables that are generated by JS7 - Schedules,
  • from JS7 - Job Resources.
• Use of the JS7 - Cycle Instruction requires attention as it can be considered a competing though by far more efficient means to specify periods for repeated execution. As a rule of thumb
  • cycles in a workflow should be the same across environments,
  • orders that trigger execution of a cyclic workflow for a specific day can be specific for an environment and are created by Schedules.

Resource Locks

• Except for testing purposes with changing capacities of JS7 - Resource Locks there is hardly any reason why not to use generic Resource Locks that can be rolled out across environments.

File Order Sources

• JS7 - File Watching is performed for directories that can be specific per environment.
• Instead of hard-wired directory names some global environment variables can be used that are added to an Agent instance's start script.
  • The bad example specifies a hard-wired Directory:
    
    Image Added
    
    
  • The good example makes use of an environment variable and optionally adds a fixed part to the Directory like this:
    
    Image Added
    
    
• There should be no good reason why to use different Patterns for incoming file names across environments.

Notice Boards

The generic nature of JS7 - Notice Boards suggests no changes when being rolled out across environments.

Script Includes

The JS7 - Script Includes are added to job scripts.

• Users can decide to add hard-wired values to the content of Script Includes to make them specific for an environment.
• Users can make use of global environment variables in Script Includes that for example are injected by JS7 - Job Resources.

Job Resources

The JS7 - Job Resources suggest to be used specifically for an environment.

Calendars

The JS7 - Calendars are a flexible means to determine days for order execution:

• Calendars allow to select hard-wired dates.
• Calendars offer to use rules for repeated execution such as Monday to Friday, every 2nd Monday, every 3rd day of month etc.

The number of Calendars can be reduced as the JS7 - Schedules offer restrictions to further limit days for order execution:

• A generic business day Calendar could specify Monday to Friday for most order executions.
• A number of Schedules can use the same business day Calendar restricting order execution for example to Monday, every 4th Thursday etc.

Users should take a design decision about their Calendars to be generic across environments or to be specific for an environment.

Schedules

The JS7 - Schedules basically can be considered to be specific for an environment:

• For testing purposes Schedules in a test environment might use more frequent periods for order execution, for example a job developer might not want to wait for end of month to test a job related to accounting.
• Control of Schedules and of the JS7 - Daily Plan is a core competency of operators in prod environments. Importing Schedules from a dev or test environment somewhat puts control at risk.

...

Notice Boards

The generic nature of JS7 - Notice Boards suggests no changes when being rolled out across environments.

Script Includes

...