Gitflow for DevOps¶

The Overall Context¶

We define the enterprise Acme to use the following software:

OpenShift for Cloud
Argo CD for GitOps Deployments
GitLab for Software Life Cycle Management
Ansible for infrastructure as code
Backstage for Inventory Management
Active Directory or Entra for IAM

We define the enterprise Acme to build the following software: * Phippy and Goldie are apps that Acme produces. * Phippy is the frontened facing app your clients love. * Goldie is a database operator being a core service of your self-service platform. * Phippy is a one single instance app that runs on one of your production cluster. * Goldie is a one cluster service that runs on one or all the clusters. * Phippy is produced by Team A a team of PHP developers. * Goldie is produced by Team B a team of devops. * Phippy and Goldie are shipped via Argo CD and are wrapped in Helm. * Phippy and Goldie are developed with the same git workflow as well as other parts of infrastructue (ansible, terraform). * Git workflow always produces semver versions that are tested through stages.

Why to use GitFlow for DevOps?

Strong versioning and release management
Clear separation of development, staging, and production environments
Better collaboration and code review processes
Easier bug tracking, hotfix and change management
Improved CI/CD integration, goverance and automation

Gitflow Diagram¶

The following diagramm represents a unified and versioned workflow over all infrastructure projects using IaC ( ansible, terraform ), GitOps Deployments ( Argo CD, Flux ). Maybe within Acme gitflow is also used in delopment of Phippy.

---
config:
  logLevel: 'debug'
  theme: 'base'
---
gitGraph TB:

    commit id: "Initial commit" tag: "1.1.0"
    branch dev
    checkout dev
    commit id: "Development setup"

    branch feat/long-thing
    checkout feat/long-thing
    commit id: "feat: Add feature 1"
    commit id: "Update feature 1"
    commit id: "Update feature 2"

    checkout dev

    branch fix/nice-thing
    checkout fix/nice-thing
    commit id: "fix: Add fix nice"

    checkout dev
    merge fix/nice-thing

    branch feat/big-thing
    checkout feat/big-thing
    commit id: "feat: Something Big"
    commit id: "Update Something Big"

    checkout main
    merge dev tag: "1.2.0"

    checkout dev
    merge feat/big-thing

    checkout main
    branch hotfix/critical-bug
    checkout hotfix/critical-bug
    commit id: "fix: Fix critical bug"

    checkout main
    merge hotfix/critical-bug tag: "1.2.1"

    checkout dev
    merge main

    checkout dev
    checkout feat/big-thing

    checkout feat/long-thing
    commit id: "Update feature 3"
    checkout dev
    merge feat/long-thing
    checkout main
    merge dev tag: "1.3.0"

Types of Software¶

How stages are implemented depending on what software you produce.

Stages¶

There at least three stages with a different meaning.

| name | purpose | hints | | dev | Used by all the devops when they develop | - | | int | Used by all CI/CD pipelines | - | | prd | Uses by all apps in production | - |

If you produce a self-service platform, your stages need isolation. Depending on a Provider you have the following options for isolation:

Azure¶

Tennats
Subscriptions

VMWare¶

Host Groups / Cluster with seperate Networks, storage pools, LUNs

Hetzner¶

Projects

Bare Metal¶

Different Hosts in seperate Networks, LUNs, ...
Your software or infractucture is part of the self-service platform
Your software is a non platform software / app used by clients

You stages are namespaces on different kubernetes clusters and they follow a nameing convention: ${apptype}-${stage}-${appid}-${instance}.

Examples:

(cs|ap|ps)-${appid}-(dev|int|prd)-${appid}

In case your app has just one instance drop ${instance}. In this example Phippy exists just once in all the stages.

Convention: (cs|ap|ps)-${appid}-${instance}-(dev|int|prd) (Namespaces can't start with Numbers)

| name | purpose | hints | | dev | Used by all the Devops | - | | int | Used by all CI-CD pipelines | - | | prd | | - |

Versioning¶

Data Model for Inventory Management¶

In this section the model is documented with examples out of Backstage . Though it has a common meaning.

Abstract Entity Data Model¶

The phippy production instance app-phippy-prd is a Component of type website
It depends on a Component 3000 which is of type Project and belongs to the System Azure Devops of the Domain Azure
A imos client is a Group and groups have Users. That client is the owner of a Project
A partner is a Group and groups have Users. A Partner can be a member of Project.
A Kubernetes Cluster is a Ressource a Compnent like prod-3000 can relate to it.
ArgoCD will read all those definitions and will render the imos app-of-apps

What is Backstage?

A software catalog for developers / service teams

What does Backstage do?

It`s main purpose is the presentation and aggregation of data and systems as a hub.

Contributor and consumer¶

A contributor contributes compontents, resources or relations to the model
A consumer consumes compontents, resources or relations from the model for its own configuration.

Type	Contributor	Consumer
resource:licence	Lizenz Portal	-
resource:cluster/uuid-12345	Rancher	ArgoCD, Project
compontent:3000	Lizenz Portal	Devops / ArgoCD
compontent:prod-3000	DevOps	ArgoCD
compontent:test-3000	DevOps	ArgoCD
group:client01	Lizenz Portal	Rancher / ArgoCD
user:acme/team-b/bjoern.dieding	Lizenz Portal	DevOps / ArgoCD
user:acme/team-a/john.doe	?	Rancher / DevOps / ArgoCD

Dataflow and Workflows¶

All Producers write data into catalogs backstage.io/v1alpha1 (Component, Resource, User, Group)
An automation (e.g. Azure Pipeline, Script or CronJob ) creates new Customer repositories in Azure. Type: backstage.io/v1alpha1(Component->type == project )
app-of-apps chart creates crds in Kubernetes from backstage.io/v1alpha1 in Azure repository
- management.cattle.io/v3 (Rancher Project + Permissions for Groups)
- argoproj.io/v1alpha1 (AppProject,ApplicationSet + AppProject Permissions for Groups )
A ApplicationSet in Argo creates a argoproj.io/v1alpha1 (Application)
A SSO Server reads backstage.io/v1alpha1( Group, User) and creates Groups and Users in its Database