Page History

Scope

• Version Control Systems are frequently used in software development. They can be applied as a basis for managed deployment of job related objects, however, they are not focused on this purpose and therefore do not support specific deployment strategies. 
• This article provides some considerations and recommendations on deployment strategies based. Users will have to determine the applicability of deployment strategies on their own.
• SOS dows not claim any preferences for specific Version Control System. At the time of writing no specific functionality is available that would make e.g. Git more useful for deployments than Subversion or Team Foundation Server. Therefore this article is not about comparing or recommending specific products, instead it will use Git and Subversion to explain the repository operations for deployments.

Prerequisites

Requirements

• Deployment includes to consistently deploy all job related objects, i.e. jobs, job chains, process classes, locks etc., that are referenced by each other and that make up a release.
• Deployments consider configuration items, path names, ports, folders, that are applicable to all environments and configuration items that are specific for an individual environment.
• Deployments can be carried out for a number of environments. Some users might use development, integration and production environments, other users might add sandbox or user acceptance test environments.
• Deployments are caried out for releases, not for changes of individual files. Version control is not a replacement for creating backups of your job environments.
• Capability to rollback to a previous release: Should a problem be detected e.g. in a production environment and not enough time be available for thorough analysis, then the option is to rollback immediately to a consistent previous branch of job related objects.

Environments

• Three environments are required for managed deployments:
  • Development
    • Modifications to job related objects are carried out in this environment.
  • Integration
    • No modifications are applied to job related objects.
    • Configuration items are specific for this environment.
  • Production
    • No modifications are applied to job related objects.
    • Configuration items are specific for this environment.
• The purpose of the integration environment is to carry out tests of deployed objects. This includes testing the completeness and accuracy of deployed objects. 
• Should you want to skip this environment then tests would have to be performed in a production environment which is not a recommended strategy.

Handling of Version Control Systems

• Repositories
  • 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.
• Branches
  • A Branch corresponds to the current status of the job related objects that have been added to the 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.
• Commits
  • Commits include to submit a fully functional and deployable copy of job related objects to a repository.
  • Commits are not intended for backup of job developer working copies of job related objects.
• Releases
  • 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).

Use Cases

• Initial Deployment
• Update Management

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

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

...

• 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

...