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

Idea created by lapol01 Employee on Aug 4, 2016

    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.



    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.



    Olivier and the French team.