Skip navigation
All Places > DevTest Community > Blog > Authors Ulrich_Vogt

DevTest Community

6 Posts authored by: Ulrich_Vogt Employee

Customers often ask “Where do we Start” when setting up and configuring their DevTest architecture. Of course, this really depends on how they plan to use DevTest - whether using Virtual Services or running tests or maybe a combination of both. So based on potential usage of DevTest, we started building a Best Practice Architecture Guide based on real world deployments.  As a part of this initiative, we will build out several architectures that are implemented by either customers or CA Services or are new/tested architectures that fit a specific need.

Our intention is to provide options for customers, partners and CA Services on how to implement DevTest within their environment to meet the specific use cases.

 

 

This third use case walks through setting up DevTest 9.1 in Microsoft® Azure environment for multiple teams that do not work on a common project, but need segregated and separate resources to create, test and operate automated tests and virtual services.

 

ScreenShot392.jpg

 

Again and as always, comments and feedback are welcome (Koustubh.Warty, Ulrich_Vogt).

 

 

So far following detailed DevTest Architecture Best Practice Guides have been published:

 

Visualization of End-To-End transactions is one of the key features of CA Continuous Application Insight. Transactions can span multiple services of an application. If a DevTest agent instruments a service it will report only its partial view of a transaction to the DevTest broker. The DevTest broker is able to assemble partial transactions from different agents into a single complete transaction. In DevTest, this assembling of partial transactions into a single one covering end-to-end information about a transaction is called Stitching.

DevTest broker stitches transactions by comparing Meta data from these partial transactions – such as IP addresses, Message IDs, classes – and linking them if they match. Sometimes, however, partial transactions carry matching information not in Meta data but in their payload. By default, DevTest broker does not access a transaction’s payload for stitching information. Therefore, partial transactions that store matching information in their payload are not stitched together out-of-the-box.

DevTest broker supports extending and customizing its stitching procedure. DevTest Continuous Application Insight users can exploit this extension mechanism to extend and customize DevTest’s standard stitching algorithm adding stitching based on custom payload content.

Broker-1.png

This document guides the user creating and deploying a DevTest broker extension example for DevTest 9.0. This DevTest broker extension stitches together partial transactions based on data in the payload of JMS messages. The transaction frames were captured from different services in the Cars Demo application. The Cars Demo application is available in DevTest 9.0.

 

lijbi01 from CA Continuous Application Insight Development team gratefully provided several code samples and lots of instructions and insights.

 

Feedback and comments are welcome.

Customers often ask “Where do we Start” when setting up and configuring their DevTest architecture. Of course, this really depends on how they plan to use DevTest - whether using Virtual Services or running tests or maybe a combination of both. So based on potential usage of DevTest, we started building a Best Practice Architecture Guide based on real world deployments.  As a part of this initiative, we will build out several architectures that are implemented by either customers or CA Services or are new/tested architectures that fit a specific need.

Our intention is to provide options for customers, partners and CA Services on how to implement DevTest within their environment to meet the specific use cases.

 

This fourth use case sets up DevTest 9.0 in a Microsoft ® Windows Azure (Azure) environment for a large development team. The team needs multiple DevTest resources to create, test and operate automated tests and virtual services. The Source Control Management (SCM) is located on premise (on physical systems or in private cloud).

 

ScreenShot087.jpg

 

Again and as always, comments and feedback are welcome (Koustubh.Warty, Ulrich_Vogt).

 

So far following detailed DevTest Architecture Best Practice Guides have been published:

Customers often ask “Where do we Start” when setting up and configuring their DevTest architecture. Of course, this really depends on how they plan to use DevTest - whether using Virtual Services or running tests or maybe a combination of both. So based on potential usage of DevTest, we started building a Best Practice Architecture Guide based on real world deployments.  As a part of this initiative, we will build out several architectures that are implemented by either customers or CA Services or are new/tested architectures that fit a specific need.

Our intention is to provide options for customers, partners and CA Services on how to implement DevTest within their environment to meet the specific use cases.

 

This document contains the list of DevTest architecture suggestions we plan to implement and to verify in detail.

All DevTest server installations are distributed. All DevTest installations have a SCM repository server attached to store project specific artifacts (test cases, virtual services) and their versions.

  • Hybrid environment (on premise and public cloud) – server components are installed in the cloud, except for the Enterprise Dashboard service.
  • Everything Cloud (public cloud) – all server components are installed in the cloud
  • Multiple Teams – multiple DevTest server installations in the cloud
  • Large Team – single DevTest server installation with multiple VSEs and Simulators for load balancing
  • Shared DevTest Infrastructure – DevTest server installation for use by internal and external clients

 

ScreenShot031.jpg

Please let us (Koustubh.Warty, Ulrich_Vogt) know if you want us to cover additional/different architectures.

 

So far following detailed DevTest Architecture Best Practice Guides have been published:

Customers often ask “Where do we Start” when setting up and configuring their DevTest architecture. Of course, this really depends on how they plan to use DevTest - whether using Virtual Services or running tests or maybe a combination of both. So based on potential usage of DevTest, we started building a Best Practice Architecture Guide based on real world deployments.  As a part of this initiative, we will build out several architectures that are implemented by either customers or CA Services or are new/tested architectures that fit a specific need. 

Our intention is to provide options for customers, partners and CA Services on how to implement DevTest within their environment to meet the specific use cases.

This document will contain guidance on implementing DevTest on premise, in private or public clouds or hybrid environments. It will describe the specific DevTest Capabilities.

This second use case walks through setting up DevTest 9.0 in a Microsoft ® Windows Azure (Azure) environment. The Source Control Management (SCM) is located on premise (on physical systems or in private cloud).

1-BP-UC-2.jpg

Feedback and comments are always welcome.

Koustubh.Warty

 

So far following detailed DevTest Architecture Best Practice Guides have been published:

 

With the release of DevTest 8.1 earlier this month, new features have been added to all products of the DevTest suite. We've started a series of How To on those features and enhancements. As a part of this series, this document will cover Continuous Application Insight:

DevTest 8.1 - How To - Continuous Application Insight (CAI)

If there are any questions please let me know.