Scope

Prerequisites

Requirements

Environments

Terms used with Version Control Systems

Use Cases

Best Practices

Separating configuration items specific for an environment

Use of Environment Variables

<job_chain>
   <file_order_source directory="${file_input_dir}\input" regex=".*"/>
   ...
</job_chain>

Use of Include Files for Parameters

Use include files to specify parameter values:

<order>
	<params>
		<include live_file="myorder.params.xml" node=""/>
    </params>
    ...
</order>

where the file myorder.params.xml could look like this:

<params >
	<param name="par1" value="value1"/>
	<param name="par2" value="value2"/>
    ...
</params>

Use of Include Files for Scripts

Use different script include files for development, integration and production environments:

<job order="yes">
	<script language="shell">
		<include live_file="include_scriptfile.sh"/>
	</script>
    <run_time />
</job>

Example for the Handling of different Include Files for Parameters and Scripts

As you have a working copy in the live folder for dev, the include files from dev will be deployed when exporting the dev folder. But with the second export from the include_files folder, the dev files will be overwritten with the correct version. An alternative approach is that also the live folder in dev is not a working copy but will be updated with an export command from the dev working copy.

Handling of Version Control Systems

Deployment

Deployment Process Flow

jobs_dev [label="Jobs\nDevelopment Environment",fillcolor="lightskyblue"]
jobs_int [label="Jobs\nIntegration Environment",fillcolor="lightskyblue"]
jobs_prod [label="Jobs\nProduction Environment",fillcolor="lightskyblue"]

conf_dev [shape="ellipse",label="Configuration Items\nDevelopment Environment",fillcolor="violet"]
conf_int [shape="ellipse",label="Configuration Items\nIntegration Environment",fillcolor="violet"]
conf_prod [shape="ellipse",label="Configuration Items\nProduction Environment",fillcolor="violet"]

repo_dev [label="Repository\nDevelopment Branch",fillcolor="orange"]
repo_int [label="Repository\nIntegration Branch",fillcolor="orange"]
repo_prod [label="Repository\nProduction Branch",fillcolor="orange"]

jobs_dev -> conf_dev
jobs_dev -> repo_dev
conf_dev -> repo_dev
 
repo_dev -> repo_int
repo_int -> jobs_int
jobs_int -> conf_int
conf_int -> repo_int
 
repo_dev -> repo_prod
repo_prod -> jobs_prod
jobs_prod -> conf_prod
conf_prod -> repo_prod

 

Explanations

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

Deployment Operations with Subversion and Git

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

 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 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 ClientGit Client 
 Install the Subversion Client on the computer where JobScheduler is locatedInstall 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 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 repository:

 
 

Retrieve the current version from the repository (update).

The update command reads changes from the repository and merges them to the working copy:

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

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 in 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. This means that a change has been made in your working copy and also in another working copy to the same file and 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.

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

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

Use this sequence of commands:

  1. pull
  2. make changes
  3. pull
  4. commit
  5. push
 
Deploying Objects

There are two possible architectures to organize the deployment:

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

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

 

  1. 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.

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

     

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

    2. In case of an urgent emergency 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 safe as

      • in integration/production environments normally no changes will be applied.

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