Deployment
The deployment deployments from test to integration to test have production make use of the following steps
- copy the configuration files from one stage to the other
- do not copy the files that are only used exclusively for testing in your test environment
- do not copy mock files
...
- host names for process classes are different
- Solution: Having a set of process classes on each stage that will not be part of the deployment procedure. This configuration will be handled directy directly on the specific stage.
- different input for file order sources
- Solution: Having different file order source sources on each stage that will not be part of the deployment procedure. This configuration will be handled directy directly on the specific stage.
- different values for parameters, e.g. DB database connection strings are different
- Make use of include files.
- Make use of environment variables that will be substituted at run time.
Using a version control software for deployment
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 helpfullhelpful. With a version control system
...
This table describes the deployment with git Git and subversionSubversion.
| Subversion | Git | ||
|---|---|---|---|
The full Find the Subversion documentation can be found herefrom | The full git Git documentation can be found here | ||
| Pre Conditions | |||
Subversion Server You find Find the documentation „how to install a subversion server“ herefrom 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 Git repository e.g. c:\temp\git_repro\live
| ||
| SVN Subversion client installed on local machine | git Git client installed on local machine | ||
Subversion Projectarchive | |||
| All files to be deployes are located in the live folder of a JobScheduler Installationinstallation. | Creating a working copy in your Please note that after the import the | Creating a working copy in your live folder from the git repository | |
| navigate to your config folder move all files to a temporary folder
move all files back to the
| ||
| The files are now in the subversion projectarchiveSubversion project archive. You can verify this with the command
| The files are now in the git Git repository. You can verify this with cloning the repository to one more folder
| |
Delete the files from the live folder Execute the command checkout to get the files from the projectarchive project archive to the live folder
| |||
| Working with the projectarchiveproject archive | You can have several working copies of the To synchronize changes in the working copy with the project folder there are two commands | You can have several working copies of the To synchronize changes in the working copy with the project folder there are three commands | |
Read the actual current version from the projectarchive project archive (update) The update command reads changes from the projectarchive project archive and merge them into the working copy.
| Read the actual current version from the repository (pull)
| ||
The Please note that before commiting changes a update command is neccessary especially when a commit from another working copy has been executed.
| The push command writes committed changes from the working copy to the repository
| ||
Making changes | Changes are made in applied to the working copy using by use of JOE or a text editor software. When all changes for certain approach has been done the changes can be commited to the projectarchiveproject archive. Before doing carrying out the
| Changes are made in applied to the working copy using by use of JOE or a text editor software.
| |
| Deployment | There are two possible architectures to organize the deployment :
| ||
Consider environment specific parameters and configurations.
When doing the deployment it is possible that parameter value values are not valid in int/prod environment. E.G. the name integration/production environments, e.g. the names of files, folders, printers etc.
Use environment variables that have accept different values in intdevelopment, prod integration and devproduction environments. For
- File order sources
- Directories in file names
| Code Block | ||
|---|---|---|
| ||
<job_chain name="job_chain1"> |
...
<file_order_source directory="${file_input_dir}\input" regex=".*"/> |
...
... |
...
</job_chain> |
Use include files for specifying to specify parameter values<order>
<params ><include :
| Code Block | ||
|---|---|---|
| ||
<order> <params> <include live_file=" |
...
myorder.params.xml" node=""/> |
...
.. |
...
</order> |
and the file paramfile
<params >
...
where the file myorder.params.xml could look like this:
| Code Block | ||
|---|---|---|
| ||
<params > <param name="par1" value="value1"/> |
...
<param name="par2" value="value2"/> |
...
</params> |
Use different script include files for dev prod and int
...
development, integration and production environments:
| Code Block | ||
|---|---|---|
| ||
<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
livefolder) - create subfolders for dev, int and prod
- create the same subfolders under dev, int and prod as in the
livefolder - 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 development environment
When having some test configuration items files in the development environment you should take care of not commiting to commit them to the repository. To achieve this, no add command should be executed on this filethese files. You also can add these files to a an ignore list (available with git Git and subversionSubversion). You should take in mind into account that every each configuration item that has been committed to the repository will be in int or prod environment sometimes deployed to the integration or production environments some time later.
Rollback to a former previous version
To rollback to a former previous version
- identify the release to which you want to fall back
- With subversionSubversion/git Git commands get the files of the release
- Publish these files to int/prod
...