Deployment automation in XL Deploy

Deployment automation in XL Deploy is great, but do not forget to automate the setup and configuration of your XL Deploy environment as well.

Try to avoid using the user interface and try to avoid adding entries to the dictionaries manually. In stead use the API to create all of your infrastructure, environments, and dictionaries. Treat the set up of XL Deploy as code!

Here is a link to their API: XL Deploy Rest API
And here is some example of how you could use it in a bash script.

# Helper methods for accessing XLDEPLOY API using CURL
del_ci() {

curl -H "Authorization: Basic $XLD_BASICAUTH" -k -X DELETE -H "Content-type:application/xml" $XLD_SERVER/deployit/repository/ci/$1 --data "<$2 id=\"$1\"></$2>"

}

add_ci() {

curl -H "Authorization: Basic $XLD_BASICAUTH" -k -X POST -H "Content-type:application/xml" $XLD_SERVER/deployit/repository/ci/$1 --data "<$2 id=\"$1\">$3</$2>"

}

update_ci() {

curl -H "Authorization: Basic $XLD_BASICAUTH" -k -X PUT -H "Content-type:application/xml" $XLD_SERVER/deployit/repository/ci/$1 --data "<$2 id=\"$1\">$3</$2>"

}

add_ci_from_file() {

curl -H "Authorization: Basic $XLD_BASICAUTH" -k -X POST -H "Content-type:application/xml" $XLD_SERVER/deployit/repository/ci/$1 -d@$2

}

add_ci Environments/test core.Directory
add_ci Environments/test/test_dict udm.Dictionary "<entries>
    <entry key=\"DATABASE_URL\">$dep_DATABASE_URL</entry>
    </entries>
  <encryptedEntries>
  	<entry key=\"DB_PASSWD\">$db_password</entry>
  </encryptedEntries>
  <restrictToContainers/>
  <restrictToApplications/>"

Keeping track of the dictionary keys in combination with the keys being used in certain versions of your deployable archives is very important in order to realize reliable and more consistent results.

In the end these kind of deployment robots like XL Deploy or Nolio will have to become more and more mature in supporting immutable server concepts so that code and configuration is exactly the same in all environments.


The last few years have seen a lot of changes and improvements in the area of automating how software solutions are deployed consistently on development, test and production environments.

In the beginning of this journey, many of us as well as I, have started righting shell scripts to automate how applications and their middleware components and configuration items should be deployed in environments.

Between 2009-2010 I had created a bespoke framework that included installation of WebSphere profiles, configuring all items in WebSphere and all related stopping and starting events. Even for the ESB, Portal and Process Server products.

The framework consisted of the concepts of applications and environments and some kind of repository to keep track of versions. The knowledge of what to deploy how was placed in modules. Actually all of it was quite similar to a product that started to appear in the horizon: Deployit from XebiaLabs.

Nowadays some of my deployment automation framework is still being used, but lots of it has been replaced by XL Deploy. Rightfully so, as more support is available and it is managed as a real product by an independent vendor

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s