Clm Deployment Options - Scaling the Collaborative Lifecycle Management (CLM) solution across an enterprise
0 likes573 views
The document discusses scaling the Collaborative Lifecycle Management (CLM) solution within an enterprise, highlighting various deployment options and topologies available for applications like Change Configuration Management (CCM), Quality Management (QM), and Requirements Management (RM). It covers the impacts and considerations of using multiple Jazz Team Servers (JTS), addressing both the advantages of load distribution and the administrative complexities. The document also emphasizes the importance of planning and monitoring resources to avoid server overcommitment and provides strategies for effectively distributing projects across different server instances.
Clm Deployment Options - Scaling the Collaborative Lifecycle Management (CLM) solution across an enterprise
- 1. CLM Deployment Options Scaling the Collaborative Lifecycle Management (CLM) solution across an enterprise Tim Feeney (tfeeney@us.ibm.com) Unleash the Labs – IBM trfeeney.wordpress.com Ralph Schoon (ralph.schoon@de.ibm.com) Unleash the Labs – IBM rsjazz.wordpress.com
- 2. Notices and Disclaimers 1 Copyright © 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law
- 3. Notices and Disclaimers Con’t. 2 Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
- 4. Session Objectives Scaling the v6.0.x Collaborative Lifecycle Management (CLM) solution across an enterprise often includes multiple instances of a given Jazz application. What multi-Jazz application options are available and what are the considerations? In this session you will learn: • What topologies and general multi-Jazz application options are available • How Jazz applications such as Change Configuration Management (CCM), Quality Management (QM) and Requirements Management (RM) relate to a Jazz Team Server (JTS) • The impact, advantages and disadvantages of multiple CLM Applications • What to consider when scaling and developing usage models adopting one of these deployment options to avoid surprises 3
- 6. Available CLM Topologies • Recommended Enterprise Distributed Topology – One JTS on a dedicated server – One of each CLM application (e.g. CCM, QM, RM, DM) on dedicated servers – Dedicated server for Data Collection Component – Dedicated server for Report Builder (JRS) , Rational Engineering Lifecycle Manager (RELM) – A database server with databases for each application – A Reverse Proxy hosting the common public URI root, making the application’s public URI resilient to topology/hardware changes – See Recommended CLM Deployment Topologies for details • Additional applications and servers needed for configuration management (Global Configuration Management, Link Index, Lifecycle Query Engine) • Variants – Multiple JTS – Multiple CLM Applications • CCM, QM, RM, DM 5
- 7. The Importance of Topologies • Understanding the available topologies to be used with CLM appications and how to implement them is key for a successful deployment – The Recommended CLM Deployment Topologies are designed to allow scalability • Upgrade server, add additional servers and applications – The first setup steps of CLM include key decisions that can not be changed later* • Most important: The common public URI root, including the port number – Use the public URI root for all CLM Applications, hosted by a reverse proxy • Always use a fully qualified domain name provided by the IT department that will never have to change – Good Examples: clm.example.com, clm.mycompany.com, clm.example.com:9443 – Bad examples: windowsbox:9443, box1:9443/jts, box2:9443/ccm • Check with the IT department on which ports are allowed especially for potential access from outside; ideally use 443 as a well known HTTPS port – Consider each setup as a production system setup, even for pilots as in many cases there is a desire to transition the environment into production, even if agreed otherwise up front • CLM has a very limited ability to migrate data across repositories * Or might impact user satisfaction even if they can be changed 6
- 8. Multiple JTS • A JTS and one or more registered applications is referred to as a CLM Instance • An environment can have multiple CLM Instances • Motivation – Distribute load to separate CLM instances to maximize scalability e.g. organize by business unit or project boundaries – Minimize overall exposure should failure occur • Pros – Useful if projects are independent • IBM Labs have many independent CLM instances for various products • Custom development for different customers, separating subcontractors, access control • Cons – Administrative cost – increasing numbers need automation for deployment, administration and upgrade 7
- 9. Impact of Multiple JTS • Reporting – Multiple JTS/CLM instances require JRS to report across JTS boundaries • A ‘federated’ topology is needed in some cases for enterprise level reporting spanning CLM Instances • Linking between Artifacts – To be able to link between applications registered to different JTS requires manual creation of friends relationships between these applications • Registering an application to a JTS automatically provides friendship to all other applications registered to the same JTS • Lifecycle Projects and CLM Instances – Cannot create lifecycle projects that include artifact containers registered with a different JTS • Dashboards live within one JTS – Can show widgets from applications with friends relationship with this JTS 8
- 10. Multiple CLM Applications per CLM Instance • It is possible to deploy multiple instances of the same application each registered to the same JTS • Motivations – Capacity planning given the amount of concurrent users in the application instance and/or usage model require multiple application servers – Funding model for projects requires segregation (e.g. not a shared, joint or commonly funded resource) – Isolate a department or subcontractor; separate confidential from non-confidential data - when OOTB access control and permissions settings are insufficient • Pros – Balance load on applications – Increased scalability • Cons – Administrative costs – Side effects (behavioral differences) 9
- 11. Impact of Multiple CLM Applications
- 12. Impact of Multiple Applications • Applications have their own administration and properties – Additional maintenance needed to keep all in sync • Applications have their own database that contains their data – Limitations on moving of data/artifacts across applications and repositories – Limitations on link types available to link across applications and repositories • Some applications provide information at repository level – Need to maintain this consistently • RM/QM project properties • CCM User work environment – work allocation, scheduled absences • CCM process templates – Use process sharing to avoid inconsistencies and minimize administration overhead • DM Profiles 11
- 13. Impact of Multiple CCM Applications – Work Items • Work Items can be created in any CCM application and linked to any other work item in any other befriended CCM application – The only link relationships between work items in different CCM applications are ‘Related Change Request’, ‘Tracks’/‘Contributes To’ and ‘Affected By Defect’/’Affects Plan Item’ • Copying/moving of Work Items between Project Areas only works within the same CCM application repository • My Stuff only works within the same CCM application repository • See best practices for multiple CCM applications 12
- 14. Impact of Multiple CCM Applications – Planning • Cross Project Planning – Can be used across repositories through use of the ‘Tracks’/‘Contributes To’ relationship • User Load and Progress – Work allocation and scheduled absences are local to a CCM – To avoid overcommitting users, automation or careful manual work is needed to keep repositories consistent and in sync • Quick Planner only works within the same CCM application repository • Parent/Child links in planning only work if the items are in the same project area – Roll up does not work across project area boundaries – Link type is not available across repositories 13
- 15. Multiple CCM Applications – Distributed SCM • Distributed SCM provides the capability to replicate SCM data between CCM repositories • From a user perspective distributed SCM operates identical to local Jazz SCM, users – Check in change sets to a repository workspace – Deliver from the repository workspace to a stream – Accept change sets from a stream into a repository workspace • With distributed SCM a repository workspace and the flow target stream can be in different ccm repositories – The SCM system replicates (copies) the SCM data to the other repository 14
- 16. Impact of Multiple CCM Applications – SCM • Distributed SCM creates identical copies of change histories, change sets and changes made – Requires both repositories to have the same metadata model • Requires the same or a compatible CCM version on both servers – Baselines can be brought over • Only the current baseline is migrated, manually accept other baselines – Work Item links on change sets are replicated • The replicated change set only has a link back to the original work item – Snapshots are local to a repository • Snapshots can’t be replicated or transferred (unlike baselines) • No snapshot across multiple CCM repositories 15
- 17. Impact of Multiple CCM Applications – SCM • It is possible to associate work items to change sets, regardless of the repository either side lives in, using OSLC References type links – When associating a change set to a work item in another CCM repository, use drag and drop or the ‘Associate Change Request’ gesture to make the association using OSLC References links – ‘Associate Work Item’ only works within one repository – Locate Change Sets does not work with this link type • Preconditions – The out of the box deliver preconditions can only be satisfied by work item links within a repository • Required Work Item Approval • Required Work Items to Match Query • Restrict Change set delivery to Components – The precondition Required Work Items and Comments can require a change request (if owner and iteration option is set to optional) 16
- 18. Impact of Multiple QM Applications • RQM is intended to reuse as many test assets as possible, reuse is by reference and only within a QM project area • New Configuration Management capability better supports reuse across streams/configurations within the project area • Unlike CCM, there is no notion of creating associations between assets in different QM project areas, let alone QM applications • Duplicating Test Artifacts – Only supports duplication within the source project area or to a project area on the same application instance – It is possible to use the ‘as-is’ command line RQM Copy Utility to copy QM artifacts across QM applications • Built-in reporting is limited in scope to one QM application 17
- 19. Impact of Multiple RM Applications • Linking of RM artifacts between RM instances is supported, however, when doing so, these are accomplished by an OSLC References type link – For consistency, can also link between artifacts on same RM instance as an OSLC References link • Embedding of artifacts only supported within the same RM instance • In a 5.0 configuration with multiple RM instances, all JTS and RM servers must be at 5.0; mixing 4.0.x and 5.0 RM server versions is not supported 18
- 20. Impact of Multiple RM Applications • RM views that include links to artifacts from local and remote RM instances can be constructed; same performance considerations and caveats apply as when including information from CCM and QM • Quick Search limited to projects on local RM instance 19
- 21. Strategies for distributing projects And when to add another application instance
- 22. Avoid Overcommitting Your CLM Servers • It is important to avoid overcommitting your servers – Plan ahead and monitor, introduce additional CLM applications if needed • Plan and monitor license usage (concurrent usage & usage model) • Monitor CPU resources, database growth • Monitor JVM memory, heap, threads, etc. • Monitor transaction of data between servers • If you are overcommitting your server – Split multiple applications sharing a server to a dedicated server – Increase the hardware performance, CPU – Add new applications to distribute the load • Move/redistribute projects – CLM has a very limited ability to migrate data – Available options differ from application to application 21
- 23. Recommended Sizing per Application / Server • Rational Team Concert (RTC) – A: Work item only workload • 400 to 600 (concurrent work item users) – B: Combined work item and SCM workload • 200 to 300 (concurrent work item users) • 100 to 200 (concurrent SCM users) – C: Combined work item, SCM and build agent workload • 200 to 300 (concurrent work item users) • 100 to 200 (concurrent SCM users) • 100 to 200 (concurrent build agents with caching proxy in front of CCM) • Rational Doors Next Generation (RDNG) • 300 to 400 (concurrent RRC/RDNG users) • Rational Quality Manager (RQM) • 350 to 500 (concurrent RQM users) • Rational Design Manager (RDM) • 300 concurrent users • See CLM Sizing Strategy and RDM performance and scalability for details • Also Getting to a right-sized Jazz environment 22
- 24. Strategies to Distribute Projects – CCM • CCM – Strategies for Change and Configuration Management (RTC) – Keep project areas that require parent child relationships on one CCM • Consider using cross project planning and tracks relationships instead – Consider separating project areas which anticipate significant growth into different CCMs – Consider separating project areas based on logical or organizational boundaries • Keep users on a single CCM if possible – Minimize use of distributed SCM where possible • Group project areas which share code in the same CCM – ‘Move’ project areas with the least possible impact • End of a release cycle 23 Proj 1 Proj 3 Proj 4
- 25. Strategies to Distribute Projects – QM, RM • QM – Strategies for Quality Management (RQM) – Maintain as few project areas as possible – Separate QM instances if needed for scalability by • Independent, loosely coupled domains • Security (e.g. classified vs unclassified) • Subcontracting (in-house vs outsourced) • RM – Strategies for Requirements Management (RDNG) • Organize projects on RM instances along some common affinity, like common domains, systems • Projects on the same RM Instance should share common project template and have a common/unified type system • Projects requiring linking of artifacts using Built-in or Custom link types must be on same RM instance. • Linking artifacts to projects across servers must be by Reference type 24
- 26. Splitting Overcommitted Applications • If you have performance issues and overcommitted your server – Contact your IBM team to discuss your situation and available options • QM, RM – Use export/import tools or custom automation to bring data over • CCM – RTC Project Area Relocation Service Offering – Use CSV export/import and/or custom automation to copy work items – Use Distributed SCM to migrate source with history • Or start with a baseline e.g. after a release • Caveat – Split is not lossless e.g. history is usually lost • Automation can link new elements with old ones – Manual work required to bring over data • Build definitions, plans,…. 25
- 27. Example Situation • Application ccm overcommitted 1. Proj1, Proj3, Proj4 use parent child links 2. Proj2, Proj5 share SCM data 3. Proj6 and Proj7 are small and independent 4. Proj8 is about to get started • Add additional application ccm01 – Leave Proj1, Proj3, Proj4 due to many work items and complex dependencies – Move Proj2, Proj5 to ccm01 • Import open work items, leave history behind • Distributed SCM to bring SCM data over – Leave Proj6 and Proj7 on ccm • Could be moved, decision based on estimated growth – Start with new Proj8 on ccm01 • Decisions based on least work/impact • There is no right or wrong, consider – Target concurrent user distribution – History loss when bringing data over – Dependencies between projects – Data duplication 26 Proj 8 Proj 1 Proj 3 Proj 4 Proj 2 Proj 5 Proj 6 Proj 7 ccm Proj 6 Proj 7 Proj 1 Proj 3 Proj 4 ccm Proj 8 ccm01 Proj 2 Proj 5
- 28. Ongoing investigations • Exploratory work in progress that may be of interest – Investigate application clustering (381515) – Investigate automated server split capability (381516) – Publish application metrics for integration with third party monitoring tools (386672) – Provide a lightweight virtual appliance with some monitoring capabilities (390245) 27
- 29. Additional reading • See Recommended CLM Deployment Topologies • Planning for multiple Jazz application server instances • CLM Sizing Strategy • RDM performance and scalability • Getting to a right-sized Jazz environment • Multiple CCM Applications - Best Practices • Multiple CCM Applications - A User Perspective • Deployment Topologies for Jazz Reporting Service 28
- 30. Thank You