Deployments with Quality Gates

1. We will try to deploy the slow version of the carts service (v0.11.2).

   • Keptn will deploy this new version into the dev environment where functional tests will be executed.
   • After passing these functional tests, Keptn will promote this service into the staging environment by releasing it as the blue or green version next to the previous version of the service.
   • Then, Keptn will route traffic to this new version by changing the configuration of the virtual service (i.e., by setting weights for the routes between blue and green) and Keptn will start the defined performance test (e.g., using JMeter). Using the monitoring results of this performance test will allow lighthouse to evaluate the quality gate.
   • The slow version of carts (v0.11.2) will not pass the quality gate and, hence, the new version will not be promoted to the production stage (i.e., the deployment will be rejected).
   • Furthermore, Keptn will change the weights within the staging stage back to the previous working deployment of the service.

2. We will deploy the regular version of the carts service (v0.11.3).

   • Keptn will conduct the same steps as before except that this version will pass the quality gate.
   • Hence, this regular version will be promoted into the production environment.

1. Complete steps from section Setup Prometheus.

   • In these steps, you configured Keptn (more precisely the lighthouse-service) to use the Prometheus SLI provider for the project sockshop and service carts with the command:

   keptn configure monitoring prometheus --project=sockshop --service=carts
   

2. Complete steps from section Setup Prometheus SLI provider.

   Note: If you are using Keptn 0.6.0 instead of 0.6.1 or 0.6.2, you will have to apply a ConfigMap

   Please apply the following ConfigMap by executing the command from within the examples/onboarding-carts folder:

   kubectl apply -f lighthouse-source-prometheus.yaml
   

   apiVersion: v1
   data:
     sli-provider: prometheus
   kind: ConfigMap
   metadata:
     name: lighthouse-config-sockshop
     namespace: keptn
   

1. Complete steps from section Setup Dynatrace.

   • In these steps, you configured Keptn (more precisely the lighthouse-service) to use the Dynatrace SLI provider for the project sockshop with the command:
     

   keptn configure monitoring dynatrace --project=sockshop
   

2. Complete steps from section Setup Dynatrace SLI provider.

   Note: If you are using Keptn 0.6.0 instead of 0.6.1 or 0.6.2, you will have to apply a ConfigMap

   Please apply the following ConfigMap by executing the command from within the examples/onboarding-carts folder:

   kubectl apply -f lighthouse-source-dynatrace.yaml
   

   apiVersion: v1
   data:
     sli-provider: dynatrace
   kind: ConfigMap
   metadata:
     name: lighthouse-config-sockshop
     namespace: keptn
   

3. Optional: Configure custom SLIs for the Dynatrace SLI provider as specified in sli-config-dynatrace.yaml:

   keptn add-resource --project=sockshop --stage=staging --service=carts --resource=sli-config-dynatrace.yaml --resourceUri=dynatrace/sli.yaml
   

The send event new-artifact command changes the configuration of the service and automatically triggers the following Keptn services:

• Phase 1: Deploying, testing, and evaluating the test in the dev stage:

  • helm-service: This service deploys the new artifact to dev.
  • jmeter-service: This service runs a basic health check and a functional test in dev. Afterwards, this service sends an event of type sh.keptn.events.tests-finished.
  • lighthouse-service: This service picks up the event and evaluates the test runs based on the performance signature. Since in the dev environment only functional tests are executed, the lighthouse-service will mark the test run as successful (functional failures would have been detected by the jmeter-service).
  • gatekeeper-service: This service promotes the artifact to the next stage, i.e., staging.

• Phase 2: Deploying, testing, and evaluating the test in the staging stage:

  • helm-service: This service deploys the new artifact to staging using a blue/green deployment strategy.
  • jmeter-service: This service runs a performance test in staging and sends the sh.keptn.events.tests-finished event.
  • lighthouse-service: This service picks up the event and this time, the quality gates of the service will be evaluated because we are using the performance-test-strategy for this stage. This means that the lighthouse-service will send a get-sli event to fetch the metrics for the carts service from either Prometheus or Dynatrace, depending on how you set up the monitoring for your service earlier. Based on the results of that evaluation, the lighthouse-service will mark the test run execution as successful or failed. In our scenario, the lighthouse-service will mark it as failed since the response time thresholds will be exceeded.
  • gatekeeper-service: This service receives a sh.keptn.events.evaluation-done event, which contains the result of the evaluation of the lighthouse-service. Since in this case the performance test failed, the gatekeeper-service automatically initiates a rollback to the previous version in staging and the artifact won’t be promoted to production.