Product Knowledge Base

Space shortcuts

Page tree

Versions Compared

Old Version 19

changes.mady.by.user Uwe Risse

Saved on

compared with

New Version 20

changes.mady.by.user Andreas Püschel

Saved on

Key

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

...

  • Version Control Systems are frequently used in software development. They can be applied as a basis for managed deployment of job-related objects, however, they are not focused on this purpose and therefore do not support specific deployment strategies. The basic functionality includes
    • to rollback to an older release if required.
    • to have changes documented.
    • to commit changes that are relevant for target environments.
    • to exclude test files and configuration files by not adding them to the repository.
  • This article provides some considerations and recommendations on deployment strategies. Users will have to determine the applicability of the repspective deployment strategy on their own.
  • SOS does not claim any preferences for a specific Version Control System product. At the time of writing no specific functionality is available that would make e.g. Git more useful for deployments than Subversion or Team Foundation Server. Therefore this article is not about comparing or recommending specific products, instead it will use Git and Subversion to explain the required repository operations for deployments.

...

  • Deployments include to consistently deploy all job-related objects, i.e. Jobs, Job Chains, Orders, Process Classes, Locks etc., that are referenced by each other and that make up a release.
  • Deployments consider configuration items, e.g. path names, ports, folders, that are applicable to all environments and configuration items that are specific for an individual environment.
  • Deployments can be carried out for a number of environments. Some users might use development, integration and production environments, other users might add sandbox or user acceptance test environments.
  • Deployments are caried out for releases, not for changes of individual files. Version control is not a replacement for creating backups of your job environments.
  • Capability to rollback to a previous release: Should a problem be detected e.g. in a production environment and not enough time be available for thorough analysis, then the option is to rollback immediately to a consistent previous state of job-related objects.

Environments

  • Three environments are required for managed deployments:
    • Development
      • Modifications to job-related objects are carried out in this environment.
    • Integration
      • No modifications are applied to job-related objects.
      • Configuration items are specific for this environment.
    • Production
      • No modifications are applied to job-related objects.
      • Configuration items are specific for this environment.
  • The purpose of the integration environment is to carry out tests of deployed objects. This includes testing the completeness, interoperability and accuracy of deployed objects. 
  • Should users want to skip the use of an integration environment then tests would have to be performed in a production environment which is not a recommended strategy.

...

  • Repositories
    • Repositories are logical units in a Version Control System to store Branches of objects that can be assigned permissions for access by different users and groups.
  • Branches
    • A Branch corresponds to the current status of the job-related objects that have been added to the repository by Commit operations.
    • Only one Branch at a time should be used for job deployment. Multiple branches are frequently used to organize the contributions of a number of developers who work in parallel on the same sources. It is not a recommended scenario for job development to have multiple engineers work in parallel on the same jobs.
    • Branches can be tagged, e.g. assigned a Release number.
  • Commits
    • Commits include to submit a fully functional and deployable copy of job-related objects to a Repository.
    • Commits are not intended for backup of working copies for job-related objects.
  • Releases
    • Releases are tagged Branches that are not modified after deployment.
    • Release numbers can be applied according to individual conventions. Semantic Versioning is a frequently used standard for release numbering (Major.Minor.Patch).

...

  • Initial creation of a repository with the configuration items of a JobScheduler instance.
    • Configuration items are stored in the live folder.
    • These items should become part of the repository
    • The live folder should be a checked out version of the configuration
  • Initial Deployment
    • Initially deploy a release to an integration or production environment.
  • Update Management
    • Deploy a maintenance release to an existing environments.
    • Existing job-related objects will be replaced. 
    • Dropped job-related objects will be removed.
    • Existing configuration items should be considered and maintained.

  • Rollback to a previous release

    1. Identify the release to which you want to fall back.
    2. With Subversion/Git operations get the files of the desired release.
    3. Deploy the desired release as stated with the "Update Management"

...

  • When carrying out the deployments it is possible that parameter values are not applicable to target environments, e.g. the names of files, folders, printers etc.
  • In a first step users should clearly separate all configuration items that are specific for an environment from job-related objects and configuration items that can be applied to all environments without changes.

  • Examples for differences in the configuration that should be considered include

    • host names for process classes
      • Solution: Having a set of process classes in each environment that will not be part of the deployment procedure. This configuration will be handled directly in the specific environment.
    • directories for file order sources
      • Solution: Having different file order sources in each environment that will not be part of the deployment procedure. This configuration will be handled directly in the respective environment.
    • values for parameters, e.g. database connection strings
      • Solution: Make use of include files.
      • Solution: Make use of environment variables that will be substituted at run time.

...

  • create a folder include_files (located parallely to the live folder)
  • create sub-folders for target environments, e.g. dev, int and prod.
  • create the same sub-folders for all target environments as in the development environment live folder
  • create the include files in the sub-folders for the target environments
  • create a project archive folder in the repository that contains the folder include_file
  • create a working copy with the import, delete and checkout commands (see below).
  • When committing the include_files folder you should also commit the live folder (and vice versa) to guarantee consistency between both folders.
  • When deploying to the integration environment then  export the include_files/int folder to the target live folder.
  • When deploying to the production environment then export the include_files/prod folder to the target live folder.

...

The following table describes the deployment operations with Subversion and Git and Subversion.

 Subversion

Git

 
PrerequisitesSubversion ServerGit Server 
 

Find the Subversion server documentation from http://svnbook.red-bean.com/en/1.5/

The complete Git server documentation can be found herefrom https://git-scm.com/documentation

 
Pre Conditions    

Subversion ServerSubversion Repository

Find the documentation „how to install a subversion server“ from

http://svnbook.red-bean.com/en/1.8/svn.serverconfig.html

Git central repository.Repository

You can create a central repository withby:Navigate

  • navigating to a
folder
  • live
where you want to locate
  • sub-folder where the Git repository
  • should be located, e.g. c:\temp\git_repro\live. 
  • executing the command:
    • git --bare init
 
 Subversion ClientSubversion client installed on local machineGit Client 
 Install the Subversion Client on the computer where JobScheduler is locatedInstall the Git Client on the computer where JobScheduler is locatedGit client installed on local machine 
 

Subversion ProjectarchiveWorking Copy

Git Working Copy 
 All files to be deployes are located in the live folder of a JobScheduler installation.

Creating Create a working copy in your live folder from the projectarchiverepository.

Please note that after the import the live folder is not a working copy.

Creating Create a working copy in your live folder from the git Git repository with the following commands:

 
 

svn import -m "initial load" --username myUser --password myPassword

"C:\sos-berlin.com\jobscheduler\scheduler_current\config\live"

http://subversion.sos/svn/myprocject

  • navigate to your
config
  • live folder
  • move all files to a temporary folder
    • git clone c:\temp\git_repro\live
  • move all files back to the live folder and execute:
    • git add *
    • git commit -m "initial load"
    • git push origin master
 

 

The files are now in the Subversion project archiverepository. You can verify this with the command:

svn list http://subversion.sos/svn/sos/test/urmyproject

The files are now in the Git repository. You can verify this with by cloning the repository to one more another folder:

git clone c:\temp\git_repro\live


 
 

Delete the files from the live folder.

Execute the command checkout to get the files from the project archive to the live folder:

svn checkout http://subversion.sos/svn/myprocject

"C:\sos-berlin.com\jobscheduler\scheduler_current\config\live"

  
Working with the project archive

You can have several working copies of the live folder (see command checkout)..

The following commands are available to To synchronize changes in to the working copy with the project folder there are two commands:

You can have several working copies of the live folder (see command clone).

To The following commands are available to synchronize changes in to the working copy with the project folder there are three commands:

 
 

Read the current version from the project archive repository (update).

The update command reads changes from the project archive repository and merge merges them into the working copy.:

svn update C:\ jobscheduler\scheduler_current\config\live

Read the current version from the repository (pull):

git pull c:\temp\git_repro\live

 
 

The commit command writes changes from the working copy to the project archiverepository.

Please note that before commiting committing changes a update command is neccessaryespecially when a commit from another working copy has been executed.an update command is recommended:

svn commit C:\ jobscheduler\scheduler_current\config\live

The push command writes committed changes from the working copy to the repository:

 

git commit -m "Commit-NachrichtMessage"

git push origin master

 

Making changesChanges

Changes are applied to the working copy by use of JOE or a text editor software.

When With all changes for certain approach has been done a certain feature being developed the changes can be commited committed to the project archiverepository. Before carrying out the commit command the working copy has to be updated with changes from other working copies by executing the update command. During the update it is possible that a conflict will be detected. That means that a change has been made in your working copy is a change and also in another working copy in to the same file and the same line a change has been done. If so, of code. In this situation you have to resolve the conflict before proceeding. It is neccessary to apply use a commit message with the commit command.

  1. update
  2. make changes
  3. update
  4. commit

Changes are applied to the working copy by use of JOE or a text editor software.

  1. pull
  2. make changes
  3. pull
  4. commit
  5. push
 
Deployment

There are two possible architectures to organize the deployment:

  1. The live folders of integration and production environments also are working copies

  2. The live folders of the integration and production environments are simple folders without assignment to a project archiverepository

 

  1. When integration and production environments are working copies, then the deployment will be done by executing an update command on the integratioonintegration/production live folder.

    1. Changes can be done directly in the integration/production live folders. They will be merged with the changes coming from the development environment.

    2. This approach is more risky as the merged changes are not tested. The configuration will be merged directly to the integration/production live folder and has never existed in this version before.

    3. For a more save and stable environment, it should avoided to make changes directly in integration/production environment live folders.

  2. When integration and production environments are simple folders, then the deployment will be done by executing the export command from the development environment to the integration/production environments. Before doing the export, existing files should be deleted.

    del /s c:\int\live
    svn export http://subversion.sos/svn/myprocject/live C:\int\live
    svn export http://subversion.sos/svn/myprocject/include/int C:\int\live

     

    1. Changes that have been made directly to the integration/production folders will be overwritten

    2. In case of an urgent, quick change directly in the integration/production environment, the change also has to be applied to the development environment to make it persistent.

    3. Working with this approach is more save as

      1. In integration/production environments normally no changes will be applied.

      2. The configuration that is deployed has been tested in the development environment.

  
    

...