Gitflow for DevOps¶

Gitflow for DevOps is an agreed workflow for software development and operations teams to manage their software, code and configuration in different environments and stages in a unified way. It is based on the Gitflow branching model and is adapted to the needs of DevOps teams delivering a self-service platform to developers. The model is opinionated but is designed to be a baseline for future extensions.

The Overall Context¶

The enterprise Acme to own the domain acme.com and have in house operations and development teams.

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 postgres 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. * semver release versions are controlled and managed through conventionalcommits.

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
• Compatible for Multi-agent Collaboration in a Model similar to GasTown
• A change to an environment / application is a commit of code and configuration bundled in a new version and potentially grouped with other changes.
• Promotion of a change is decoupled from the point in time of a commit. It is a decision that can be made at any time after the commit and can be automated or manual.

Read more about the anti-pattern of mapping branches to environments for GitOps deployments.

The advantages of GitFlow over trunk-based development for operations teams

• Allows a fast moving development branch for features and fixes without affecting the stability of the main branch.
• A clear seperation of development and production
• Favors scheduled and planned release cycles for governance and compliance, which is crucial for infrastructure and operations teams.
• Enables better collaboration and code review, promotion processes

Many devops favor trunk-based development for increased agility and faster delivery.

Gitflow Diagram¶

The following diagramm represents a unified and versioned workflow over all infrastructure projects using IaC ( ansible, terraform ), GitOps Deployments ( Argo CD, Flux ). Gitflow might be not strictly enforced within Acme, but gitflow can be also used in the development of Phippy.

Types of Software¶

Diffentiating between different types of software is important to understand the different lifecycles and workflows. The following table gives an overview of the different types of software in the context of a self-service platform for software development and operations.

Lifecycle of infrastructure and software components¶

Definitions¶

An environment is a set of resources (servers, databases, configurations) where something is deployed.

A stage is a logical, ordered step in a deployment pipeline of a software or infrastructure component.

A release is a software or infrastructure component tagged with a specific version in its lifecycle and tested for the stage prd.

Stages¶

There at least three stages with a different meaning.

Team B: Platform Service Lifecycle¶

• Team B develops Goldie in the dev environment and stage.
• A stage consists of one or more clusters isolated from other environments with clusters.
• An Environment is a set of resources (servers, networks, resource groups, configurations)
• Goldie has the stages dev, int and prd.
• Goldie is being tested in the environment int via Continuous Integration Pipelines.
• Goldie is being released to the environment and stage prd.
• Team A uses Phippy in the environment prd.

Team A: Software Lifecycle¶

• Team A develops Phippy in the dev environment and stage.
• A stage consists of usually one namespace isolated from namespaces of other stages.
• An Environment is a set of mainly cluster internal resources (services, databases, configurations)
• Phippy has the stages dev, int and prd.
• Phippy is being tested in the environment int via Continuous Integration Pipelines.
• Phippy is being released to the environment and stage prd.
• Team A uses Phippy in the environment prd.

Naming conventions¶

• Namespaces can't start with numbers

For cluster services¶

For platform services¶

See ps-cloudnative-pg chart for an example of a platform service with its own namespace and ArgoCD application.

For applications¶

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

See phippy chart for an example of an application with its own namespace and ArgoCD application.

Service and Application Distribution¶

Cluster Distribution over Infrastructure Stages¶

Provider specific environments and isolation¶

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

Azure¶

• Tennats
• Subscriptions

VMWare¶

• Host Groups / Clusters in seperate Networks, storage pools, LUNs

Hetzner¶

• Projects

Bare Metal¶

• Different Hosts / Clusters in seperate Networks, LUNs, ...

Data Model for Inventory Management¶

In this section the model is implemented as an example with the inventory management system Backstage. It`s main purpose is the presentation and aggregation of data and systems as a hub.

.

Use cases for the inventory

• Developers want to find out which services and applications are available in the platform and how to use them.
• Support engineers can contact the right team responsible for a service or application.
• ArgoCD can read all those definitions to render the app-of-apps
• ArgoCD generate those definitions from the app-of-apps as a catalog.
• OpenShift can read those definitions to manage access control.

Abstract Entity Data Model¶

About goldie¶

• The platform service goldie is a Resource of type database
• goldie is part of the the system OpenShift of the domain acme.com
• Team B is a Group and groups have Users
• Team B is the owner of OpenShift and goldie.
• A Component like app-phippy-prd can relate to goldie.
• goldie can have references to the documentation, team, sources, deep links to argocd ...

About phippy¶

• The phippy instance app-phippy-prd is a Component of type website with lifecyle production
• It depends on a Component phippy which is of type Project and belongs to the System Business Applications of the Domain acme.com
• Team A is a Group and groups have Users. That Team A is the owner of a Project
• A Cluster is a Resource and a Compnent like app-phippy-prd can relate to it.
• app-phippy-prd can have references to the documentation, team, sources, deep links to argocd, openshift ui ...

Catalog and consumers¶

• A catalog contributes compontents, resources or relations to the inventory model.
• A consumer consumes compontents, resources or relations from all the catalogs for its own configuration.

Further Reading:

• Gitflow + DevOps at AWS
• The original Gitflow blog
• GitOps Branching Models compared
• GasTown
• Stop Using Branches for Deploying Different GitOps Environments