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

DevTest Community

2 Posts authored by: gupra11

Control your destiny with Virtualization Driven Development (VDD).

VDD.png


VDD decouples teams in early development cycles by allowing changes in the virtual world, where team members are in full control of their destiny!

 

Background: This project (customer: anonymous) is in the middle of upgrading the end-user look & feel of the product by embracing some of the latest UI technologies. It’s a large modernization initiative involving many development teams at different layers in the architecture.


Real World: Since modern UI is the main driver, UI development team needed a lot of data scenarios (both quantity and quality) to develop and test for things like table pagination, scrolling and performance of the new portal. In this real world, developers send data requests and wait for business analysts and other teams to populate data in all different dependent systems. They wait and wait; only sometimes being lucky enough to get back a handful of useful data. The team lacks true control of their own deliverables (destiny); they are at the mercy of teams, systems and data. It’s not an easy problem to solve when you have to populate data across multiple systems of records, mainframes and also partner channels.

 

Virtual World: In the virtual world, instead of waiting for a real, end-to-end environment with questionable data, the UI development team decided to use virtual services in place of real systems. A team member updated virtual services for different permutations and combinations of data scenarios enabling the team to proceed with the

development and testing of the UI. As a result, the team successfully developed and tested pagination, scrolling, and even performance of the web pages without any delays. However, the fun just began - as the team made changes to the UI, they discovered changes needed in the backend services.


In the real world, they would have sent the newly discovered requirements to the backend team and waited for another sprint (or two) to integrate. However, in the virtual world, there is no such constraint. The UI development team still shared the discovered gap with the backend team, but didn’t wait for their deliverable. Another team member updated the service definitions (and associated data) in the virtual world, and the team proceeded further with the UI changes.

 

At the end of the sprint, they had a fully developed (and tested) UI and a reference implementation of the all the changes needed in the backend services inside the virtual world. This reference implementation was then passed to the backend services team to make sure they could validate their enhancements against these changes.

 

In the virtual world, the developer is king! The team gets what they want, when they want it, and how they want it, and deliver high-quality products on time. As for ruling the real world, that’s a topic for another day!

DevOps: It's a cultural change that starts with collaboration between people.

 

I bet you have heard this many times. The statement is absolutely true, but the DevOps journey doesn't necessarily begin from collaboration. In fact, there is no single recipe of success. That's the beauty of it -- everyone can make a difference from wherever they are. For any enterprise level transformation, Change Management and COE are critical concepts that can allow different business units and teams to benefit from "economies of scale" and "economies of learning". DevOps journey is no different, however, there are two interesting components that can make this journey easier and much more fun: "Standardization" and "Automation".

 

metaphor-car_lights_highway.jpgStandardization: Variety is the enemy of stability, and hence has an adversarial relationship with Operations. Variety means too many variables, and every variable in turn comes with its own set of dependencies. The less the variety, the fewer variables, resulting in a decrease in risk associated with fast paced changes coming down the conveyer belt.  Standardizing technology, architecture, tools, and processes has tremendous impact; it not only reduces risk but also paves the path for extreme Automation. Cloud Manager Platforms are a perfect example of how they use policy based pre-defined blueprints to establish standards across teams. They minimize the variables involved and help enforce a standard.

 

Automation: Most Analysts credit automation as the critical ingredient for DevOps success. It's clear that manual labor is not only slow, but also error prone because of the human capital involved. Quality issues and longer release cycles are common issues attached to manual labor. Automation has obvious benefits around improved quality and time to market. There’s a reason why you hear numerous “continuous” terms such as continuous build, continuous integration, continuous validation, and continuous delivery. Automation encapsulates every possible manual step, which can be automated - including automation of environment, releases, testing, code promotion, and even the feedback loop.

 

Double down on Automation: The problem with automation is that it still requires manual labor i.e. the process of automation itself is Manual. For example, manually automating test cases is also slow and error prone -- automating regression tests can take weeks and/or months and still results in questionable coverage. In this era of self-driving cars and fast-paced feedback loops, automating the automation is not a far-fetched goal. In fact, DevOps data mining uses the feedback look to auto-generate regression baselines, which not only shrinks months to weeks and days, but also keeps your test coverage close to 100% at all times.

 

Has Standardization or Automation enabled you to gain speed in your DevOps initiative? Have you tried doubling down on automation? Are you interested in telling others about it? You could have the opportunity to speak at CA World with a sponsored event registration!