No description
  • Go Template 61.6%
  • Go 25%
  • Shell 11.6%
  • Dockerfile 1.8%
Find a file
renovate_token_read_write a373891d31 Renovate/kyverno 3.x
2026-10-22 14:33:10 +02:00
development EN-5948/align bootstrap managed 2026-10-08 14:25:06 +02:00
rendered/enabling-test Renovate/kyverno 3.x 2026-10-22 14:33:10 +02:00
tests Add otel image tag 2026-09-21 15:05:22 +02:00
.chainsaw.yaml EN-4845/Add functional test coverage 2026-06-04 11:18:00 +02:00
.editorconfig Enabling deploy 2026-05-07 14:48:06 +02:00
.gitignore Various fixes to the vcluster setup: 2026-09-15 10:41:34 +02:00
.gitlab-ci.yml FIX: remove faulty target revision ref 2026-10-08 15:16:50 +02:00
appset.yaml FIX: remove faulty target revision ref 2026-10-08 15:16:50 +02:00
dev.helmfile.yaml.gotmpl Ops/increase memory argocd and loki enabling-test 2026-10-09 13:55:35 +02:00
flow.helmfile.yaml Renovate/kyverno 3.x 2026-10-22 14:33:10 +02:00
kustomization.yaml En 5733/vcluster enabling argocd 2026-10-08 08:09:53 +02:00
README.md EN-5948/align bootstrap managed 2026-10-08 14:25:06 +02:00
renovate.json chore(renovate): Update config 2026-06-02 08:47:41 +02:00

Flow Platform

Flow is RWS WM's development and deployment platform.

Purpose and Goals

The Flow Platform intends to streamline development and operational workflows.

It aims to:

  • Provide a robust, simple and scalable environment for building, testing, and deploying applications.
  • Provide standard solutions for common operational problems. Said problems include, but are not limited to:
    • Continuous Integration and Deployment
    • Secrets Management
    • Policy Management
    • Observability: monitoring, logging and tracing
    • Certificate and trust management
    • Identity and Access Management (not implemented yet)
    • Alerting (not implemented yet)
    • Self-service PostgreSQL (not implemented yet)
    • API management (not implemented yet)
  • Make the deployment and operation of our applications consistent, using a reduced number of technology stacks, so TABers can easily switch between applications.
  • Enable multitenancy and separation of concerns.

Target Users

There are two main groups of target users

  • Suppliers. They are concerned with the development and testing of the applications. They value ease of use, quick turnaround and independance.
  • TABers. They value stabiliity, consistency and predictability.

Core Components

The platform consists of the following core components:

Flow Platform deployment pipeline

graph TD
  Node1[Gitlab-CI PRE stage]
  Node1 --> Node2[deploy eso on wm-tooling]
  Node1 --> Node3[deploy trustmanager on wm-tooling]
  Node1 --> Node4[render Flow manifests]
  Node1 --> Node5[render test manifests]
  Node5 --> Node101[Gitlab-CI tooling stage]
  Node4 --> Node101
  Node3 --> Node101
  Node2 --> Node101
  Node101 --> Node102[bootstap]
  Node101 --> Node103[deploy wm-infra external secrets on tooling cluster]
  Node101 --> Node104[deploy Argo CD on tooling cluster]
  Node102 --> Node201[Gitlab-CI cluster stage]
  Node103 --> Node201
  Node104 --> Node201


  Node201 --> Node202[Child pipeline for cluster 'X']
  Node202 --> Node203[Deploy Argo CD agent on cluster 'X']
  Node203 --> Node204[Deploy Flow apps for cluster 'X' to tooling Argo CD]
  Node204 --> Node205[Deploy external secrets to cluster 'X']

  Node201 --> Node302[Child pipeline for cluster 'enabling-test']
  Node302 --> Node303[Deploy Argo CD agent on cluster 'enabling-test']
  Node303 --> Node304[Deploy Flow apps for cluster 'enabling-test' to tooling Argo CD]
  Node304 --> Node305[Deploy Flow tests for cluster 'enabling-test' to tooling Argo CD]
  Node305 --> Node306[Deploy external secrets to cluster 'enabling-test']

vcluster on featurebranches

To prevent concurrency issues on our internal test cluster, we introduced vcluster based deployments when our pipeline runs on other branches then the main branch. The manifests are rendered the same way as for the actual cluster, what has to be different in a vcluster is done in the pipeline and in appset.yaml.

The pipeline contains a set of additional step to make sure the vcluster is set up first and payloads deployed to it are accessible using special ingresss URLs.

Exceptions:

  • Branches created by renovate matchting ^renovate.* run their pipeline against the actual enabling-test cluster.
  • The same goes for branches with 'vclusterdisabled' in their branch name.

Local / helmfile deployment

Our deployment is based on helmfile. We tested with version v1.7.0 but anything newer should also work. Also we depend on the helm 'diff' plugin. One way to get it is using the source repository:

helm plugin install https://github.com/databus23/helm-diff --verify=false