Creating and Using Environment-Independent Packages in XL Deploy

One of the main ways in which XL Deploy helps you achieve successful automation of application deployments is by providing the following features and practices:

• Development and Operations use the same tool to perform deployments, sharing the same deployment rules and logic
• XL Deploy generates a deployment plan based on rules by using its Unified Deployment Model, performing delta analysis, and automatically taking only the components that need to be deployed or updated into account
• The packages that are deployed and tested in Development, Integration, and Acceptance environments are the same ones that will be deployed to Production, which eliminates ambiguity in applications versions

In this blog post, we’ll give a brief introduction into how you can create environment-independent packages and still handle environment-specific values such as database connection strings, with XL Deploy.Creating environment-independent deployment packagesWhen on-boarding a new project within XL Deploy, one of the very first steps is to generate XL Deploy packages, typically by adding build instructions to your favorite build or CI tool.
Configuration embedded in a build cannot—- and should not – try to handle environment and infrastructure related changes. These items simply do not have the same lifecycle, and often decision makers are from different teams.
As an example, let’s look at a database instance being moved from one server to a different one. This type of move is typically an infrastructure or database team decision. If your configuration is embedded in the application, the application has to be in sync with the changes made to the underlying infrastructures, which are made by different teams in different timeframes. In the best case, failure to handle these changes will result in manual configuration steps that need to be carried out during deployments; in the worst case, it will result in deployment failures.
To eliminate environment-specific builds, XL Deploy allows you to use placeholders anywhere in your packages where you need environment-specific values. XL Deploy stores the values for these placeholders for each environment in its repository, and will take care of replacing the placeholders automatically at deployment time.
Placeholders use the following syntax by default: {{MY_VARIABLE_NAME}}. The environment-specific values for these placeholders are stored in dictionaries, which can be associated with one or more environments. This allows you to share common variable values across environments.
So, your usual properties or XML configuration files become environment-independent and will typically look like this:Note: a best practice is to define a naming convention for variables and to use prefixes –“STOCK” above- to avoid ambiguity and collisions.
When defining the environment-specific values in a dictionary, it is also possible to reference other placeholders. This eliminates the need to unnecessarily duplicate information and makes maintenance easier  (see the STOCK_DB_URL below):XL Deploy dictionaries also support encrypted entries for sensitive values such as database passwords. Used with password properties, these values will be represented as “*” in step previews or in inspection screens during deployment.
When an application package is built and imported into XL Deploy, placeholder-aware types can display the detected placeholders. You can use this feature to verify that the expected placeholders were correctly detected.If, during a deployment, XL Deploy is unable to find a value for a placeholder in a deployment package, an error will be displayed if the placeholder appears in a mandatory property. XL Deploy treats all placeholders in files as mandatory:To learn more about the different types of placeholders and special values such as , refer to Using placeholders in XL Deploy.
By default, XL Deploy will scan files with a predefined set of file extensions for placeholders:
file.File.textFileNamesRegex=.+.(
cfg | conf | config | ini | properties | props | test | txt | asp | aspx | htm | html | jsf | jsp | xht | xhtml | sql | xml | xsd | xsl | xslt)
If you need XL Deploy to scan files with other extensions too, you can simply change the appropriate configuration value, as described in Enable placeholder scanning for additional file types.Reviewing and verifying environment-specific valuesWhen deploying a package with XL Deploy, you can inspect the deployed object to verify values and do on-the-fly value overrides for testing purposes.This approach makes your deployments safer and allows you to manage environment-specific values from XL Deploy.
If an environment-specific value changes, you can even trigger an update of the application after updating the appropriate dictionary, to propagate the changes to the running system. XL Deploy will determine which deployed components are impacted by the changes and will generate an update plan that takes care of the required actions such as updating a datasource or your configuration files, restarting an Apache or JBoss server etc.

Additional options

There are several tools and practices that can help development teams and take specific situations or technologies into account when declaring and using placeholders:

• Development teams can continue to maintain a local version of their parameters for local debugging and deployments
• You can use XL Deploy REST APIs on the fly to generate local versions of the packages at build time (for example you can query dictionary values for the local environments)
• If you use Maven to build packages, you can take advantage of the Mustachifier community plugin, which (among other things) supports extended placeholder syntax such as {{USE_DELIMITERS:TRUE}} where « TRUE » is  the local build version value, that you can use to create a local build version

On the other side, teams in charge of the maintenance of dictionaries can leverage the XL Deploy Python client or REST API to automate dictionary operations; for example, they can perform a batch load or a batch update of dictionary values, and create reports to list differences between dictionaries.

Summary

While generating independent packages can require a bit of work from your development teams, it is strongly advised that you put in this one-time small investment because:

• Dictionaries provide a central place to enter and maintain environment-specific configuration
• Storing sensitive data such as server addresses, accounts, and passwords in dictionaries means it is not stored in development repositories
• It eliminates the need for environment-specific builds – which also means no more « oh, we’re running the development version in the QA environment »
• Dictionaries allow you to update environment-specific values from XL Deploy, eliminating manual, untraced configuration modifications on target machines and discrepancies between configuration embedded in the packages and the actual configuration required

Leveraging placeholders and dictionaries is a best practice when adopting XL Deploy. To learn about advanced features such as dictionary restrictions, visit our documentation site at https://docs.xebialabs.com/xl-deploy/