Page History

...

Terms used with Version Control Systems

• RepositoryRepositories
  • 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..
• Working Copy
  • Working Copies are local copies of files from a Repository. Modifications are applied to files in a Working Copy that later on can be Comitted to the Repository.
• BranchBranches
  • A Branch corresponds to the current status of the job-related objects that have been added to the repository 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.
• CommitCommits
  • Commits include to submit a fully functional and deployable copy of job-related objects from a Working Copy to a Repository.
  • Commits are not intended for backup of working copies Working Copies for job-related objects.
• ReleaseReleases
  • 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 items 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.

...

• Discipline
  • Due to the possible sharing of tasks between job development and integration testing a test manager might not know exactly what files are included with the delivery of a release, i.e. he or she cannot check the completeness of deployed objects.
  • Therefore the discipline of the job developer is vital to to commit complete and accurate jobs and job dependencies is vital to the deployment process.
• Quality of the development environment
  

  • When managing test configuration files in the development environment you should take care not to commit them to the repository. To achieve this, no add command should be executed on these files. You also can add these do not add such files to the repository. Typically you can add such files to an ignore list (available with Git and Subversion). You should take into account that each configuration item that has been committed to the repository will be deployed to the integration or production environments some time later.

...

The deployments from development to integration and production environments make use of the following steps:

• Development Environment:
  copy
  • add the job files and configuration
  files from one stage to the other
  • do not copy the files that are used exclusively for testing in your respective environment
  • do not copy mock files

  ...

  • • files to the repository.
    • do not add files to the repository that are used exclusively for testing in this environment, e.g. mock files.
  • Integration Environment
    1. Update a local working copy from the development branch of the repository. Do not use the live folder directly but a separate folder outside of the JobScheduler installation for updating.
    2. Manage configuration files for this environment in a separate folder and add them to the integration branch of the repository.
    3. Update the integration environment, i.e. the live folder, first from the working copy for the development branch 1) and then from the working copy for configuration files from the integration branch 2).
  • Production Environment
    • Apply the same local working copies and deployment steps as for the integration environment.

  Deployment Operations with Subversion and Git

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

  	Subversion	Git
  Prerequisites	Subversion Server	Git Server
  	Find the Subversion server documentation from http://svnbook.red-bean.com/en/1.5/	The complete Git server documentation can be found from https://git-scm.com/documentation
  	Subversion Repository Find the documentation „how to install a subversion server“ e.g. from http://svnbook.red-bean.com/en/1.8/svn.serverconfig.html	Git Repository You can create a central repository by: navigating to a live sub-folder where the Git repository should be located, e.g. c:\temp\git_repro\live.  executing the command: git --bare init
  	Subversion Client	Git Client
  	Install the Subversion Client on the computer where JobScheduler is located	Install the Git Client on the computer where JobScheduler is located
  	Subversion Working Copy	Git Working Copy
  	Create a working copy in your live folder from the repository.	Create a working copy in your live folder from the 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 Please note that after the import the live folder is not a working copy.	navigate to your 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 repository. You can verify this with the command: svn list http://subversion.sos/svn/myproject	The files are now in the Git repository. You can verify this by cloning the repository to another folder: git clone c:\temp\git_repro\live
  	Delete the files from the live folder. Execute the command checkout to get retrieve the files from the repository to the live folder: svn checkout http://subversion.sos/svn/myprocject "C:\sos-berlin.com\jobscheduler\scheduler_current\config\live"
  Creating Working Copies	You can have several working copies of the live folder (see command checkout). The following commands are available to synchronize changes to the working copy with the repository:	You can have several working copies of the live folder (see command clone). The following commands are available to synchronize changes to the working copy with the project folderrepository:
  	Read Retrieve the current version from the repository (update). The update command reads changes from the repository and merges them into to the working copy: svn update C:\ jobscheduler\scheduler_current\config\live	Read Retrieve 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 repository. Please note that before committing changes it is recommended to perform an update command is recommendedin order to verify that the working copy reflects the current changes from the repository: 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-Message" git push origin master
  Making Changes	Changes are applied to the working copy by use of JOE or a text editor. With all changes for a certain feature being developed and functionally tested the changes can be committed to the repository. 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 This means that a change has been made in your working copy and also in another working copy to the same file and the same line of code. In this situation you have to resolve the conflict before proceeding. It is neccessary to use a commit message with the commit command. update make changes update commit	Changes are applied to the working copy by use of JOE or a text editor. Use this sequence of commands: pull make changes pull commit push
  Deploying Objects	There are two possible architectures to organize the deployment: The live folders of integration and production environments also are working copies. The live folders of the integration and production environments are simple folders without assignment to a repository.     When integration and production environments are working copies, then the deployment will be done by executing an update command on the integration/production live folder. Changes can be done directly in the integration/production live folders. They will be merged with the changes coming from the development environment. 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. For a more save safe and stable environment, it should avoided to make changes directly in integration/production environment live folders. 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 carrying out the export, any 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   Changes that have been made directly to the integration/production folders will be overwritten In case of an urgent , quick emergency change directly in the integration/production environment, the change also has to be applied to the development environment to make it persistent. Working with this approach is more safe as In in integration/production environments normally no changes will be applied. The the configuration that is deployed has been tested in the development environment.