This folder contains docs for developers. If you are looking for the usage documentation of Keptn, or the keptn CLI,
please take a look at the keptn.sh website.
- Kubernetes CLI tool kubectl
- Docker
- You have installed the Keptn CLI and have a working installation of Keptn on Kubernetes (see Quickstart).
- Docker Hub Account (any other container registry works too)
- Go (Version 1.16.x)
- GitHub Account (required for making Pull Requests)
- If you want to use in-cluster debugging, please take a look at our debugging guide.
While this is not a requirement, we recommend you to use any of the following
- Visual Studio Code (with several Go Plugins)
- JetBrains GoLand (with Google Cloud Code)
Keptn consists of multiple services. We recommend to take a look at the architecture of keptn.
The Keptn core implementation as well as the batteries-included services (helm-service, jmeter-service) are stored within this repository (keptn/keptn).
In addition, the go-utils package is available in keptn/go-utils and contains
several utility functions that we use in many services.
Similarly, the kubernetes-utils package is available in keptn/kubernetes-utils
and contains several utility functions that we use in many services.
If you want to contribute to the website or docs provided on the website, the keptn/keptn.github.io is the way to go.
Last but not least, we have a collection of additional services at
We aim to follow some rules for branch names within our repositories:
- master contains the latest (potentially unstable) changes from development
- release-x.y.z contains the release x.y.z
- feature/###/name, bug/###/name, patch/###/name, hotfix/###/name (where ### references the github issue number) contains code for branches that are under active development.
We are following the git branching model described in this blog post. For instance, if a new feature or bug branch is created, the workflow is to create a new branch of the master branch, and name it according to the convention listed above. Once ready, a new Pull Request should be created with the master branch as a target. Hotfixes work similar, but should be branched away from the master branch. PRs for hotfixes should be created to the master and respective release- branches, ensuring that the latest release and the current development version use the fix.
We have automated builds for several services and containers using Github Actions. This automatically creates new builds for
- every GitHub Release tagged with the version number (e.g.,
0.8.4), - every change in the master branch (unstable) tagged as
x.y.z-dev(e.g.,0.8.4-dev) as well as the build-datetime, - every pull request (unstable) tagged as
x.y.z-dev-PR-$PRID(e.g.,0.8.4-dev-PR-1234).
You can check the resulting images out by looking at our DockerHub container registry and at the respective containers.