Self-Service

As developers operate in environments that demand speed, innovation, and continuous integration, they require tools and resources that can be accessed without bureaucratic friction or delays. A self-service model ensures that developers have immediate access to the documentation, tools, and platforms they need, thereby fostering a more productive and autonomous development process.

By minimizing external dependencies and waiting times, developers can rapidly prototype, test, and deploy their solutions, leading to quicker time-to-market and agile iterations. Furthermore, when empowered with self-service capabilities, developers are better positioned to troubleshoot issues, optimize performance, and innovate on the fly, elevating the overall quality and efficiency of software development.

We’ve now established what the platform represents and we have installed it. The next question to address is how we incorporate applications developed by stream-aligned (also known as feature delivery) teams. For this purpose, we’ll bring the GitOps paradigm, and manage these applications in a new separate repository.

Introduction to GitOps

In the GitOps paradigm, the concept of repositories hierarchy plays a crucial role in managing and deploying infrastructure and applications. The structure of repositories is not just a means of organizing files; it’s a direct reflection of the way you manage and understand your operational landscape. In this chapter, we look into the details of repositories hierarchy and propose a recommended directory structure for optimal organization and management.

The generators.yaml file within the platform chart serves a crucial role. It contains an ArgoCD definition that integrates this repository with our platform. Including this is pivotal in streamlining the deployment and management of applications across various environments.

A hierarchical repository structure aids in logically separating various concerns and helps teams to understand the state of infrastructure and applications at a glance. It’s vital to understand the repositories’ hierarchy within GitOps to ensure seamless and efficient deployment and management.

There are typically two types of repositories in a GitOps setup:

• Platform: What we covered in the section before, this repository contains definitions of the infrastructure where your applications run. It includes base Kubernetes cluster definitions, custom tools, tekton tasks, and so on. Access is restricted to to platform team members only.

• Environments often referred to as the “App Repo” or “App Config”, is where the configuration for each individual application is stored. This includes things like Kubernetes manifests for Deployments, Services, ConfigMaps, Secrets, etc.

The App Config corresponds to the applications that are running on the infrastructure. Each application would typically have its own repository, allowing developers to manage their application’s configuration independently.

Let’s create a new repository in our organization:

cd /workspaces/workspace
gh repo create $GITHUB_ORG/environments --private \
  -d 'Environments via GitOps' \
  --add-readme \
  --disable-wiki \
  --disable-issues \
  --clone && cd environments && git pull origin main

The platform folder structure we covered in the previous section where we defined what is the platform. In this section, we’ll cover the Environments hierarchy. This repository is shared with the feature delivery teams and should promote inner-sourcing practices. The repository structure index should looks like this:

├── README.md
├── applications
│   ├── dev
│   │   └── service-1.yaml
│   └── prod
│       └── service-1.yaml
└── shared.yaml

• The applications folder functions as a central registry for all applications present on the platform. This registry is an integral part of the platform’s configuration as it maintains a record of each application, enabling effective tracking and management of all deployed services.

• The shared.yaml might contain some data which we’ll make it available for all apps.

Let’s create the folder structure and the shared.yaml.

mkdir -p applications/dev applications/prod
touch shared.yaml applications/dev/service-1.yaml applications/prod/service-1.yaml

And make it ours, by changing some of the values:

yq eval -i '.org = env(GITHUB_ORG) | .domain = env(CLUSTER_NAME) | .root = env(CLUSTER_DOMAIN)' shared.yaml
yq eval -i '.aws.account = env(AWS_ACCOUNT) | .aws.account style="double" | .aws.region = env(AWS_DEFAULT_REGION)' shared.yaml

Now the shared.yaml should look similar to the object below:

org: dx-book
domain: eu-north-1.training.dx-book.com
aws:
  account: "292243477487"
  region: "eu-north-1"

And then push to the environments repository:

git add .
git commit -m "New structure with shared values"
git push origin main

Any change to the applications folder triggers a sequence of automated tasks that aim to streamline the integration of the modified or newly added application. But what’s inside each of files inside the applications folder? Let’s find out in the next section where we’ll have an in-depth look at each step.