Skip to main content

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Dec 14, 2014 — DevOps Expert

I Have XL Deploy, I Get It, What Now?

DevOps

A few years ago, after months of planning and preparation I, with the help of some specialists had my delivery team implement a production go-live.  The implementation weekend was pretty scary, it was our first one and despite all the pre go-live meetings it felt very chaotic.

That said, the specialists that were brought in to run the go-live were amazing, highly qualified and very experienced.  They pretty much had everything covered. In fact, I as product owner/sponsor added zero value on the night.  Once the post implementation handover and warranty period had completed the specialists withdrew and presumably moved on to other projects leaving myself and my delivery team to manage the production system. His name is Zak. That first night alone at home was one of the most terrifying.  People with kids are pretty much thrust in at the deep end and have to learn by doing... Ok, so this is a pretty tenuous (possibly clichéd) lead in to what I want to talk about, which is what do you do when you've bought the software, turned it into a production service and the vendors with their expert consultants have withdrawn and moved on to other things?  You want to apply the "new shiny" to your own problems but how do you start? Well, with our software you use it of course.  One of the best ways of getting the most value from our tooling is to use it at every opportunity for those tasks you identified that were giving you cause to automate - in the case of XL Deploy and XL Release. A trick to achieving larger goals with tooling (and pretty much most IT activities to be fair) is to break them down into smaller tasks.  Many improvement processes hit barriers because of our often inherent need to nail down every single detail in a single hit.  The "I must determine if I can boil the ocean before starting a project" mindset is sometimes irresistible and inhibits starting-the-doing bit.

The key to getting started for me is to ask some questions:

  • What do I have now?
  • Is a next step an improvement?
  • Does that next step inherrently limit me from making further improvements?
Then I dive in!

Real Life Example ( for me! )

My role requires me to perform demonstrations of software, consult with prospective clients and run proof of concepts  ( It's a very cautious world we live in! ). I am also relatively new to the company but not the role. I now have to understand new software and explore it's sweet spot and use it to solve a variety of problems our customers might face, without the “luxury" of all of the infrastructure our customers have to manage. If I want to demo continuous delivery from code creation to delivery into a "production” ( yes sometimes I have to be that explicit to prove it can be done ) I often want to do more than the stereotypical magic smoke and mirrors routine.  Starting this from scratch seems a daunting task and within minutes all of the aspects of what I want to show start to spider out of control (very similar to the real life solution we are trying to work with). So I start to break this down, I think about the physical aspects of what I want to deploy to.  There’s probably an optimal formula for doing this and perhaps that will emerge, in the mean time I figure that I would like to work with 3 unique environments (DEV, UAT, PROD) since this is typical of the landscapes we work with.  I want a 3 tier web-application running on these servers, oh and it would be nice to perhaps have a middleware server to represent some more variety of our products.  I would also like this to be re-useable and I want to automate as much of it as I can. Breaking down into steps from left to right and attacking each of the boxes in turn... In my case this diagram wasn't planned in advance. I was actually experimenting and deliberately drilling down to too much detail for a demo and it emerged, from a single virtual image target and my artificial requirements to create a desirable infrastructure.  However once I saw some patterns emerge I just imagined new sets of steps and kept working through the columns (in iterative loops if need be) to get to end goals.

What did I get out of it?

  • I created database schemas - learned some MySQL
  • I created LDAP infrastructures - learned some Open LDAP, discovered LDIF files
  • Automated provisioning of infrastructure - learned some Puppet
  • I explored more functionality of XL Deploy and XL Release
I now have 3 virtualized targets which I can spin up in advance.  I have scripts that will create the required configuration in XL Deploy and XL Release, with plans to virtualize these in the same way as I have done the targets.  I have integrations with third party tooling which I can deep dive into.  I also created custom configurations in XL Deploy to achieve some very specific deployment activities. Just going through this process has taught me about the XebiaLabs tooling and several other technologies besides. Once you get in the habit of using XL Deploy and XL Release to solve your deployment problems it becomes quite addictive.  You can quickly learn to use it for more and more aspects of deployment automation and you can start to improve many of your application release lifecycles.

Next Steps

There’s always more to do, and that’s true whether you’re building a small demo or managing a broader IT infrastructure.  I don’t want to stop at one demo, I want to make a platform so that others in my position can benefit from the effort.
  • Automate the provision of new versions XL Deploy and XL Release (using XL Deploy of course)
  • Incorporate our latest products into the platform
  • Add more target images for other middleware
  • Work with partners to simplify/improve those aspects of the platform
  • Look at providing a Demo As A Service (DAAS)

Conclusion (aka struggle to relate to tenuous opening)

I've found that you don't really have a choice when you bring home a child for the first time, soon the learn by doing aspect of parenting becomes immediately apparent.  I have also found recently that it's not a great metaphor for IT type projects...but never-mind.   I guess with software, or pretty much anything work related we tend to need a nudge.  We need to go all-in and commit to the activities that we think will improve our situation. The more you commit the sooner you learn what works and (I believe, more importantly) what doesn't.

Final Observation

Tackling the simple aspects of your release process first is a good way to start and following an 80:20 principle you can certainly make significant gains out of the box with both XL Deploy and XL Release.  The same probably applies to other tooling and approaches. But then going for your complex problems really gets you to the nuts and bolts of the tools.  You could find aspects of those problems you hadn’t considered before could make them less daunting without intervention.  Sometimes just committing to tackle a problem is valuable.  Another indirect benefit is that you will also be doing things that really make the vendors/developers of your product take notice.  This will (and certainly does for us) lead to very productive collaborations and further improvements for both parties. However far you want to take it, you won't be disappointed!

More from the Blog

View more
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

DevOps
If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

DevOps
Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Jan 06, 2021

How testing automation can build a culture of QA while accelerating continuous delivery

DevOps
An organization’s level of automated test coverage is quickly emerging ...
Read More
Jul 30, 2020

Part 2: Is Technology Slowing Down Your Digital Transformation?

DevOps
In part one of this post, we shared insights from Andreas Prins’ webin ...
Read More
Contact Us