xebialabs - optimizing app deployment to ibm websphere

Optimizing App Deployment to IBM WebSphere

Andrew Phillips, VP Products 13 Nov 2014

2 Copyright 2014.

Housekeeping

▪ TODO

3 Copyright 2014.

About Me

▪ VP Products for XebiaLabs

▪ Lots of enterprise software development on high-performance systems

▪ Been on both sides of the “Dev…Ops” fence

▪ Active open source contributor and committer

▪ Regular meetup, conference etc. presenter

4 Copyright 2014.

About XebiaLabs

▪ Leading provider of delivery automation software focused on helping companies deliver higher quality software faster.

▪ Reduce development applications costs

▪ Accelerate application time to market

▪ Bridge the gap between Development and Operations

Global Customers, Global Success

and more…

5 Copyright 2014.

Agenda

▪ Context: DevOps, CD and more…

▪ WebSphere App Deployment Challenges

▪ The Bigger Picture

▪ Getting Started

▪ Q & A

6 Copyright 2014.

Context: DevOps, CD and more

▪ Organizations need to dramatically accelerate the pace delivery of new features

▪ Agile, DevOps and Continuous Delivery as key initiatives

▪ New architectural paradigms (microservices) and runtime environments (containers, PaaS) coming too

7 Copyright 2014.

Context: DevOps, CD and more

▪ Getting releases to production is faster involves much more than just app deployment, of course…

▪ …but it’s one of the tasks that needs to be carried out much more frequently

▪ Delivery pipelines also require on-demand environments, so relying on “the test environment configured at the dawn of time” is out

8 Copyright 2014.

WebSphere App Deployment Challenges

1.  Defining your deployment package

2.  Limiting access for self-service

3.  Managing configuration

4.  Promoting to downstream environments

5.  Configuration drift

9 Copyright 2014.


Defining your deployment package

▪  Ensure you have a complete deliverable…

▪  …not “code here and config in an email/support ticket/spreadsheet”

▪  How to specify configuration in an environment-independent way?

▪  How to specify configuration without asking developers to include scripts or code in the deployment package?

▪  How to control which attributes are available to developers, and which values are permitted, without manual review?

12 Copyright 2014.


Limiting access for self-service

▪  WebSphere admins shouldn’t be spending time clicking through app deployments to Test and QA environments!

▪  Giving developers access to WebSphere directly usually results in “interesting” configurations

▪  How to allow developers to deploy without giving them WebSphere credentials and access to the machines on which WebSphere is running (e.g. for config files)?

▪  How to limit access to certain parts of WebSphere, e.g. allow only server- or cluster-scoped datasources?

16 Copyright 2014.


Managing configuration

▪  How to ensure the app has been approved for promotion?

▪  Same code and config, different settings

▪  Environments may have different sizings, different versions or even different runtimes (e.g. SA vs. ND)

▪  May require different deployment strategies −  E.g. rolling hot deployments vs. “standard” deployment with downtime

▪  Need to be able to abstract targeting information and orchestration logic from the deployment package!

18 Copyright 2014.


Promoting to downstream environments:

▪  How to ensure the app has been approved for promotion?

▪  Same code and config, different settings

▪  Environments may have different sizings, different versions or even different runtimes (e.g. SA vs. ND)

▪  May require different deployment strategies −  E.g. rolling hot deployments vs. “standard” deployment with downtime

▪  Need to be able to abstract targeting information and orchestration logic from the deployment package!

20 Copyright 2014.


Configuration Drift:

▪  How often have you heard: “But it works in the Test environment”?

▪  Configuration drift across environments is one of the most common causes of failed deployments

▪  Automated config management can help get rid of this problem…

▪  …but until that is done across the board “config diffs” are incredibly useful

21 Copyright 2014.


Configuration Drift:

▪  Challenge: how to look at only “the relevant bit” of the configuration?

▪  Discovering everything takes too long and produces far too much data to usefully work with

▪  How to identify “expected” vs. “unexpected” differences?

▪  What to do once you discover an unexpected difference?

26 Copyright 2014.

▪  WAS is not the only target for many applications

▪  Think database changes, config files on the file system, MQ resources etc. etc.

▪  Define them as part of the same deployment package…

▪  …or (if shared) as part of a dependent package

▪  Handle these as part of the same “automated transaction”

▪  And handle all “the usual” automation requirements: rollback, audit trail, reporting, integrations etc. etc.

The Bigger Picture

27 Copyright 2014.

▪  Many organizations are looking at automated environment provisioning and new runtime platforms

▪  “If I spin up a new WAS installation using PureSystems, can I deploy to it straight away?” −  i.e. is it “known” to my automation tooling?

▪  “If I want to try out Liberty Profile/BlueMix/Docker/your-favourite-runtime-here today, how big is the tooling overhead?” −  “trying out” doesn’t just mean doing the Hello World example, it means

seeing how easy it is to use as part of your delivery stream

▪  “Can I deploy to different runtimes as part of the same app pipeline transparently?”

The Bigger Picture

28 Copyright 2014.

▪  “We have all these apps and config spreadsheets? Where do we start?”

▪  Building your deployment packages doesn’t have to be a “boil the ocean” approach

▪  Start with the most common elements first −  Obviously, the app code −  Usually things like queues and datasources

Getting Started

29 Copyright 2014.

Getting Started

30 Copyright 2014.

▪  Tooling that can “reverse engineer” packages will accelerate the process

▪  Not magic: need to pick the correct elements to include in the package (e.g. no shared config) and need to tokenize environment-dependent values

▪  Should be used as a one-off “kickstarter” rather than the standard procedure for package delivery!

Getting Started

31 Copyright 2014.

Getting Started

32 Copyright 2014.

Getting Started

33 Copyright 2014.

Getting Started

34 Copyright 2014.

Key Takeaways

1.  Define environment-independent packages with code and app config

2.  Version and automate your shared config 3.  Allow for self-service deployment without full

access to WAS 4.  Include code and config beyond WAS 5.  Start with the most common config types first

35 Copyright 2014.

Next Steps

▪ Download XL Deploy: xebialabs.com/download/xl-deploy

▪ Learn more about XebiaLabs & WebSphere: xebialabs.com/products/xl-deploy xebialabs.com/resources/whitepapers

▪ Stay informed:

blog.xebialabs.com

@XebiaLabs

youtube.com/xebialabs

Thank You!

xebialabs - optimizing app deployment to ibm websphere

Technology