Kubernetes base

This is a base file for gitlab-ci.

troubleshoot

Usage

# on top of your gitlab-ci.yml

include:
  - project: gitlab-ci/kubernetes-base
    ref: v5
    file: panter-kubernetes-base.yml

Or for node apps (will automatically create a simple dockerfile):

include:
  - project: gitlab-ci/kubernetes-base
    ref: v5
    file: node-kubernetes.yml

We recommend to use a certain version as ref. Without a ref, it will always take master (latest) which might break your builds.

You need to provide the following variables in your gitlab-ci.yml:

variables:
  CUSTOMER_NAME: pan
  APP_NAME: awesomeapp
  CLUSTER_NAME: production
  COMPONENT_NAME: web # optional, if you want to have multiple services/apps into the same namespace, this needs to be different
  CHART_NAME: panter-charts/manulstack # path to a panter-charts helm chart or local path (/chart)
  APP_DIR: . # path where your app leaves (package.json) relative to the git-root
  REPLICAS: '3' # how many pods to launch (only on prod. review and stage have always 1)

Features

This include defines the following:

• test, app-build and docker-build
• deploys to kubernetes
• deploys to review environment on every branch (review apps, one per Branch)
• deploys to dev environment on every master commit
• you can trigger a semantic-release manually, which will tag the repository and deploys to prod or stage environment.
• you can manually deploy to prod from stage

release handling

You can create a release manually on the repository, which does a semantic-release, creates a changelog, bumps the version number and tags the repository. For this to work your commits need to follow semantic versionsing: fix(scope): nasty bug or feat(scope): new fancy feature.

After the repository got tagged, a deploy to prod or stage is done (depending on whether staging is enabled, see below).

In the pipeline, click on "create-release" to create a release tag and trigger therefore a new release.

hotfixing older release

You might come accross the situatio where you have a tagged version that is about to get released, but its still getting tested by the customer on staging.

Now, a wild bug occures and you have to fix that on production!

With the normal workflow you would need to fix that, merge it into master and trigger a normal release. But this will release everything that is on stage right now!

To avoid this, you can do this hotfix flow, which follows this recipe:

Let's assume your current "good" version on prod is v2.4.3 It's important that this version is the latest patch version so (v2.4.4 does not exist). This is usually in praxis, as you want to release bugfixes as soon as possible usually. So we want to have a new patched version 2.4.4 that will be our new prod :

• create a branch for the hotfix: `git checkout -b 2.4.x v2.4.3
• do your fixes and commit with a fix: commit: fix: very important bug to hotfix
• push this branch to gitlab
• this will now trigger a special pipeline where you have your usuall lint/test/build and review deploy.
• Additionaly this pipeline contains a "create-release"-step. Run this job to create the new hotfix release 2.4.4.
• this will in turn run a pipeline that let's you deploy it to prod and stage. its not done automatically. Chose the right destination for your hotfix.
• pull the branch again locally (if you want to have it in the changelog file) and merge it into master
• this might lead to conflicts now if the hotfix no longer applies, but that's ok! Maybe it was already fixed in some stage feature.

enable staging

if you set STAGING_ENABLED: "true" in your variables, it will deploy to stage first when doing a release. You can then do the prod release manually.

automatically release

if you set AUTO_RELEASE: "true", commits on master automatically creates a release and therefore deploy to prod. This is good for continues deployment.

Note: If you also set STAGING_ENABLED: "true", the automatic release will deploy to stage, so you have to deploy to prod manually.

automatic cleanup

By default your review environment will selfdestruct after 2 weeks You can not override this setting put pin the environment in the environment overview

building and testing

test and app-build stages assume a typical app with a package.json and will execute yarn test and yarn-build. You can override this:

app-build:
  extends: .app-build
  script:
    - mvn install # or whatever

Values handling

If your project contains a file called values.yml it will get passed automatically to your helm-chart.

If your project contains values-stage.yml values-review.yml or values-prod.yml, this values will be used only on deployments to the corresponding environment. These environment-specific values get merged with values.yml.

Default values:

these values are always set:

application.componentName: The value of COMPONENT_NAME, unless you are in a review-app. In this case, the name has a suffix describing the review-app. This guarantees that multiple review-apps do not collide in the namespace if used correctly in your helm-chart.

application.hostCanonical: A hostname for the app that is always defined. If you use our helm-charts this will guarantee that the app is always reachable with this hostname.