Skip to content

@johannes-b johannes-b released this Jul 25, 2019

Release Notes 0.4.0

This release makes it easier to install and to try out Keptn by a significantly reduced footprint and a faster installation process. Consequently, you can run Keptn on a small Kubernetes cluster to deploy your services with automated quality gates and get started with self-healing with your application.

  • In terms of virtual CPUs, the smaller footprint means a reduction by 75 percent since Keptn 0.4.0 requires just 4 vCPUs instead of 16. Also, memory consumption is reduced by the same factor.

  • A faster installation process means that the stopwatch measures that Keptn 0.4.0 can be installed in under 6 minutes (depending on the Cloud Platform).

From a technical perspective, Keptn 0.4.0 does not rely on Knative but rather uses an eventing mechanism based on NATS and Keptn core components. These core components (i.e., dispatcher and eventbroker) are responsible for distributing the Keptn CloudEvents to the Keptn services that have a subscription to the corresponding CloudEvent type.

New Features

  • Implementing eventing without Knative #505
  • Keptn CLI: Deploy the installer as a Job instead of Deployment #456
  • Keptn CLI: Correct error message output in install command #510
  • Keptn CLI: Removed --wait option when deploying the installer Job #512

Fixed Issues

  • Fixed issue in wait_for_deployment function #550
  • Addressed adherence to cloud events: Changed datacontenttype to contenttype #405
  • Added missing cloudevents header and source property #405

Upgrade Keptn 0.2.x or 0.3.0 to 0.4.0

  • Upgrading a previous Keptn version to Keptn 0.4.0 is not supported due to the breaking change in Keptn's architecture. However, instructions to delete an old Keptn installation and to install Keptn 0.4.0 are provided here

Known Limitations

  • Only one GitHub organization can be configured with the Keptn server (will be addressed in #210)
Assets 8

@agrimmer agrimmer released this Jun 28, 2019 · 54 commits to master since this release

Release Notes 0.3.0

New Features

  • Support installation on an AKS cluster #3
  • Support installation on Openshift cluster #4

Fixed Issues

  • keptn CLI: Fixed typo - Changed artefact to artifact #387

Known Limitations

  • On OpenShift, the keptn's log and keptn's bridge are currently not suppored. Logging capabilities for OpenShift will be added in subsequent releases.
Assets 8

@johannes-b johannes-b released this May 29, 2019 · 133 commits to master since this release

Release Notes 0.2.2

This release improves the usability and stability of keptn. More precisely, it significantly improves the experience of installing keptn, executing commands using the keptn CLI, and deploying new applications.

New Features

  • keptn CLI: New command for installing keptn #272

  • keptn CLI: Receives constant status updates during the execution of CLI commands #203

  • keptn CLI: New commands for sending new artifact events and arbitrary keptn events #326

  • The name of the namespace has the project name as prefix, e.g., sockshop-dev, sockshop-production #229

  • Service configuration files follow the naming scheme: servicename-servicetype.yaml #295

  • Hard-coded URLs for Dynatrace SaaS tenants are removed to support Dynatrace-managed tenants #255

  • Deploys dynatrace-service when Dynatrace monitoring is activated #268 #354

  • The deploy pipeline does not send the Dynatrace deployment event since this is handled by the dynatrace-service #268

Fixed Issues

  • Fix no healthy upstream-problem during blue green deployment #332
  • Bugfix in roll-back step of evalution_done and run_tests pipelines #292
  • Set visibility of service to cluster-local #396
  • Correct typo in eventbroker and control service #268
  • Log reason for failed service onboarding #274
  • Mark evaluation as failed when no data can be retrieved from Dynatrace #380

Upgrade keptn 0.2.0 or 0.2.1

  • To upgrade a keptn 0.2.0 or 0.2.1 installation to this release, follow the instructions provided here

Known Limitations

  • Installation is only supported for GKE (more platforms to come)
  • Only one GitHub organization can be configured with the keptn server (will be addressed in #210)
Assets 8

@jetzlstorfer jetzlstorfer released this May 3, 2019

Release Notes 0.2.1

This release is a stability improvement release. All use cases work like with 0.2.0 and this release significantly improves the installation experience of keptn.

New Features

  • Improved installation script that verifies each steps of the installation to provide accurate feedback of the installation procedure #250 #285

Fixed Issues

  • Invalid characters in project and service names now detected by keptn CLI #292
  • Error handling in core services #287

Version dependencies:

keptn is installed by using these images from the keptn Dockerhub registry:

  • keptn/keptn-authenticator:0.2.1
  • keptn/keptn-control:0.2.1
  • keptn/keptn-event-broker:0.2.1
  • keptn/keptn-event-broker-ext:0.2.1
  • keptn/pitometer-service:0.1.1 (fixed issue #291)
  • keptn/servicenow-service:0.1.0
  • keptn/github-service:0.1.1 (fixed issue #265)
  • keptn/jenkins-service:0.2.0 (fixed issues #250 #268, known limitations #292)
    • keptn/jenkins-0.5.0

Known Limitations

  • Installation currently only on GKE (more platforms to come)
  • Only one GitHub organization can be configured with the keptn server (will be adressed in #210)
  • For use cases that require Dynatrace: support for Dynatrace SaaS tenants only (will be adressed in #255)
  • keptn CLI output not reliably reflecting success/error of keptn services: the CLI only reflects the successful acknowledgment of the CLI command but not its successful execution (will be adressed in #203 #143)
Assets 8

@jetzlstorfer jetzlstorfer released this Apr 10, 2019 · 145 commits to release-0.2.x since this release

Release Notes 0.2.0

Release Goal

The goal of this release is to provide a keptn installation that comes with automated quality gates evaluation, different deployment strategies, a dedicated keptn CLI and integration with 3rd party vendors to allow you to build your cloud-native delivery.

Automated setup

This release comes with scripts that automatically install keptn on your GKE cluster and set up all needed components including Istio, Knative, Kibana and all keptn services. Additionally, keptn creates namespaces for the different stages your service will go through (e.g., dev, staging, production) to ensure resource isolation.

Easy onboarding of custom services

With the keptn CLI custom services can be onboarded so keptn takes care of delivery. For onboarding, a so-called shipyard file is needed that defines which stages have to be created and also defines the quality gates that have to be passed for artifacts to be promoted from one stage to the other. This release comes with a demo service that can be onboarded and defines the following stages in its shipyard file: dev, staging, production, as well as a deployment and testing strategy for each stage.

Deployments with automated quality gate evaluation

  • Quality Gates: Once services have been onboarded, keptn takes care that only built artifacts that pass the quality gates will be promoted to next stage. The quality gates are automatically validated by our Pitometer component, which already provides integrations for Prometheus and Dynatrace monitoring but also allows developers to integrate their own data sources. The actual validation in Pitometer is done by leveraging a so-called perfspec file that defines checks for given metrics, e.g., the response time of a service has to be lower than the defined threshold.

  • Deployment Strategies: In addition to quality gates, keptn provides different deployment strategies for onboarded services. For example, a direct deployment directly replaces the old version of the artifact with its new version, while a blue/green deployment strategy deploys the artifact in a separate version (e.g., blue) while retaining the previous version of the artifact (e.g., green). This allows performance tests and the quality gate evaluation on the blue version while the green version might still handle user traffic. Only if the blue version passes the evaluation it will replace the green version by rerouting all traffic to the blue version. This also allows an instant fallback to the previous version if some (production) issues are detected.

Runbook automation and self-healing

While keptn provides means to ensure high quality of all onboarded services as they get promoted through the different stages, an issue free production environment cannot be guaranteed. For example, changes at runtime might cause problems that have to be handled quickly and reliably.

In this release, keptn provides an integration with ServiceNow and Dynatrace to trigger workflows in ServiceNow if Dynatrace detects problems in your environment. In the demo that is shipped with this release, the service is prepared to allow for configuration changes at runtime, which will introduce an increase of the failure rate. This increase is detected by Dynatrace and a problem notification is sent to keptn. In keptn, the ServiceNow service will create an incident in the provided ServiceNow instance which will trigger the workflow to revert the configuration change in the production environment.

Unbreakable delivery pipelines

keptn provides an unbreakable delivery pipeline, which prevents that bad code changes are impacting your end users by ensuring that only high quality code can be promoted to subsequent stages and eventually into production.

Thereby it relies on three concepts:

  • Shift-Left is the ability to pull data for specific entities (processes, services, or applications) through an automation API and feed it into the tools that are used to decide on whether to stop the pipeline or keep it running,

  • Shift-Right is the ability to push deployment information and metadata to your monitoring solution (e.g., to differentiate BLUE vs GREEN deployments), to push build or revision numbers of a deployment, or to notify about configuration changes,

  • Self-Healing is the ability for smart auto-remediation that addresses the root cause of a problem and not the symptom.

Version capabilities:

keptn is installed by using these images from the keptn Dockerhub registry:

  • keptn/keptn-authenticator:0.2.0
  • keptn/keptn-control:0.2.0
  • keptn/keptn-event-broker:0.2.0
  • keptn/keptn-event-broker-ext:0.2.0
  • keptn/pitometer-service:0.1.0
  • keptn/servicenow-service:0.1.0
  • keptn/github-service:0.1.0
  • keptn/jenkins-service:0.1.0
    • keptn/jenkins-0.4.0

Known limitations:

  • installation currently only on GKE (more platforms to come)
  • no multi-tenant functionality yet (only one GitHub organization can be configured with the keptn server)
  • for use cases that require Dynatrace: support for Dynatrace SaaS tenants only (managed support to come)
  • keptn CLI output not reliably reflecting success/error of keptn services: the CLI only reflects the successful acknowledgment of the CLI command but not its successful execution
Assets 8

@bacherfl bacherfl released this Apr 4, 2019

Release Notes v0.1.3

⚠️ Please note that this version does not allow to onboard custom services. If you want to onboard your own services we recommend using the latest release version of keptn

This is a bugfix release of version 0.1.2. It does not add any usecases but fixes a problem that prevented the Dynatrace OneAgent to communicate with the Dynatrace Tenant. This version now uses Istio 1.1, which allows outbound traffic per default.

The updated instructions can be found on the keptn.sh website.

Fixed bugs:

  • fixed a problem with Istio that prevented the OneAgent to communicate with the Dynatrace Tenant
Assets 2

@jetzlstorfer jetzlstorfer released this Mar 24, 2019 · 5 commits to release-0.1.x since this release

Release Notes v0.1.2

This is a bugfix release of version 0.1.1 as well as 0.1.0. It does not add any use cases but does address bugs that prevented automated setup of some components and prevented frictionless operations of the use cases.

The updated instructions can be found on the keptn.sh website.

Fixed bugs:

  • installation now ready for Dynatrace OneAgent Operator v0.3.0

Improvements:

  • updated Performance Signate Plugin in Jenkins to version 3.1.1
  • added script to setup Kubernetes API connection to Dynatrace (for Kubernetes Dashboard)
Assets 2

@jetzlstorfer jetzlstorfer released this Feb 26, 2019 · 36 commits to release-0.1.x since this release

Attention: this release has a known bug that results in a failing installation of the Dynatrace OneAgent Operator. The bug is fixed in v0.1.2

Release Notes v0.1.1

This is a bugfix release of version 0.1.0. It does not add any usecases but does address several bugs that prevented automated setup of some components and prevented frictionless operations of the use cases.

The updated instructions can be found on the keptn.sh website.

Fixed bugs:

  • fixed outdated Jenkins configuration
  • fixed pipelines that where tagging docker images incorrectly
  • fixed wrong URL in Ansible script
  • fixed null value bug in production pipelines

Improvements:

  • added logging to setupInfrastructure.sh and forkGithubRepositories.sh
  • using Ansible vault for storing credentials
  • automatically create Dynatrace request attributes during setup
Assets 2

@jetzlstorfer jetzlstorfer released this Feb 15, 2019 · 78 commits to release-0.1.x since this release

keptn Release Notes v0.1

Release Goal

The goal of the V 0.1 release for keptn is to provide an MVP (minimum viable product) for an autonomous cloud fabric supporting major use cases based on a demo application.

Automated Setup

This release of keptn provides an automated setup for the keptn core components as well as a demo application. The setup only requires a Kubernetes cluster with minimum master version 1.10.11. Detail specs can be found in the getting started section.

If you want to use keptn with your own application, you will have to modify the keptn setup files. Future versions will provide a smoother onboarding experience.

Automated Multistage Pipeline

Keptn supports a three-stage continuous delivery pipeline with the following stages:

  • Development - for integration testing
  • Staging/Continuous Performance - for production-like performance testing
  • Production - production deployment with automated load generation

Automated Quality Gates

Keptn provides a quality gate from the development to the staging and from the staging to the production environment. While the gate in development is a basic check regarding the availability of the service, the quality gate in staging assumes an execution of a performance test that gets validated against a performance signature. This signature defines the thresholds to mark a deployment as unstable and to stop the delivery pipeline.

The use case provided in this release is as follows:

  1. The source code of a service is changed, and the service gets deployed to the development environment.
  2. The service passes the quality gates in the development environment.
  3. However, the service does not pass the quality gate in staging due to an increase of the response time detected by a performance test.

Automated Runbook Automation with Ansible

Keptn provides runbook automation as an auto-remediation approach in response to detected issues in a production environment. Therefore, keptn automatically sets up and configures an Ansible Tower instance during setup. The example ships with predefined playbooks that are capable of updating the configuration of a service in production, defining configuration change events, and reacting on them in case of detected issues.

The use case provided in this release is as follows:

  1. A configuration change is applied to a service in the production environment, leading to an increase of the failure rate.
  2. An issue is detected in production and a problem ticket is opened.
  3. The configuration change is automatically reverted.

Production Deployments with Canary Releases

Keptn provides the runbooks to release a new version and to automatically switch back to the previous version if an issue is detected. As described above, keptn relies on Ansible Tower for auto-remediation capabilities. Thus, keptn is shipped with pre-defined playbooks that can deploy a new version and take care of re-routing traffic in case of detected problems.

The use case provided in this release is as follows:

  1. A faulty service version is deployed to the production environment and traffic is routed to this new version in a canary release manner, starting with only 10 % of the traffic and increasing this percentage over time.
  2. An issue is detected in production and a problem ticket is opened.
  3. The traffic routing is changed to redirect traffic to the previous (non-faulty) version.

Attention: this release has a known bug that results in a failing installation of the Dynatrace OneAgent Operator. The bug is fixed in v0.1.2

Assets 2
You can’t perform that action at this time.