Organize deployment with a version control system such as Subversion or Git

Why using a version control system?

• deploy by releases
  • branch = code Stand: nur 1 branch auf dem alle arbeiten
  • branches werden getaggt
• capability to rollback to a previous release
  • problem unter produktion entdeckt - keine Zeit für Analyse
  • Datensicherung: wiederherstellen nach Löschen von Dateien in einer Umgebung
• Verteilung
  • Technische Übertragung auf mehrere Server

Scope

-3 environments: geht nicht mit weniger

• es muss eine Integrationsumgebung geben, damit das Deployment selber getestet werden kann

Regeln für den Umgang mit version control systemen

• Commit: ein funktionsfähiger und auslieferungsfähiger Stand, es darf kein Entwicklungsschritt committed werden
• Keine Commits zur Datensicherung

Probleme

• Korrekturlieferungen aus dev
  • Keine selektiven Updates auf Verzeichnisebene
    • Updates auf Verzeichnisebene: nein, da sonst Problem mit globalen Ressourcen, z.B. global locks, globale Prozessklassen
    • Update immer auf live folder
  • Keine selektiven Updates auf Änderungshistorie
    • Es wird immer der aktuelle Stand des Repository übernommen, nicht ein bestimmter Revisionsstand
• Disziplin: 
  • wenn derjenige, der in Integration testet, nicht wissen kann, was genau in der Lieferung enthalten ist, dann kann er nicht prüfen, ob er ggf. zu viele oder falsche Objekte erhalten hat
  • Know How Auftrennnung: der Entwickler kennt Locks, der Tester kennt einen Testfall für Concurrency (nicht die Objekte, die das implementieren)
• Umgebungsspezifische Dateien
  • Dürfen nicht committed werden

Deployment

The deployments from test to integration to production make use of the following steps

• copy the configuration files from one stage to the other
• do not copy the files that are used exclusively for testing in your test environment
• do not copy mock files

Just copying files probably is not sufficient. There are differences in the configuration that have to be considered.

• 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 directly on the specific stage.
• different input for file order sources
  • Solution: Having different file order sources on each stage that will not be part of the deployment procedure. This configuration will be handled directly on the specific stage.
• different values for parameters, e.g. 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 helpful. 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
• You can exclude test configuration files by not adding them to the repository

This table describes the deployment with Git and Subversion.

Consider environment specific parameters and configurations

When doing the deployment it is possible that parameter values are not valid in integration/production environments, e.g. the names of files, folders, printers etc.

Use environment variables that accept different values in development, integration and production environments. 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 to specify parameter values:

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

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

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

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>

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 development environment

When having some 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 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.

Rollback to a previous version

To rollback to a previous version

1. identify the release to which you want to fall back
2. With Subversion/Git commands get the files of the release
3. Publish these files to int/prod