Deployment Automation

[SaschaWildgrube]

Imagine a world without Update Sets. Yes. Just for a moment.

In this imaginary utopia, everything is shipped as an app via Source Control.

And instead of unicorns and fairies, imagine all deployments are done fully automated.

Here is how deployments work in this dream world:

Each deployment of an application version to a downstream instance should be conducted exactly according to the following procedure in exactly that order:

Automated:

1. Establish the dependency list based on the requested application version
2. Check the availability of the requested application version branch in the Source Control System and all application version branches of the dependency applications
3. Check which application versions need to be deployed to the target instance
4. Check if there are any version incompatibilities between the to-be-installed versions and the already installed versions on the target instance
   (e.g., if a version 1.5.0 is to be installed but version 2.0.0 is already installed – this would imply a version incompatibility and the deployment cannot be done)
5. Deploy all applications (in the order of the “dependency list”) to the target system
6. Verify compliance with the Coding Guideline on all deployed applications using Instance Scan
7. Run installation scripts (in the order of the “dependency list”)
8. Run all automated tests of all deployed applications (in the order of the “dependency list”) – but only on non-production instances (if there is a “Platform” application available, run all automated tests based on the dependency tree of the “Platform” application. Refer to chapter “Application Architecture and Dependency Management”)

Manual:

1. Performing smoke test
2. Optional: Clone production instance to HOTFIX instance

To perform these steps, the following technical capabilities need to build – as these are not provided OOTB:

• Establish the dependency list based on version branches in the repositories
• Deny any deployments in case circular dependencies or missing version branches for required applications
• Identify all tasks necessary to conduct the deployment – including installing applications from source control, running Instance Scan checks, and running ATF test suites (on non-production instances) – and execute these tasks automatically
• Run all installation scripts remotely on the target instance
• Ensure that there is only one deployment taking place on one target instance at any given point in time (otherwise a mix if different or even conflicting version states may temporarily impair the results of automated tests being run in parallel)
• Warn users of potential data deletions if an application no longer contains tables or columns in other tables which are present on the target instance

The open-source applications “DevTools”, “Deployer” and “CodeSanity” support all the required technical capabilities.

Read the whitepaper for the full story:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf

The DevTools, Deployer and CodeSanity apps (and many more) can be found here:

https://www.wildgrube.com/servicenow