Ship it!

Ship it! is Wattpad's tool for continuous deployment to Kubernetes.

The technical background and architecture of Ship-it can be found in the overview documentation here

Operations

Continuous Deployment

Ship-it watches HelmRelease custom resources in the namespace in which it is deployed. Whenever a HelmRelease resource is created/updated/destroyed, Ship-it performs the appropriate install/upgrade/delete Helm operation on the associated Helm release.

An example of a minimal HelmRelease definition:

apiVersion: shipit.wattpad.com/v1beta1
kind: HelmRelease
metadata:
  name: my-release-name
  annotations:
    helmreleases.shipit.wattpad.com/autodeploy: "true"
spec:
  releaseName: my-release-name
chart:     repository: my-chart-repository     name: my-chart-name     version: my-chart-version
values: {}

As a quick overview, there are 4 important sections to take note of.

• metadata.annotations enrich the HelmRelease with additional information.

Annotations are always optional, however the HelmRelease will not autodeploy as the default is false. All annotations recognized by Ship-it are prefixed by helmreleases.shipit.wattpad.com/

| Annotation | Description | Default Value | | ---------- | ----------- | ------------- | | autodeploy | Toggle auto-deployment of the release | "false" | | code | Source code URL | "" | | datadog | Datadog dashboard URL | "" | | squad | Squad owner of the release | "" | | slack | Slack channel of the owner | "" | | sumologic | Sumologic query URL of the release | "" |

• spec.releaseName defines the desired name of the Helm release

• spec.chart provides the desired chart name and version

• spec.values provides the desired chart values. In this example the service

does not provide any overriding values for the chart, however the field is still explicitly required

A much more thorough documentation of the HelmRelease custom resource can be found in the resource definition, or by kubectl describe crd/helmreleases.shipit.wattpadhq.com in a cluster namespace where the CRD exists.

Automatic Rollback

Ship-it initially has limited support for automatic rollbacks. When a Helm release enters the FAILED state, Ship-it will perform a Helm rollback operation to the most recent successful release version. Most often, this will be the immediately previous release version.

Developers should take note that a FAILED Helm release is caused by deployment errors, not application runtime errors. Some non-exhaustive examples are: incomplete chart values or corrupted manifests produced by invalid templates, failure to create resources in the desired namespace, or tiller internal error. A Helm release will not fail because a Pod crashes after its deployment is successfully rolled out.

In the future, we plan to add support for more advanced rollback strategies such as rollbacks triggered by failing liveness/readiness health probes or developer defined conditional expressions on service metrics.

Local Development

This project uses kind for local development and testing. To get started, you'll need to install these tools to your development machine:

• helm: https://github.com/helm/helm
• kind: https://github.com/kubernetes-sigs/kind

• Create a new kind cluster

$ make kind-up

• Update kubectl's cluster context

$ export KUBECONFIG=$(kind get kubeconfig-path --name="ship-it-dev")
$ kubectl config current-context
kubernetes-admin@ship-it-dev

• Build local images

$ TARGET=ship-it-api make build
$ TARGET=ship-it-syncd make build
$ cd operator && make docker-build

• Deploy local ship-it images

$ make kind-deploy

• Connect to the service's node port (check the chart values)

curl -i http://localhost:31901/api/releases

or

open http://localhost:31901

• Destroy cluster when finished

make kind-down