The Configuration Centralization Pattern

In today’s software development environment, especially in decentralized settings, efficiently cataloging and sharing solutions is a pressing concern. This becomes particularly noticeable when teams expand to a point where maintaining consistent communication becomes challenging. Moreover, the effort to distribute common libraries across diverse software divisions, each with its unique approach, adds to this complexity.

The configuration centralization pattern offers a solution. This method addresses these challenges by adeptly managing data from various repositories. Throughout this chapter, we’ll explore the intricacies of this pattern, highlighting its potential to consolidate scattered data and boost its visibility.

A pivotal part of our discussion will be introducing a unified view hosted on GitHub Pages. This tool presents repository information in a clear and user-friendly manner, underscoring the significance of not...

Technical requirements

To follow along with the hands-on material in this chapter, you will need to follow the steps in the previous chapter or access the resources from that chapter and refer back to it if anything is ambiguous to you. We will continue to use our self-hosted runners to make these changes.

You’ll need to add the topic of public on three to four public repositories in your organization. At the very least you need one, but to demonstrate a valuable output, having a couple would be useful. You can fork any repository on GitHub to your account if you do not have many.

You’ll need to create a fork of the SAP Innersource portal at https://github.com/SAP/project-portal-for-innersource into your organization account. Rename the repository My.GitHubOrg.

You’ll also need to create three GitHub Apps, which we have done previously. If you need a refresher, you can refer to the Setting up a GitHub App section in Chapter 11. Create the three apps listed...

Understanding the central configuration pattern

The central configuration pattern is a practical tool in the software development world, similar in some ways to the crawler pattern. But instead of making changes across multiple repositories, the central configuration pattern focuses on analyzing a single repository, pulling content, or storing computed data about that repository in the central repository.

This pattern is especially useful when creating a central data store is needed. It can be for gathering results or managing files from one central place. I’ve seen it used in three scenarios:

• One is when a central team wants to manage the configuration files of different repositories, ensuring they have the final approval over company master data.
• Another is when there’s a need to collect data centrally to create visual displays using tools such as Grafana or even custom web applications.
• Internally accessible web portals enabling developers by exposing...

Creating a repository indexer

Currently, to utilize GitHub Pages on our current free plan, a repository must remain publicly visible unless you have an enterprise account, which we don’t. However, I’d advise against making it public for your specific needs unless you also intend to use Pages. Currently, GitHub doesn’t offer a feature on the free plan for private pages that’s easily accessible and simple to maintain compared to conventional web hosting. Yet, the solution to achieve our objective isn’t overly complicated. Let’s explore how to create a crawler that indexes repositories and evaluates their content:

1. Our first step is to design a workflow for the indexer to do this. Design a workflow that does the following:
   • Runs on a set schedule
   • Can be manually triggered
2. The workflow will collect data from all other repositories using the crawler pattern.
3. Utilize the GitHub API to fetch repository information.
4. Checkout the target...

Hosting the results using GitHub Pages

In this section, we’ll build a workflow to host a GitHub page to demonstrate our collected data. At its core, GitHub Pages is a hosting service provided by GitHub that allows users to publish web content directly from their repositories. It’s designed to host static websites, meaning it can serve HTML, CSS, and JavaScript files, but it doesn’t support server-side code such as PHP or Python. This makes it an ideal choice for personal, project, or documentation websites.

GitHub Pages offers two primary methods for deploying your website:

• Classic deployment: This traditional approach involves pushing your static files to a specific branch in your repository. GitHub Pages automatically detects these files and publishes them as a website. It’s straightforward and requires minimal setup, making it a favorite among users who prefer simplicity.
• Actions deployment: The newer method leverages GitHub Actions, which...

Summary

This chapter explored the configuration centralization pattern, a sophisticated strategy for managing and organizing configuration data across numerous repositories. It ensures uniformity and accessibility. Initially, the chapter shed light on the core principles of this pattern, highlighting its crucial role in fostering an efficient configuration management system.

We then transitioned from theory to practice, constructing a repository indexer workflow. Utilizing an existing action, we performed the initial indexing, meticulously gathering and organizing information from a variety of repositories. This crucial step showcased the pattern’s ability to centralize data effectively. We also noted the potential to expand this process, using a matrix to aggregate data from each repository if needed.

As we approached the chapter’s conclusion, our attention shifted to the integration and deployment facets of the pattern. The repository indexer’s compiled...