Skip to main content
Version: Deploy 22.2

Best Practices for Maintaining Deploy/Release Tools

This topics provides information about the best practices for maintaining Deploy/Release tools.

We recommended that you store the following items in your artifact storage repositories:

  • Application versions
  • The Deploy application /lib, /plugins, and /hotfix directories

For the configuration items (CIs) in Deploy applications, store the following in your source control management repositories:

  • The /conf directory
  • The /ext directory

This approach ensures that you can build a running version of the Deploy application, including all plugin content and configurations.

For CIs, you must define a versioning scheme for the contents of these directories. Also, we recommended that you have separate 'units' for /conf and /ext, because these directories may have a different lifecycle.

Further considerations:

  • Ensure that you have commit policies in place for clear commit messages. This ensures that people who are introducing changes clearly communicate what the changes are intended to do.
  • Optionally, introduce a branching scheme, in which you first check-in a configuration change on a development branch. Then, introduce a test setup that uses the development branch configuration and run smoke tests.
  • If you use a build system such as Salt, Ansible, Puppet, or Chef, consider scripting this process. For example, you could script the download of various artifacts from your artifact storage, unpack them together, then start the Deploy application instance. You could also use scripting to talk to the Deploy application instances to insert content.

Release​

An additional artifact to consider versioning is your Release templates. After you create a template that is considered final, click Export on the template to export it to an archive file with the .xlr extension. If you are following the storage repository approach described above, you should also consider storing the Release template binaries in the same fashion.

Provision a new instance​

We recommended that you create sandbox versions of Deploy/Release tools so you can test changes locally before introducing these changes to the larger team. At a high level, you should:

  1. Copy the appropriate version of the application from artifact storage and install it.
  2. Copy the /lib and /plugins directories from artifact storage.
  3. Check out the /ext and /conf directories from source control management into the new server directory.

Deploy​

After you create a sandbox environment, you can create the infrastructure and environment definition(s) that you need for testing. You can automate this process by creating versioned scripts and executing them using the command-line interface (CLI) or the REST API.

Release​

After you create a sandbox environment, you can check out the template(s) that you would like to work with.

Tips for setting up development and sandbox instances​

When a new version of a Digital.ai product is available, you can download it from the link provided in the support forum. At a high level, you should:

  1. Download the new version from the Deploy/Release Software Distribution site and store it in Nexus.
  2. Create a sandbox version of the new Digital.ai product, ensure that you have the correct plugins for your installation.

You are now ready to test the new version.