Introduction

Rollout strategies imply to determine procedures how to rollout 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 

• the JS7 - System Architecture in use,
• the JS7 - Security Architecture requirements,
• the applicable skill set to use
  • JS7 - Deployment
  • JS7 - Inventory Export and Import
  • JS7 - Inventory Git Integration

Environments

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

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

Key Indicators

System Architecture

The JS7 - System Architecture offers a number of scenarios to use

• Single JOC Cockpit, Single Controller, Shared Agents
  • In this scenario only one JOC Cockpit instance and one Controller is used. Agents are mapped to respective environments.
  • Rollout is performed within the single JOC Cockpit. This approach includes
    • to map environments to separate top-level folders in the JS7 - Inventory,
    • to copy scheduling objects between inventory folders,
    • to modify the Agent assignment having copied workflows between top-level folders to consider environments.
• 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.
  • Rollout is performed within the single JOC Cockpit. This approach includes
    • to map environments to the same or to separate top-level folders in the JS7 - Inventory,
    • 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.
• Dedicated JOC Cockpits, Dedicated Controllers, Dedicated Agents
  • In this scenario dedicated JOC Cockpit instances are operated per environment. Each JOC Cockpit instance is assigned a dedicated Controller with dedicated Agents.
  • Rollout is performed between JOC Cockpit instances. 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,
    • to retain Agent assignment 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

Deployment

Complexity is low as deployment is a one-click operation that does not suggest complexity when used 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

Complexity is medium as the technical operation is simple, however, the choice of objects requires some attention.

Git Integration

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

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

Basic Considerations

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 an environment.

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

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