streamlining deployments in a large websphere environment

Streamlining Deployments in a Large WebSphere Environment

Real-world stories from Today’s IT World

2 Copyright 2015. Confidential – Distribution prohibited without permission

Agenda

▪The Need to Automate Application Deployment

▪Develop In-house Scripts

▪Buying Tools

▪Over to you: Questions!


About Me

• Currently: a Solution Architect with XebiaLabs

• Previous: Developer, Unix Admin, DBA, Middleware Admin and Middleware Architect

• Industries: Process Control to Banking


About XebiaLabs

XebiaLabs gives you the tools you need to deliver higher quality software, faster, at scale. Designed to foster Agile Development, our solutions for DevOps and Continuous Delivery bring speed, clarity, and simplicity to your software delivery practice.


Our Solutions

XebiaLabs products are designed to help Enterprise DevOps professionals achieve true Continuous Delivery at scale.

Visualize, orchestrate and manage your Continuous Delivery pipelines from

end to end.

Automate your application deployments so releases

occur in a repeatable, standard and efficient

way.

Manage, execute and optimize complex test

scripts across test tools.

TRY OUR PRODUCTS:

www.xebialabs.com/products


The WebSphere Environment

▪Two data centers

▪Dozens of Applications

▪Most run in WAS clusters (one cluster in each data center)

▪Most WAS clusters have two or more WAS servers

▪Most WAS clusters run on shared AIX VMs

▪The servers are a combination of Linux on VMWare and AIX on AIX VMs

▪There are some special dedicated servers for high value application

▪In addition to the WAS environment there are Jboss, Tomcat and a very few WebLogic environments.

▪DataPower and WAS Enterprise Service Bus (WESB)


What We Struggled With

We could not build the environments that the development teams needed fast enough

We could not configure the servers fast enough

We could not deploy applications fast enough


What We Struggled With

Inconsistencies when building environments by hand

How to keep up with all of the technologies in use

￭ JEE Containers (Webshpere, Tomcat, Jboss, WebLogic)

￭ Websphere Enterprise Service Bus

￭ Datapower

￭ Operating Systems (Linux, AIX, Windows)


Why Develop Our Own Script?

We didn’t have any budget for buying a tool.

We understand our environment better than anyone else.

We figured, we should be able to build our own deployment tools.

We gradually added more automation over time.


Develop In-house Scripts

Writing scripts Maintainingthe scripts

Auditing Tools


What Happened?

▪At first we had great success

▪We were able to deploy applications quicker

▪We were able to start to hand off some deployments to other teams

▪We could not develop scripts fast enough

▪We had problems with errors in the scripts

▪We still did not resolve the configuration drift between containers

The

Good

The

Bad


What We Learned?

Building your own scripts requires lots of discipline.

Building your own scripts takes more time than you would expect.

Building an extensible framework for your scripts requires more experience and planning than expected.

Nobody wants to write the documentation so everyone can use the scripts.

Adding new features / functionality was difficult.


Next Try: XL Deploy

Scripts already existed for most of the targets we were working with

There were clear paths to extend the product for environments that were not already supported

Security built into the product

Auditing built into the product

Enable other groups to have more control / visibility into their environments

Clearly define what needs to be delivered during a release


What Happened?

▪We were able to quickly integrate with Jenkins which helped the developers to quickly adopt XL Deploy for their development deployments

▪The middleware team could spend more time improving the middleware servers and less time servicing deployment and server configuration requests

▪We could compare environments to see if there was configuration drift

▪Deployments were smoother

▪We could not get plugins for everything

The

Good

The

Bad


What We Needed Beyond XL Deploy

XL Deploy did not have plugins for everything in the environment.

XL Deploy provided a specific framework for extending the product to support anything we wanted to automate.

XebiaLabs has an active community with a public github repo were we could contribute our plugins and get help from XebiaLabs or other XL Deploy users.


What We Learned

▪If you want to automate your deployments use a tool like XL Deploy that has characteristics as follows:

− Plugin framework

− Auditing

− Extensible by your team

− Active community to support your efforts

▪Make sure you have auditing and use that to measure your process improvements (number of deployments, success and most import failures including the reason for the failure.

▪Use a tool!


Resources

Books

http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

http://xebialabs.com/resources/whitepapers/the-it-managers-guide-to-continuous-delivery/

http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726


More Information

XebiaLabs products are designed to help Enterprise DevOps professionals achieve true Continuous Delivery at scale.

Visualize, orchestrate and manage your Continuous Delivery pipelines from

end to end.

Automate your application deployments so releases

occur in a repeatable, standard and efficient

way.

Manage, execute and optimize complex test

scripts across test tools.

TRY OUR PRODUCTS:

www.xebialabs.com/products


Start Delivering Faster Today!

@XebiaLabs

@jcodebender

XebiaLabs.com

XebiaLabs.com/ProductsFind us on Twitter:

http://www.twitter.com/xebialabs

http://www.twitter.com/xebialabs

Questions?

Thank You!

streamlining deployments in a large websphere environment

Software

confidential distribution

permission agenda

xebialabs xebialabs

inhouse scripts

test tools

deployment tools

application deployments

large websphere environment