Introduction

Rollout strategies imply to determine procedures how to rollout determining procedures for the rollout of scheduling objects such as JS7 - Workflows, JS7 - Calendars, JS7 - Schedules etc. between scheduling environments, for example from dev -> test -> prod environments.

Applicable strategies are determined by according to:

• the JS7 - System Architecture in use,
• the JS7 - Security Architecture requirements,
• the applicable skill set to use Rollout Procedures to be applied including:
  • JS7 - Deployment of Scheduling Objects
  • JS7 - Inventory Export and Import
  • JS7 - Inventory Git Integration

Environments

For the sake of simplicity the following explanations assume the use of three tiers for rollout with from dev -> test -> prod environments.

• Users might apply different wordings wording such as staging, user acceptance, integration etc.
• User Users might use fewer environments (such as test -> prod) or more environments (such as dev -> int -> uat -> prod).

Key Indicators

Terminology

• Deployment: The term is used for the step performed with JOC Cockpit: digitally signing and transferring a scheduling object such as a workflow to a given Controller and Agents.
• Rollout: This term implies transferring a scheduling object within the  same or across different JOC Cockpit inventories.
• Security Level: The security architecture implies three security levels when it comes to the deployment of scheduling objects:
  • low: a common private key is used for all user accounts when signing objects for deployment,
  • medium: individual private keys are used per user account when signing objects for deployment,
  • high: an individual private key is used per user account and outside of JOC Cockpit when signing objects for deployment.

Rollout Strategies

...

The JS7 - System Architecture offers describes a number of scenarios to useusage scenarios:

• Single JOC Cockpit - Single Controller - Shared Agents
• Single JOC Cockpit - Dedicated Controllers - Dedicated Agents
• Dedicated JOC Cockpits - Dedicated Controllers - Dedicated Agents

Strategies imply consideration of the JS7 - Security Architecture and Rollout Procedures.

Single JOC Cockpit

...

- Single Controller - Shared Agents

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

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

CONTROLLER1 [shape="box",label="Controller",fillcolor="lightskyblue1",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 [label="  assign Agent: dev  ",fontname="Arial",fontsize="10pt"]
JOC1 -> FOLDER1T [label="  assign Agent: test  ",fontname="Arial",fontsize="10pt"]
JOC1 -> FOLDER1P [label="  assign Agent: prod  ",fontname="Arial",fontsize="10pt"]

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

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

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

Explanation:

• System Architecture, Shared Agents
  • 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 with a low or medium security level.
• Rollout Procedures
  • Rollout is performed within with the single JOC Cockpit instance. This approach includes:
    • to map mapping environments to separate top-level folders in the JS7 - Inventory,
    • to copy copying scheduling objects between inventory folders ,
    • to modify the Agent assignment having copied workflows between top-level folders to consider environments.
    • and modifying Agent Assignments for consideration of environments.
    • deploying modified scheduling objects.
  • This approach makes use of Inventory Deployment and denies use of Inventory Export/Import and Inventory Git Integration for rollout.

Single JOC Cockpit - Dedicated Controllers - Dedicated Agents

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

FOLDER1D [label="Folder 1: dev",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1T [label="Folder 1: test",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1P [label="Folder 1: 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="darkolivegreen2",fontname="Arial",fontsize="10pt"]
CONTROLLER1P [shape="box",label="Controller: prod",fillcolor="darkolivegreen3",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"]

Explanation:

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

  Dedicated JOC Cockpits

  ...

  - Dedicated Controllers - Dedicated Agents

  
  

  Flowchart

  JOC1D [label="JOC Cockpit: dev",fillcolor="lightskyblue1",fontname="Arial",fontsize="10pt"] JOC1T [label="JOC Cockpit: test",fillcolor="lightskyblue2",fontname="Arial",fontsize="10pt"] JOC1P [label="JOC Cockpit: prod",fillcolor="lightskyblue3",fontname="Arial",fontsize="10pt"] FOLDER1D [label="Folder 1",fillcolor="white",fontname="Arial",fontsize="10pt"] FOLDER1T [label="Folder 1",fillcolor="white",fontname="Arial",fontsize="10pt"] FOLDER1P [label="Folder 1",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="darkolivegreen2",fontname="Arial",fontsize="10pt"] CONTROLLER1P [shape="box",label="Controller: prod",fillcolor="darkolivegreen3",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"] JOC1D -> FOLDER1D JOC1T -> FOLDER1T JOC1P -> FOLDER1P { rank = same; JOC1D -> JOC1T [label="rollout",fontname="Arial",fontsize="10pt"] } { rank = same; JOC1T -> JOC1P [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"]

  
  

  Explanation:

  • System Architecture, Dedicated Agents
    • In this scenario dedicated JOC Cockpit instances are operated per for each environment. Each JOC Cockpit instance is assigned a dedicated Controller with dedicated Agents.
  • Security Architecture
    • Each JOC Cockpit instance can be operated at any security level: low, medium. or high.
  • Rollout Procedures
    • Rollout is performed between JOC Cockpit instances using separate inventories. This approach includes:
      • to map mapping environments to separate JOC Cockpit instances with their respective Controllers and Agents,
      • to rollout of scheduling objects from one JOC Cockpit instance to the next ,to retain Agent assignment and retaining Agent Assignments as the same Agent Names be used with each Controller.

  Security Architecture

  The security architecture suggests three security levels when it comes to deployment of scheduling objects:

  • low: a common private key is used for all user accounts when signing objects for deployment,
  • medium: an individual private keys are used per user account when signing objects for deployment,
  • high: an individual private key is used per user account and outside of JOC Cockpit when signing objects for deployment.

  Implications towards the system architecture include that

  • a single JOC Cockpit instance can be operated in one security level only,
  • use of multiple JOC Cockpit instances allows to use separate security levels.

  Skill Set

  • • • ,
      • deploying scheduling objects individually from each JOC Cockpit that maps to the respective environment.
    • This approach makes use of Inventory Export/Import or Inventory Git Integration for rollout.

  Anchor
  rollout_procedures rollout_procedures

  Rollout Procedures

  Anchor
  inventory_deployment inventory_deployment

  Inventory Deployment

  The JS7 - Deployment of Scheduling Objects makes use of built-in operations available within a single JOC Cockpit instance .

  Copying folder contents, selecting objects for deployment and knowing which object to deploy to which Controller and environment requires some discipline.

  ...

  Complexity is low as deployment is a one-click operation that does not suggest complexity when used is carried out with a single JOC Cockpit instance.

  Selecting objects for deployment and knowing which object to deploy to which Controller when used with a common JOC Cockpit instance requires some discipline.

  Inventory Import/Export

  Anchor
  inventory_export_import inventory_export_import

  Inventory Export/Import

  The JS7 - Inventory Export and Import operations offer a valid strategy for performing rollout operations, for example from dev -> test -> prod environments.

  At the same time export/import requires some discipline to observe the nature of scheduling objects which are local to a specific environment or are to be prepared for rollout across environments.

  Complexity is medium as the technical export/import operation is simple, however. However, the choice selection of objects requires some attention.

  Anchor
  inventory_git_integration inventory_git_integration

  Inventory Git Integration

  The JS7 - Inventory Git Integration offers a number of options for rollout by use of the JS7 - Git Repository Interface.

  Complexity is high as this approach includes to follow suggests following the best practices for software development.

  Typically we find:

  • developers: persons who own skills for development in teams that to manage branching, merging etc. with Git,
  • engineers: persons who dispose of possess skills in system administration and scripting languages.

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

  Basic Considerations

  Rollout Considerations

  Anchor
  agent_assignments agent_assignments

  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 requires the Agent assignment of a Job to be modified when the Workflow is rolled out across environments.
  • During registration with a Controller, Agents can be assigned one or more Alias Names in addition to the Agent Name.
    • It is good practice to use generic Alias Names, such as accountingAgent. During rollout the Job's Agent assignment can remain unchanged provided that we find an Agent with the same Alias Name for each environment.
    • Note 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 the use of more Agents in the prod environment.

  Anchor
  rollout_objects_local_objects rollout_objects_local_objects

  Rollout Objects and Local Objects

  A number of objects suggest lend themselves to be being rolled out across environments without any changes. Most prominently this includes workflowsWorkflows/jobsJobs.

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

  Rollout Objects and Local Objects are categorized in the next section together with their assigned object types. Note that the classification suggested here does not necessarily apply to all users.

  Rollout Objects

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

  • 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 of 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

  Export/Import for Rollout

  The JS7 - Inventory Export and Import operations offer a valid strategy to perform rollout operations, for example from dev -> test -> prod environments.

  At the same time export/import requires some discipline about the nature of scheduling objects to be local to a specific environment or to be prepared for rollout across environments.

  Git Repository Integration for Rollout

  ...

  Prepare Objects for Rollout

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

  The suggested measures should not be considered a recommendation but a proposition that users might well choose 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 is considered a more efficient means of specifying periods for repeated execution than use of cyclic orders. 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 for not using generic Resource Locks which can be rolled out across environments.

  File Order Sources

  • JS7 - File Watching is performed for directories that can be specific to individual environments.
  • Instead of hard-wired directory names some global environment variables can be used that are added to an Agent instance's start script.
    • The following bad example specifies a hard-wired Directory:
      
      Image Added
      
      
    • The following 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 different Patterns for incoming file names are used across environments.

  Notice Boards

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

  Script Includes

  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 nature of JS7 - Job Resources suggest that they are used specifically for an environment.

  Calendars

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

  • Calendars allow selection of hard-wired dates.
  • Calendars allow the use of 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 provide restrictions for further limiting the 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 whether their Calendars are to be generic across environments or specific for particular environments.

  Schedules

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

  • For testing purposes in a test environment Schedules might use more frequent periods for order execution. For example a job developer might not want to wait until the 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 brings a degree of risk to the prod environment.