The leader in enterprise class, open source middleware

JBoss Enterprise Middleware

Subscribe to JBoss Enterprise Middleware: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get JBoss Enterprise Middleware: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


JBoss Authors: APM Blog, Stackify Blog, SOASTA Blog, XebiaLabs Blog, Dynatrace Blog

Related Topics: JBoss Enterprise Middleware, Intel XML, XML Magazine

Blog Feed Post

Using Environment-Independent Packages in XL Deploy

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.


 

You can achieve successful automation of deployments with XL Deploy by leveraging 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 byusing its Unified Deployment Model, performing delta analysis, and automatically taking the components that need to be deployed or updated into account
  • The same packages are deployed and tested in different environments (such as Development, Integration, and Acceptance) before reaching Production, which eliminates ambiguity in applications versions

 

When 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. To eliminate environment-specific builds, XLDeploy 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:

 

stock1http://blog.xebialabs.com/wp-content/uploads/2016/03/stock1-768x284.png 768w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock1.png 980w" sizes="(max-width: 980px) 100vw, 980px" />

 

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):

stock2http://blog.xebialabs.com/wp-content/uploads/2016/03/stock2-768x529.png 768w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock2.png 980w" sizes="(max-width: 980px) 100vw, 980px" />

 

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.

stock3http://blog.xebialabs.com/wp-content/uploads/2016/03/stock3-768x588.png 768w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock3.png 980w" sizes="(max-width: 980px) 100vw, 980px" />

 

If XL Deploy is unable to find a value for a placeholder in a deployment package, you will get an error if the placeholder appears in a mandatory property. XL Deploy treats all placeholders in files as requiring a value:

 

stock4http://blog.xebialabs.com/wp-content/uploads/2016/03/stock4-768x65.png 768w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock4-960x83.png 960w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock4.png 980w" sizes="(max-width: 980px) 100vw, 980px" />

 

To learn more about the different types of placeholders and special values such as <empty>, refer to Using placeholders in XL Deploy.

 

XL Deploy includes a predefined set of file extensions for the artifact types that you can use; if you use a specific file extension, simply include it in the configuration of your object.

file.File.textFileNamesRegex=.+\.(cfg | conf | config | ini | properties | props | test | txt | asp | aspx | htm | html | jsf | jsp | xht | xhtml | sql | xml | xsd | xsl | xslt)

To learn more about scanning files for placeholders, refer to Enable placeholder scanning for additional file types.

 

When 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.

 

stock5http://blog.xebialabs.com/wp-content/uploads/2016/03/stock5-768x545.png 768w, http://blog.xebialabs.com/wp-content/uploads/2016/03/stock5.png 980w" sizes="(max-width: 980px) 100vw, 980px" />

 

Using this approach makes your deployments safer and allows you to manage environment-specific values from the XL Deploy repository; you can update dictionary values and trigger an update of the application to propagate parameter changes to the target system. XL Deploy will determine which deployed components are impacted by the variable changes and will generate an update plan that takes care of the required actions such as updating a datasource or your configuration files and restarting an Apache server or JBoss JVM.

While generating independent packages can require a bit of work from your development teams, it is strongly advised that you perform 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

 

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. When the configuration is embedded in an application, the application has to be in sync with the changes made to the different infrastructures, which are made by different teams in different timeframes. In the best case, failure to handle these changes and deliver the ad hoc version will result in manual configuration operations during deployments; in the worst case, it will result in deployment failures.

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 this 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 our 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.

 


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/

The post Using Environment-Independent Packages in XL Deploy appeared first on XebiaLabs.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.