Organize deployment with subversion or git

When deploying configuration files it is more than just copying files from a to b. When working with sources a version control software migth be helpfull. With a version control system

you can rollback to an older version if neccessary
changes are documented
You have to commit changes that are relevant for other environments like integration or production

The following problems can not be solved by the version control system:

Having different configuration attributes in the JobScheduler configuration files e.g.

host names for process classes are different
different input for file order sources
different values for parameters e.g.DB connection strings are different

Consideration of different configuration attributes in dev, int and prod

Commit only files that should be part of the integration and production environment
Have include files for scripts and parameters and handle them seperatly
Make use of environment variables e.g. in the configuration of file oder sources or the values of parameters

	Subversion	Git
	The full Subversion documentation can be found here http://svnbook.red-bean.com/en/1.5/	The full git documentation can be found here https://git-scm.com/documentation
Pre Conditions
	Subversion Server You find the documentation „how to install a subversion server“ here http://svnbook.red-bean.com/en/1.8/svn.serverconfig.html	Git central repository. You can create a central repository with Navigate to a folder live where you want to locate the git repository e.g. c:\temp\git_repro\live `git --bare init`
	SVN client installed on local machine	git client installed on local machine
	Subversion Projectarchive
All files to be deployes are located in the live folder of a JobScheduler Installation.	Creating a working copy in your live folder from the projectarchive Please note that after the import the live folder is not a working copy.	Creating a working copy in your live folder from the git repository
	`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 folder move all files to a temporary folder `git clone c:\temp\git_repro\live` move all files back to the live folder `git add *` `git commit -m "initial load"` `git push origin master`
	The files are now in the subversion projectarchive. You can verify this with the command `svn list http://subversion.sos/svn/sos/test/ur`	The files are now in the git repository. You can verify this with cloning the repository to one more 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 projectarchive to the live folder `svn checkout http://subversion.sos/svn/myprocject` `"C:\sos-berlin.com\jobscheduler\scheduler_current\config\live"`
Working with the projectarchive	You can have several working copies of the live folder (see command `checkout`). To synchronize changes in 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 synchronize changes in the working copy with the project folder there are three commands
	Read the actual version from the projectarchive (update) The update command reads changes from the projectarchive and merge them into the working copy. `svn update C:\ jobscheduler\scheduler_current\config\live`	Read the actual version from the repository (pull) `git pull c:\temp\git_repro\live`
	The commit command writes changes from the working copy to the projectarchive Please note that before commiting changes a update command is neccessary especially when a commit from another working copy has been executed. `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-Nachricht"` `git push origin master`
Making changes	Changes are made in the working copy using JOE or a text editor software. When all changes for certain approach has been done the changes can be commited to the projectarchive. Before doing the commit the working copy has to be actualize with changes from other working copies by executing the update command. During the update it is possible that a conflict will be detect. That means that in your working copy is a change and also in another working copy in the same file and the same line a change has been done. If so, you have to resolve the conflict before proceeding. It is neccessary to apply a commit message with the commit command. update make changes update commit	Changes are made in the working copy using JOE or a text editor software. pull make changes pull commit push
Deployment	There are two possible architectures to organize the deployment The live folders of int and prod also are working copies The live folders of int and prod are simple folders without assignment to a projectarchive When int and prod are working copies, the deployment will be done by executing an `update` command on the int/prod live folder. Changes can be done directly in the int/prod live folders. They will be merged with the changes coming from dev This approach is more risky as the merged changes are not testet. The configuration will be merged directly in int/prod live folder and has never been existed in this version before. For a more save and stable environment, it should be forbidden to make changes directly in int/prod live folders. When int and prod are simple folders the deployment will be done by executing the `export` command from dev to int/prod. Before doing the export, all 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 in the int/prod folders will be overwritten In case of an urgent, quick change directly in int/prod, the change also has to be done in dev to make it persistent. Working with this approach is more save as Changes in int/dev normally will not be made The configuration that is deployed has been testet in dev.

Consider environment specific parameters and configurations.

When doing the deployment it is possible that parameter value are not valid in int/prod environment. E.G. the name of files, folders, printers etc.

Use environment variables that have different values in int, prod and dev. For

File order sources
Directories in file names

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

Use include files for specifying parameter values

<order>
<params ><include live_file="paramfile" node=""/>
..
</order>

and the file paramfile

<params >

<param name="par1" value="value1"/>

<param name="par2" value="value2"/>

</params>

Use different script include files for dev prod and int

<job order="yes">

<script language="shell">

<include live_file="include_scriptfile.sh"/>

</script>

<run_time />

</job>

How to handle different include files for parameters and scripts

create a folder include_files (parallel to the live folder)
create subfolders for dev, int and prod
create the same subfolders under dev, int and prod as in the live folder
create the include files in the subfolders for dev, int and prod
create a projectarchive wich contains the folder include_file
create a working copy with the import, delete and checkout command (see above).
When committing the include_files folder you should also commit the live folder (and vica versa) to have consistency between both folders.
When deploying to int export the include_files/int folder to the live folder at int
When deploying to prod export the include_files/prod folder to the live folder at prod

As you have a working copy in the live folder of dev, the include files from dev will be deployed when exporting the dev live 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 actualized with an export command from the dev working copy.

The quality of the dev environment

When having some test configuration items in the development environment you should take care of not commiting them to the repository. To achieve this, no add command should be executed on this file. You also can add these files to a ignore list (available with git and subversion). You should take in mind that every configuration item that has been committed to the repository will be in int or prod environment sometimes later.

Rollback to a former version

To rollback to a former version

identify the release to which you want to fall back
With subversion/git commands get the files of the release
Publish these files to int/prod

Space shortcuts

Page tree