Streamlining Deployments in a Websphere Environment
Streamlining Deployments in a Websphere Environment
This article includes a slide deck from “Streamlining Deployments in a Websphere Environment – Real world stories from today’s IT world.”
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
On June 23rd, I participated in a Webinar on “Streamlining Deployments in a Websphere Environment”. I discussed my experiences automating deployments in a primarily IBM and IBM Websphere environments, our struggles with building environments, configuring the servers and keeping up with deployments. Towards the end of the webinar I outlined some of the items that we considered important for any deployment tool. Below is the slide deck “Streamlining Deployments in a Websphere Environment – Real world stories from today’s IT world.”
After the webinar, we held an impromptu Q&A session where I was able to answer questions that were brought up during and after the webinar. I have tried to respond to everyone’s questions below.
Questions from Webinar:
- Can you compare XL Deploy w/ WCBD?
We currently have support for WAS and WPS servers. Some of our customers have used the WAS plugin with some custom XL Rules to provide customer specific behavior for their WAS based applications.
- You said about Resource configurations like datasource,jms,ssl…how are they configured by XL deploy…is it similar to triggering some scripts from XL deploy?
XL Deploy uses a variety of scripts to do the actual deployments. These scripts are either part of the existing plugins or part of custom plugins. The scripts that get executed are data driven. By data driven, I mean the much of what they do is defined by configuration of the deployable objects as you define them in XL Deploy. We have a brief YouTube video that might help explain how this works.
- What advantages does Xebialabs tools have over other similar tools such as Puppet and Chef?
XL Deploy is built for application deployments. Tools like Puppet and Chef are built for system provisioning. There is a difference. It is possible to use a tool like Puppet or Chef to deploy your application, but here are 4 of the main reasons why provisioning tools are often not the best choice for application deployments:
- Hard to segregate duties between teams. For example splitting, Dev and Ops deliverables.
- Focus on individual machines. App deployments run across machines with inter-dependencies between machines and individual steps
- Little or no out-of-the-box logic for the most common application deployment operations. You’ll have to build those yourself
- Poor or no integration with your Build and CI tooling
Read more on our website
- XLDeploy integrates with wcs dmgr or deploys to wcs cluster using individual wcs node scripts?
The WAS plugin can interact directly with the WAS deployment manager and WAS servers via wsadmin. Any configuration changes you can do with wsadmin can be done with XL Deploy.
- What is the difference between testing frameworks such as JUnit and XL TestView?
We should be clear that XL TestView is not a testing tool in the sense that jUnit is. While tools like jUnit, Gatlin, FitNesse and Cucumber execute tests XL TestView collects, visualizes and analyzes the data from all of your test tools in one central dashboard. Furthermore, XL TestView can manage the execution of all of your test jobs. You can use XL TestView to set pass/fail criteria to enable automated decisions on whether to go live or not. The analysis tools in XL TestView help you identify potential problems based on your test results before they turn into bottlenecks or disasters. Check out the product page at https://xebialabs.com/products/xl-testview/
- How does XL Deploy differentiate between deploying a server environment vs. deploying an application to said server?
In XL Deploy Infrastructure is built up from Overthere hosts. An Overthere host is a system that you could log on to. Some examples of Overthere hosts include Unix servers and Windows servers. An overthere host could have a container such as a WAS deployment manager or WAS server. There are a variety of containers that are possible based on containers defined in the loaded plugins. These infrastructure components are combined to define an environment. We have a brief YouTube video that explains how environments are built:
- Are there any feature comparison sheet with other vendors?
We don’t provide a comparison sheet between other vendor’s products, but we do have a rich collection of documentation and white papers to help you identify the features that might be important to your organization. Furthermore XebiaLabs has community editions to allow you to try our tools without any pressure. We will also help you get started with your first applications. We will be there to help you all the way from trial to a full enterprise installation or as far as you want to go. https://xebialabs.com/products/xl-deploy/
- Is XL deploy tool built by XebiaLabs?
- How much tool scripting is performed on the command line stored on the server?
XL Deploy copies its scripts to the server, executes those scripts and then removes them when done. Our plugins come with most all of the scripting you would need. If customization is required it is very straight forward and it is easy to leverage the power of the rest of the XL Deploy framework.
- Is XL deploy specific to Websphere?
XL Deploy is not specific to Websphere. In addition to Websphere XL Deploy supports a plethora of other middleware containers such as; WebLogic, Tomcat and Jboss. Check out the plugins on our website at https://xebialabs.com/plugins/
- I have a script for websphere, can I easily convert that script to Jboss?
The first thing is that you don’t really need to write scripts for most of the tasks you would want to do with XL Deploy. Since XL Deploy uses an object model to model the things you want to deploy and the environment you want to deploy them too, the deployment plan and scripts are generated for you. You could very easily deploy to Jboss in Dev and then turn around and deploy to WebShere in Production. The application package would be the same for both environments and the deployment plan would automatically change as you changed targets.
- Jenkins does deploys too, why add another layer?
While it is true that Jenkings does deploys, XL Deploy does deployments better. A couple examples of how XL Deploy is better at deployments are as follows:
- Jenkins does not handle deployment pipelines well, Jenkins will build and deploy to one environment well, but expanding that to all of an organizations environments does not scale well
- Jenkins is missing some significant orchestration abilities found in XL Deploy for determining the order that artifacts will be deployed across several servers, managing network appliances and managing container configurations
- So for each environment the configuration details are to be passed through a properties files?
XL Deploy defines objects for each deployable. The data for these deployable object are stored in XL Deploy’s repository. The data for these deployable objects are made available to the deployable objects scripts at deployment time using a variety of substitution techniques.
- What do you think of WAS Liberty Profile, and how do you see XL Deploy in combination with that product?
I think WAS Liberty Profile is an interesting approach from IBM. Recent changes in development have seen many shops moving away from the full JEE stack in favor of frameworks like Spring and Hibernate that don’t need the whole JEE stack. This has allowed containers like Tomcat, Jetty and JBoss to take a bigger role in organizations. Compared to these containers Websphere seems big and clunky. WAS Liberty Profile on the small (fewer features enabled) can play in the Tomcat space while with all of the features turned on can play in the tradition WAS space. With a newer code base it is quite interesting. Sill it seems that traditional WAS sites are slow to change and the guys using Tomcat etc are in no hurry either. XebiaLabs provides two types of solutions for Liberty Profile users. First for the short term it is easy enough to extend XL Deploy to execute custom rules on objects like EAR and WAR objects. We are also in the process of developing an XL Deploy plugin to support WAS Liberty Profile.
- And is it something similar to RAFW?
The last I heard from IBM was that RAFW was end of life. RAFW was more of a deployment and configuration language. You are still stuck with building your own scripts and you have limited your scope of potential targets to WebSphere containers. Furthermore, you still need to implement an infrastructure to support your deployments. You will likely want to grant others’ permissions to do deployments, orchestrate the deployments across several technologies, collect logs from deployment steps, setup notifications, allow other groups to build deployments, integrate with your build systems (i.e. Jenkins, TFS, Bamboo etc), integrate with your ticketing system and many of the other features you find in a tool like XL Deploy.
- Deployment, scripts, datasources – in the case of WAS, wouldn’t XLDeploy have to wrapper wsadmin?
XL Deploy uses wsadmin and python. XL Deploy does not install anything special on your WAS servers. In fact from the deployment window you can inspect the actual scripts that XL Deploy will use to deploy your applications (full transparency).
You can listen to the entire video webcast by registering here: http://insightsmagazineonline.com. Learn more about XebiaLabs and how it can help streamline your deployments at https://xebialabs.com/products/
Published at DZone with permission of Rick Broker , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.