Skip navigation
All Places > DevTest Community > Blog > 2016 > January
2016

Thank you for attending last week's webcast "Improve Your Virtual Services Quality using Synthetic Data via CA Test Data Manager Integration\Whats new in 3.2 & 3.2.1" -- we hope that you found it valuable.

 

Whether your missed the session, or attended and simply want to run through it again, this blog post will consolidate everything in one place for you:

 

Community Event Invitation: CA Test Data Manager - Whats new in 3.2 & 3.2.1

Video Replay: Webcast Replay: Improve Your Virtual Services Quality using Synthetic Data via CA Test Data Manager Integration Webcast

Presentation:  (see attached)

 

Thank you again for attending today's event. Our next community webcast will be February 9 titled DevTest 9.0 New example application, Forward Cars Webcast

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:

The open platform that Docker provides is a game-changer for application development. The "deploy and destroy" model Docker offers is useful when consuming hardware/services from a platform as-a-service (PaaS) because it allows you to reduce your cost by only hosting and running your tools when and where you need them. With Docker containers packaging up the OS and application in a single bundle, you can easily run dev-test solutions from CA Technologies on any infrastructure or any cloud that Docker supports.

 

Here are 4 use cases our customers have shared with us on how they use Docker with Service Virtualization to accelerate their Continuous Delivery efforts:

 

1. A Catalog of Ready to Deploy Services

40 - 50% of your services are probably considered “Enterprise grade” meaning they are used by a large segment of your company. Common services that support many applications like a backend ERP system or even a 3rd party service that nearly all applications need to validate against are key areas of constraint in the development and testing cycle. Many times when companies start their Continuous Delivery journey, they start by trying to remove these key constraints by building virtual services and then sharing those services with others who have the same dependency.

 

With the onset of Docker, companies have found an easy way to create development and testing environments “on the fly” for their enterprise-grade services. By publishing the virtual services in a catalog and automatically bundling them with a Docker deployment of the Service Virtual tool along with the virtual services and test cases, they can create an automated deployment of environments for development and testing in seconds rather than days. This provides an isolated, immutable, on-demand environment for immediate consumption.

Picture1.png

2. Deployment and Testing on Demand

Similar to the Catalog concept above, customers can deploy CA Service Virtualization  on demand with a Docker image. On demand deployments, with the corresponding constraints removed, allow teams to move faster. Imagine, bundling the virtual services, with the test cases and the testing environment with a single click.

Picture2.png

3. Business in a Box

Building on the last scenario, this use case is good use for creating environments and setting the required tests that an external party must run prior to certifying their integration with your tools. So, the 3rd party (your partner) sends an automated request for testing, your team spins up a VSE in addition to the test cases and provides a Docker image on demand for that 3rd party to use. After use, the success/failure reports can be shared with the tester or with your company for “certification” of sorts.

 

4. Diverse Environments

Building and deploying various environments such as a developer onboarding, training environments and demonstration environments can all be automated programmatically with the use of Docker bundled with CA Service Virtualization and CA Application Test eliminating most errors and removing the test environment constraint in seconds.

 

Stating your team is “agile” or that you employ efficient software engineering approaches like continuous delivery is the easy part.  The hard part is executing against this vision. Combining DevTest tools and Docker together allows you to simplify software development by removing constraints and allowing you to efficiently accelerate your continuous delivery process.

 

Related Threads:

 

************************************************

2016 DevTest New Years Resolutions

  1. Remove Constraints by Trying Out Service Virtualization on Demand
  2. Accelerate My Continuous Delivery Tool Chain with Docker

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: