Service Virtualization

 View Only

Tuesdays Tips:  DevTest requires reading and planning BEFORE installing.

  • 1.  Tuesdays Tips:  DevTest requires reading and planning BEFORE installing.

    Broadcom Employee
    Posted May 19, 2015 04:17 PM

    When you move to DevTest, whether for the first time or migrating, you will quickly discover that this is not simply LISA7 repackaged into DevTest; this is a whole new platform. As a result, a brand new install is required - there is not a migration path to move historical database data forward to DevTest.  As a result, Support does not recommend that you simply get a license from the GSC, install DevTest, and start working.  The first thing Support recommends is to read the fine manual that our Documentation Team put together and Support reviewed.  We all want you to be able to successfully install/migrate with as much information and understanding as possible. This will require planning on your side to get the most efficient use of database space, disk space, and memory on your machines.

     

    I have found out that licensing is where all things start.  In DevTest, not only has licensing changed, but ACL is mandatory, you need new database installs, and there are more topics as you will discover through reading the manual on the Wiki.  Here is some helpful advice to get you started:

     

    I recommend reading the blog https://communities.ca.com/community/ca-devtest-community/blog/2014/12/19/devtest-80-licensing Arif posted on the license changes in 8.0.

     

    As mentioned above, here is a quick pointer to the documentation discussion of Administration for Licensing and general setup in our new Wiki based documentation:

     

    Administering - DevTest Solutions - 8.0.2 - CA Wiki

     

    Click on the License Administration sub category.  In this part of the document, you will find information on how the licensing has changed.  It will discuss important new ideas that you need to fully understand and put a plan in place on how you are going to monitor your license usages via the Audit Reports available from the Enterprise Dashboard (once a week, every month, once a quarter, i.e. what does your Business group require?).  Basically, you are looking at setting up a new centralized license server – Enterprise Dashboard (ED) – and having all the Registries point to it and sending connection information to be massaged into concurrent user information, who is using DevTest, where are they accessing it from, etc.  You may need a brand new server, 50 GB of database, and accessible to all of the Geo local people if one is not already at your disposal.  In addition, you may need to set up separate ED servers in Geo data centers due to the database transfer rates needed between the Registries and the Enterprise Dashboard.  You can make all Registries LDAP enabled to help with the ACL Management - please refer to the Security Section located here - Security - DevTest Solutions - 8.0.2 - CA Wiki .  You will find out how to enable LDAP, assign roles, etc.  You will need to plan out what Roles are needed, verify if Resource Groups are needed, and determine where the Administrator's new password is going to be kept for safe keeping "in case" you forget what it is.

     

    NOTE:  Yes, someone has forgotten their changed password and had to truncate the ACL Users table and reconstruct all the Users and their Roles.  CA does not have a way to recover a lost password for your security.  Please be very careful.

     

    Next, go back and look at the General Administration - General Administration - DevTest Solutions - 8.0.2 - CA Wiki - to find what the default port numbers are, how do shared vs. local installs differ, what is the proper sequence now for starting DevTest components - Running Server Components as Services - DevTest Solutions - 8.0.2 - CA Wiki ,  how to increase the memory for the various DevTest components, etc.  You will want to use this information while you are planning how many VSE Services are going to be deployed per VSE per server per Registry, how many test cases you will be running, how many monitors using CVS you will deploy, and then how much memory that will take for each of the components.  You may find that you will want 2-4 GB for your Registry, 2-6 GB for your VSE's, and even 1GB each for your Coordinators and Simulators.

     

    Note: Apache Derby is provided as an out of the box database so that you have a functioning system as you prepare to move to the enterprise database solution for your organization. Derby is not supported as an enterprise database solution.

     

    Once you have this information, then it is time to look at the new database requirements - Database Administration - DevTest Solutions - 8.0.2 - CA Wiki - where you will find that the ED (Enterprise Dashboard) has a recommendation of a separate 50 GB database.  I am sure you are asking or will have to justify that size requirement so you will be interested to know it contains all the transaction data that is gathered at the Registries and sent to the ED database from its start up for Reporting and Audit purposes.  Depending on your organization, this will quickly become large as you record each login and logout of every component and associated information therein.   Also note that each Registry is to have it's own database.

     

    At this point, you should have a good idea of the scope of DevTest's components and requirements so you can start reading the section on Installation -  Installing - DevTest Solutions - 8.0.2 - CA Wiki - and review the Preinstallation section right on through all the installation sections.  With your plan that you have constructed with the requirements necessary for DevTest, you will have a successful installation based on knowledge, planning, and execution in an informed manner.

     

    Yes, this is a lot of reading.  Yes, some of this may not apply to your specific installation right now.  However, now that you have read it, you know where to go and look for it later when you implement it as your organization's use of DevTest grows.