Idea Details

Unleash the Developers: Improve DevTest usage and adoption for the Developers community

Last activity 06-13-2019 10:14 AM
lapol01's profile image
08-04-2016 12:33 PM

Situation / context:

Based on our local French customers and experiences feedback, the adoption of DevTest by developers is not good enough. This is a break to a larger adoption of Service Virtualization. We tried to figure out the reasons and we propose hereafter some evolutions that could change the game.

An important point to take into account is regarding how developers work: they work primarily in the context of their IDE and they don't want to install and learn an heavy infrastructure (several components with require communications between them) to fit a need like service virtualization.

Based on this, the solution should be simple and close to their working environment.

 

Proposal:

The aim of the content and roadmap presented below is to foster the Dev community adoption of CA DevTest / Service Virtualization by fitting their needs when adapted with their “way to work”.

The path (and priority) of evolutions/improvements could be seen and organised this way:

  1. Provide developers with a Java Library containing/allowing access to main essential SV actions:
    • Developers work within an IDE. From this IDE, they must be able to:
      • Create a SV from a contract (WSDL; RAML; SWAGGER …)
      • Create a SV from a Req/Resp pair
      • Deploy a SV in a VSE
    • The primary choice / approach is not to develop the plug-in (for Eclipse or another IDE) but rather to provide a Library (Java...) with main SV actions.
      • This Library could then be used to develop the appropriate plug-ins based on customer requirements and priorities :
        • IDE plug-ins: Eclipse, Netbeans …
        • CI plug-ins: Maven, Jenkins …
        • SCM plug-ins: Git …
      • A customer or partner (or CA) could develop a new plug-in and then share it with others in a "SV plug-in Store"
  2. Break the Registry dependance for the Developers community by providing a standalone "VSE light”:
    • Developers could deploy (through the Library or plug-in) a SV in:
      • A “standard” VSE (the one we know today which requires a DevTest installation with a Registry an so on…). Could be realistic for existing SV customers.
      • A “standalone VSE light” reachable through a JVM:
        • The Library/plug-in could allow to install/start this VSE light in an easy and fast way.
        • No need of heavy/complex infrastructure with several components and communications requirements.
        • The VSE light could have limited features compared with “standard” edition.
    • For developers, the goal is really to make the creation and usage of SVs as fast, as simple and as integrated as possible to their environment.
  3. Ease the way to generate new functional responses for a SV when the dependance does't exist yet:
    • Without recording (i.e.: when the service doesn’t exist yet), provide developers with a way to generate new responses with content of some fields adapted to their test requirements.
    • Could be based on TDM/Shredder but again a lightweight tool/approach as it must fit with the way developers work.

 

At least the 2 first points sounds really important for us to succeed for a better DevTest/SV adoption throughout the Developers community.

 

Regards,

Olivier and the French team.


Comments

10-18-2018 06:11 PM

As I understand, the release of codeSV and SV Community Edition has catered to the points mentioned here that talks about a Registry-less IDE as well as creating and testing VS thru code from an eclipse/IntelliJ IDE.

 

Marking this as delivered.

i agree with Oliver my suggestion is to use a mix of CodeSV and SV community edition which the developers are comfortable for local development/unit testing and for complex usecases make use of Devtest Workstation.

The assets created in SV CE are also compatible in the Enterprise edition which can then be used/extended for integration testing

10-13-2017 10:32 AM

CA SV Comminity Edition also is set up to be very useful for developers allowing them to work locally with services. 

 

It is lightweight, registry free, embedded vse engine, can integrate into the local developers CI (via CLI).

 

10-13-2017 09:53 AM

CA DevTest CodeSV seems to be addressing this idea.  Quick Start Guide · CA-DevTest/CodeSV Wiki · GitHub  

10-18-2016 04:17 PM

I agree with Olivier, a common demand signal (i.e., question) among the Dev teams is the desire for integration with their IDE and/or CD platform.  Many will not will not be adverse to using the portal to accomplish SV related work while others will want a capability where they do not need to understand DevTest to effectively utilize the software. 

08-23-2016 07:07 PM

Good Idea , Part of this problem is going to solve by DevTest Portal.

08-11-2016 12:04 PM

I believe DevTest Portal (or ultimately when DevTest Workstation is retired) does accomplish the above requirements.  The components all run on an enterprise server.  Only 1 admin is needed to make sure the components (dashboard, registry, vse) are up and running.  No need for the developer to worry about the interdependencies between the components.  So the challenge is to make DevTest Portal contain all of the functionality contained in DevTest Workstation.  Then all an organization needs is to have a CTO (Chief Technology Office) group provide the maintenance.  Developers should be able to access the DevTest portal via a url right from their IDE.

08-10-2016 05:25 PM

Good Idea.. Basically developer will be looking for something to respond quickly and move on.. unlike testing community they may not be interested (not enough time to spend apart from core work) in installing and configuring heavy weight components like devtest , vse servers etc., it would be good to have a light devtest plug in for eclipse, jdeveloper and for other popular IDE.. also good to have their VS deployed in their local env (as their own vse running on their local instance) and see monitor basic stuffs..

08-05-2016 11:55 AM

Not even OUR open source tools?

 

I agree with the sentiment of the idea (especially a 'VSE light' as a maven test-phase plugin for example) - but there may already be a better starting point.

08-05-2016 11:28 AM

In my view, yes it may work but with several conditions:

1) The customer is already a DevTest customer (why not promoting DevTest for the Dev community before that stage?)

2) Requires a very strong CD/SV sponsorship at a very high level ... unfortunately not found very often.

 

Olivier.

08-05-2016 11:25 AM

Our vision is really to make DevTest THE ServiceVirtualization tool for all the different actors, not to promote open source tools.

08-05-2016 10:22 AM

Within services we are looking to create a formal DevOps coach role, where this person will be embedded with a client for extended time to help them with such things as this, instructing them and coaching on how to properly stitch things together and how to foster adoption...etc. 

08-05-2016 10:10 AM

A lot of this is in the culture and easy path capability enablement that the company adopts and socializes.  When I was at JPMC, our CDO (Chief Development Office) that I was part of provided a Center of Capability / center of Excellence for easy onboarding of tooling.  We also had a developer desktop that came preloaded with all recommended DevOps tools (including Workstation and access to SV Catalog).  Devs could also on-demand download capability components that installed locally and equipped them for full shift-left, easy use.  Ourt team also acted as enablers socializing, teaching and promoting proper tooling to all global teams.  The Day in The Life and Night In The Life model of the recommended developer toolset was a template for adoption.

 

This said, yes we can do a better job with making DevTest more flexible, but a large portion of the ease of adoption is on the CIO/CDO to standardize, promote and enable workstation tooling in the sdlc and Day In The Life of a developer.

 

It works...I lived it

08-05-2016 08:58 AM