10 Steps to Improving Your Deployment Process to Wildfly and Jboss EAP Whitepaper

10 steps to improving your deployment process to WildFly and JBoss EAP Whitepaper

Table of contents

Best practices for application deployments 3

Versioned artifacts together with application configuration 3

Versioned and templatized JBoss profile configuration 4

Best practices for deployments to IIS 4

Standard runtime control setup 4

Runtime control, insight, and deployment service 5

Automation 5

Automated application and configuration deployment 5

Automated JBoss middleware provisioning 5

Secure self-service 5

Integration 6

Consider components outside the Red Hat stack 6

Integrate with your development toolchain 6

Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 2 Whitepaper

At Digital.ai, we have decades of accumulated experience deploying to JBoss EAP and broader Red Hat middleware environments. Based on this Versioning knowledge, we have collected a list of practices and recommendations that can help you improve your 1. Versioned artifacts together with application deployment process to your JBoss- application configuration based middleware stack. 2. Versioned and templatized JBoss Many of the following practices, which we have profile configuration grouped into Versioning, Management, Automation, and Integration “tracks”, are applicable and valuable in other middleware environments too. Management The lightweight and flexible nature of JBoss1, the 3. Standard runtime control setup consequent wide variety of possible setups, and the relatively rapid pace of change of automation 4. Runtime control, insight, and interfaces, result in a number of JBoss-specific deployment service challenges too.

Automation Versioning 5. Automated application and 1. Versioned artifacts together with application configuration deployment configuration 6. Automated JBoss middleware Real apps running on JBoss are more than just an EAR file. Keep information about your application provisioning configuration — the datasources, queues, topics, 7. Secure self-service etc. that are required only for this application and which you would also want to remove if the application were uninstalled — with the code so Integration you know what your application actually needs to 8. Consider components outside the run, even if you have to set it up in a brand new Red Hat stack environment. 9. Integrate with your development • Always delivering just “the new EAR file” toolchain and assuming that your target environment is correctly configured means that there is 10. no one place — no Definitive Software Library — you can point to that describes your full application • Applying configuration changes required for a new version to all your JBoss installations becomes as easy as deploying the new • It is important that your configuration application version to the next environment: definitions abstract away from the no waiting around for the middleware team implementation format, such as the XML to deal with a configuration request. Even file syntax for defining datasources in older better, backing those configuration changes JBoss versions, or specific CLI commands for out again is as simple as downgrading to WildFly and JBoss EAP 6. As this transition the old application version: no more JBoss installations with dozens or hundreds of possibly stale configuration resources about 1 Throughout this document, “JBoss” will be used when the comment which nobody can say whether they are used applies both to JBoss AS (now WildFly) and JBoss EAP. If the open source or commercial version specifically is meant, we will use “Wild- by any of the current applications or not Fly” and “JBoss EAP”, respectively.

Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 3 Whitepaper

demonstrates, the implementation syntax can change dramatically. By specifying configuration in an abstract format, such Digital.ai Deploy, JBoss, & Red Hat changes can be accommodated without Middleware having to redefine all your application configuration Digital.ai Deploy, formerly XebiaLabs XL Deploy, is the only fully automated 2. Versioned and templatized JBoss profile Application Release Automation configuration solution on the market today. Digital.ai Even in a secured set up where developers Deploy was built from the ground up to don’t have access to the JBoss console and the support the best practices derived from underlying machine, ensuring a consistent server our extensive experience of deploying and profile configuration across environments, and preventing configuration drift, is a key to JBoss and working with Red Hat. challenge. Look for automation tooling to support Digital.ai Deploy offers unrivaled configuration drift analysis. Better still, prevent it from happening in the first place by provisioning support for the Red Hat middleware new JBoss environments based on versioned, family including JBoss EAP, as well as controlled configuration definitions! JBoss Web Server. Digital.ai Deploy can deploy most JBoss application and • Your “company standard” middleware environment configuration types out- configuration — profiles, JDBC drivers, and of-the-box, supports JBoss topology similar global resources — can be versioned and resource discovery, and provides a and controlled just as your application code and configuration should be consistent automation interface across (pre-)JBoss AS 6/JBoss EAP 5 and “new • Profile templates allow you to maintain one generation”, WildFly/JBoss EAP 6. versioned configuration definition while allowing port sets, credentials, etc. to vary With Digital.ai Deploy, organizations between environments can accelerate application time to • If your automation can deploy application market and eliminate manual tasks such configuration it should also be able to as scripting, while reducing cost and deploy your shared configuration, giving errors. you a consistent way of defining, managing, and applying all your JBoss configuration Learn more at: digital.ai/deploy settings

Management 3. Standard runtime control setup in the background. Since the standard JBoss In an enterprise environment, JBoss needs to startup command returns before the server run as an unattended server process. Logging in is fully running, determine which additional interactively as a user, starting the process, and checks to use before the init.d script simply leaving the login session open is not a completes. Log parsing and checking for scalable approach. connectivity on a certain port are common • On Unix, create an init.d script that switches options; a simple application that provides to the JBoss service user and starts, stops, a dedicated “server up” response is another and restarts the server uninterruptedly and possible alternative

Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 4 Whitepaper

• On Windows, install JBoss as a service using you dependent on a small set of individuals JBoss Native or one of the various Java for deployment service wrappers that are available • Release manuals are seldom stored or versioned alongside the applications they 4. Runtime control, insight, and deployment relate to: “oh, use the one from the last service time — it’s the same” Due to the relative simplicity and accessibility of the directory structure and deployment models • Ensure your automation allows for per- of pre-WildFly/JBoss EAP 6 versions, many JBoss application management of JBoss working setups handle deployment and maintenance directories! JBoss only offers “all-or-nothing” activities such as viewing log files through direct cleanup capabilities out of the box — either access to the JBoss directories and files. This can the working directories for all applications create unnecessarily complicated file permission are cleaned, potentially losing session state, structures when different groups of users require or no working directories are removed, different access rights (e.g. one group that deploys leaving stale files. In practice, working applications, another to manage configuration, a directory handling needs to be configurable third that can only start and stop the server). It also on a per-application basis ties these management activities very closely to the JBoss implementation which, as WildFly/JBoss EAP 6 6. Automated JBoss middleware provisioning demonstrates, can change significantly. • Many proven options exist to automatically • Expose the ability to start, stop, restart, provision a JBoss stack, from cloud etc. the server to view logs and to deploy management systems like VMware’s vSphere applications and configuration through a and vCloud and Red Hat’s Network Satellite, simple service layer. For start/stop/restart, to dedicated provisioning tools like JBoss appropriately controlled access to the JBoss Operations Network (JON), PuppetLabs’ init.d script or Windows service are already Puppet, and Opscode’s Chef sufficient • Clean environments greatly reduce the • For JBoss EAP 6, the new CLI already risk of stale settings, configuration, or file covers many aspects of a service layer. Until permission changes made for unrelated enterprises have entirely migrated to these applications in a previous test run from new versions, a thin wrapper that can expose interfering with your application and causing the same interface for both these and pre- a time-consuming “config bug hunt” WildFly/JBoss EAP 6 versions significantly simplifies application management and 7. Secure self-service reduces the migration effort Allow developers, testers, the QA team — anyone who needs access to a running version of the Automation application, really — to deploy without giving them 5. Automated application and configuration access to the admin console or JBoss directory deployment tree, enabling you to maintain control over your environment. No more release manuals, screenshots, or deployments through the admin console! • Your middleware management team has much better things to do than support • Release manuals have to be processed by application deployments to test and QA human beings, and we are known to be environments, but giving developers and poor at carrying out repetitive procedures testers access to JBoss and the actual accurately. Releases are often also too machines often leads to undesired, involved for a team member unfamiliar with undocumented, and hard-to-track changes your application to carry out quickly, leaving to your environments

Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 5 Whitepaper

• Automation allows for access controls that 9. Integrate with your development toolchain enable developers and testers to carry out Connect your deployment automation to your the limited activities required to deploy their development ecosystem. Look for automation that applications without logging into the admin can be integrated with your build tools, continuous console or directly accessing the machine(s) integration etc. on which JBoss is running • Most organizations have adopted iterative, • A consistent user experience and agile development methodologies to allow automation capability across (pre-) JBoss them to deliver new functionality faster AS 6/JBoss EAP 5 and “new generation” through DevOps and continuous delivery WildFly/JBoss EAP 6 is essential here! The initiatives JBoss management interfaces are almost completely different in the newer versions, • Linking your deployment automation to your and it is important that your automation development and continuous integration handles this transparently for your self- platforms removes a common bottleneck service users and is a prerequisite to setting up a continuous delivery pipeline

Integration And the 10th step? Sit back, relax, and 8. Consider components outside the Red Hat stack enjoy a well-deserved cup of coffee! Real deployments touch more than just JBoss and the Red Hat middleware stack. Bear in mind many apps will use components beyond the Red Hat suite: databases and other data stores such as Oracle, MySQL, or a NoSQL database, processing engines such as Hadoop, Content Distribution Networks, CMSes, or even simple configuration files or libraries to be copied to target systems etc. Learn more about • Ensure your automation can handle all the steps required to deploy your applications. Digital.ai Deploy: Otherwise, you’ll again be left with error- prone steps outside the Red Hat stack digital.ai/deploy • Most organizations run applications on hybrid middleware stacks, e.g. Java on JBoss and Tomcat, or Java and .NET applications

About Digital.ai Digital.ai enables enterprises to focus on outcomes instead of outputs, create greater business value faster, and deliver secure digital experiences their customers trust. The Digital.ai Value Stream Platform seamlessly integrates all the disparate tools and processes across the various value streams, uses data and AI/ML to create connective tissue between them, and provides the real-time, contextual insights required to drive and sustain successful digital transformation. With Digital.ai, enterprises have the visibility they’ve been seeking to deliver value, drive growth, increase profitability, reduce security risk, and improve customer experience.

Learn more at Digital.ai