ReGradeTM Technical FAQ
How does ReGrade deploy in Kubernetes?
ReGrade can be quickly and easily deployed in Kubernetes by using a Helm chart. ReGrade can run as a set of three pods, each with one container. The three containers are a PostgreSQL database, a UI/API container, and a network sensor container. The configuration and results are stored in the PostgreSQL database. Both the UI and the sensor container are designed to scale horizontally, and therefore are compatible with Horizontal Pod Autoscaling (HPA) with the requirement that sticky sessions are used by the load balancer.
Figure 1. REGRADE IN KUBERNETES
How does ReGrade deploy in AWS?
ReGrade can be quickly and easily deployed in AWS using a CloudFormation template. ReGrade uses Amazon Relational Database Service (RDS) to store the product configuration and comparison results. The UI/API container and the network sensor can both be run in Fargate. Amazon Elastic Load Balancers (ELBv2) are configured to provide access to the UI and the network sensor. Because of the variety of the AWS ecosystem, there are many alternative ways to deploy ReGrade not discussed in depth here. To name a couple examples: a deployment with easy autoscaling can be achieved by deploying into Elastic Beanstalk instead of Fargate, or passive deployments can be achieved by using AWS VPC Traffic Mirroring.
The diagrams below show a deployment using ECS and Fargate to host the ReGrade containers. The first diagram shows the deployment of RDS, the UI ECS Task, and the UI ELB instance along with all of the associated security groups and roles for the deployment. The second diagram shows the deployment of a sensor instance, also with an ELB front end to allow access. The load balancer has been configured to use HTTP for the sake of simplifying the example, but in the case of a TLS deployment the appropriate certificate would be provided to the load balancer as well.
Figure 2. RDS INSTANCE AND USER INTERFACE
Figure 3. FRONT END SENSOR AND LOAD BALANCER
How does ReGrade deploy in a RedHat Virtual Machine?
ReGrade can be quickly and easily deployed in a RedHat 8 environment by running a single installation shell script on a fresh VM. The script will install and configure podman to run a PostgreSQL container, a UI container, and a network sensor container on the same VM. Because of the scaling limitations inherent in running on a single VM, this deployment model does not support auto-scaling.
Figure 4. REGRADE RUNNING ON A REDHAT VIRTUAL MACHINE
How does ReGrade work in Jenkins?
ReGrade integrates well with the unit test or integration test stages of your Jenkins pipeline. Your existing tests such as Selenium or LoadRunner can be augmented by running them in a way that compares the current build to the last known stable build. Developers can configure the expected changes for their work before check-in, allowing expected changes to be automatically filtered out. The ReGrade API allows easy integration with the Jenkins workflow to launch sensor instances, filter results based on expected changes, and make go or no-go decisions based on the results.
Figure 5. REGRADE IN A JENKINS PIPELINE
How does ReGrade work in Azure DevOps?
ReGrade integrates well with the unit test or integration test stages of your Azure DevOps pipeline. Your existing tests such as Selenium or LoadRunner can be augmented by running them in a way that compares the current build to the last known stable build. Developers can configure the expected changes for their work before check-in, allowing expected changes to be automatically filtered out. The ReGrade API allows easy integration with the Jenkins workflow to launch sensor instances, filter results based on expected changes, and to provide a final gate for release.
Figure 6. REGRADE IN AZURE DEVOPS
Does testing a service require running all of its backing services?
No. ReGrade has two capabilities that can reduce the need to run additional services for testing.
First, ReGrade provides a service virtualization/mocking capability. ReGrade can observe the interactions between the primary service and its backing services. Then, for the secondary services under test, ReGrade can act as if it is the backing services by matching up the queries and providing the corresponding response. This allows a secondary test service to run without needing to also duplicate its entire backing environment.
Second, ReGrade provides a replay capability. Traffic going to and from an original service can be recorded and replayed at a later time when the original service is no longer running. Thus, a single service in an ecosystem can be tested by replaying both the front-end requests and the responses that it receives from the backing services. In the diagram below, a service is shown that has a backend SQL database. However, this can be generalized to any supported protocol such as other REST APIs, etc.
Figure 7. REGRADE IN AN ENVIRONMENT WITH BACKEND SERVICES
Can ReGrade test Functions as a Service (FaaS)?
Yes. Functions are services that operate on network traffic as their inputs and outputs. ReGrade is deployed the same as it would be otherwise and configured with the host and port information to reach both the old and new versions of the function.
How does ReGrade handle known or expected changes to service behavior?
ReGrade has a rules and filtering system that allows developers or QA engineers to describe the changes they intend
to make to the new software release. Adding a new API call, modifying the set of HTTP headers, changing the
structure of a JSON document, or just upgrading libraries are all operations that the developer can describe before
release in terms of what they expect to change. When running their unit tests, they can verify before check-in that
they see the changes they intend to introduce and only those changes. Once this information is placed in the ReGrade
database it is available for use in all future test runs, both manual and automated. Because developers can input
their intentions early in the process, tests at later stages only document the relevant information about unintentional
changes.
ReGrade offers the advanced benefit that if more intensive testing later finds an unintended change in some part of
the product that the original developer did not test, that change will always be discovered. With this approach, test
failures can now occur even when no one anticipated a particular failure mode. Changes that were previously missed
because the specific test was not present are now detected because ReGrade discovered a change in software
behavior that was not intended by any of the developers.
Contact Curtail today for additional information, demo or a free trial. Call us at 805-880-1268. Email us at info@curtail.com. Or visit www.curtail.com
This document is provided for informational purposes only. This document is not warranted to be error-free, nor subject to any other warranties, whether express orally or implied. The technologies, services, or processes described herein are subject to change without notice.