Release Automation

Technical Overview


DIRECT is designed to automate the deployment of native client applications with a focus on speed, data integrity, security and, when applicable, the end user experience.  While DIRECT excels at handling the global deployment of large digital payloads of almost any type, some particular use case challenges addressed by DIRECT are:

  • Installations and updates of software that must be permissioned by end-users.  User experience and completion rates are critically important (example: software, software trials, firmware, game downloads, etc.).​
  • Development teams working with game engine technologies (example: Unreal, Unity, Lumberyard, CryEngine, OGRE, etc.) that want benefits of Continuous Delivery practices, automated deployment across environments, and an efficient, fault tolerant update mechanism designed for massive scale.
  • Centrally managed deployments to specific target systems around the globe.  100% success in deploying to these systems is a critical business requirement (examples: POS systems, Ed-tech systems, manufacturing, etc.).

DIRECT consists of:

  • A client SDK for making highly customized client applications that manage the deployment operations on target systems (Windows, MacOS and Linux), and;
  • A set of tools, APIs and services that automate the deployment pipeline from the build server out to target systems through specified environments (example: Dev>>Test>>Stage>>Live).​

Deployment Scripts

​In order to facilitate a quick start, the DIRECT SDK includes deployment scripts written in Python 2.7 that combine and simplify the functionality of our deployment console tools and API services. These scripts can be used out-of-the-box to integrate with your continuous integration server, or they can be used as references for the scripting language of your choice.

These scripts are supported with extensive documentation and samples. Each script supports command line arguments, configuration files written in JSON, or values from a python configuration file.

Sample Commands: Release Deployment to AWS

The sample commands below instantiate the script to deploy an iteration of your application (or “release”) to our Origin Service at AWS: --source_directory=C:\SSN\llama_game\releases\33\
--output_directory=C:\SSN\llama_game\metafiles\ --repository_name=llama-game --build_version=1.00.033

​The script will perform the tasks diagrammed below.

Sample Script Output

The verbosity and location of the output is configurable.

The deployment scripts can perform the following tasks:

  • Deploy a release to the Origin Service at AWS
  • Deploy a release to a local server (web server, FTP, etc)
  • Deploy an existing local release to the Origin Service
  • Deploy directly to CDN origin storage
  • Create delta update paths between releases using the Origin Service
  • Compile and sign an end-user client for Windows, macOS or Ubuntu
  • Create deployment environments
  • Assign and/or promote releases between environments
  • Delete releases
  • Delete update paths

To see the complete documentation of DIRECT deployment tools, request an Evaluation account today.

Build Server Integration

​DIRECT comes with command line tools that handle the most common deployment related tasks including:

  • Deploying new iterations of software applications
  • Compiling customized DIRECT client applications
  • Signing and securing metadata used by DIRECT clients in its deployment operations

These tools are designed to work seamlessly within your continuous delivery framework, providing you with progress status and exit codes as part of its standard output.

Setting Deployment Arguments

The DIRECT deployment tools support an extensive set of arguments, all of which are fully documented within our Knowledge Base. Several example arguments are provided below.

Example 1: Specify where files are located and sync their attributes to a metafile.

Solid.MetaFile.Console.exe --metafile=c:\temp\game-release-01.json --add=c:\gamedirectory\01\ --attr=sync
  • A metafile is a JSON data file comprised of release-specific information such as file names, sizes and timestamps.
  • Files can be read from a local build server, a network share, plus SSH, HTTP, S3 or FTP URLs.

Example 2: Specify where to deploy delivery-optimized files and the digital certificate to be used to sign the metadata.

Solid.Release.Console.exe --metafile=c:\temp\game-release-01.json --create
--target=s3://1234567/362d5409-62894/ --pkcs12=c:\temp\ssntesting.pfx --pkcs12password=password
  • Releases can be deployed to another directory on a local build server, a network share, as well as SSH, S3 and FTP URLs.

Example 3: Compile a client-side executable while assigning “Version” and “Company Name” file properties

Solid.Builder.Console.exe --platform=win32 --skin=c:\pathToSkin\launcherSkin\
--output=c:\output\gameLauncher.exe --version= --companyName=Solid State Networks
  • The DIRECT deployment tools support building executable files and/or applications for Windows, macOS and Ubuntu operating systems.

Origin Service API

​Our robust Origin Service API allows you to manage your releases either on the cloud using AWS or on-premise, depending on the use case. Functionality includes:

  • Creating and managing deployment environments (development, qa, beta, staging, production)
  • Creating delta updates between releases using compute resources at AWS
  • Pushing deployment-ready files to a CDN for optimized delivery
  • Promoting releases between environments

The Origin Service API was designed to work best within a continuous delivery framework. It is a document-rich API service that uses standard GET, POST, and DELETE calls to initiate tasks on AWS.

Example 1: Pushing a Release to CDN.  This POST instructs our egress service to push a release from S3 to the delivery CDN.

POST /qa/egress/2a1a3fcfbe6a20a58592a06b87cba8088f6d9bda HTTP/1.1
Authorization: Bearer {{token}}

A 202 Response code means the task has been initiated. The body of the response will include additional information:

    "status": 202,
    "request": "31691519-4dcb-11e8-ac58-2f274a7d32fc",
    "target": "2a1a3fcfbe6a20a58592a06b87cba8088f6d9bda"

Example 2: Checking Status on the Release.  This GET checks on the status of the release in progress during egress to the CDN origin storage.

GET /qa/egress/2a1a3fcfbe6a20a58592a06b87cba8088f6d9bda HTTP/1.1
Authorization: Bearer {{token}}

A 206 response means the the release is still “in progress,” while a 200 response indicates the task has completed.

    "status": 206,
    "request": "4df10197-4dcb-11e8-9873-ef2df6f3e28d",
    "target": "2a1a3fcfbe6a20a58592a06b87cba8088f6d9bda"

Origin Service Web Application

Our Origin Service Web Application provides a simple user interface for viewing:

  • Storage and service usage
  • Release library for all repositories
  • Update paths
  • Status of deployment environments
  • Deployment analytics
  • Client-side analytics

As with our API and deployment scripts, the visualization tools are fully documented on our Knowledge Base. Documents include extensive “How to” articles such as “Viewing client-side metrics by City, Country, or Province” or “Viewing Completion Percentage Metrics.”