Mapping i26g's Domains to Its Repositories

This is the design that development is working towards. None of the sites described here are live yet.

From RST to i26g chose the name and the domains. This post describes how those domains are structured, and how each address maps to the repository it comes from.

The Domains

i26g.com is the main address. i26g.sh and i26g.co are registered defensively and will redirect to it, so there is one place to link to and one place people end up.

Everything else lives under i26g.com as a subdomain, one for each purpose:

Each destination has a clear job: understand the subject, use the platform, or take part in development.

Why Subdomains

Learning material is organised around choices and trade-offs; platform documentation is organised around components, versions, tasks, and the architecture and decisions behind them. Subdomains give each site a distinct identity and let its navigation, build, and hosting evolve independently.

Stable addresses come from preserving URLs and redirects when sites change, whichever layout is used. Subdomains make that easier to manage per site, but they are not what makes it possible.

The Repositories

The repositories follow a different logic from the domains: they are split by what needs to change and be released together.

The Main-Site Repository

The main site changes on a different rhythm from the product — when the offering or the messaging changes, not when the code does — so it is built from a repository of its own.

The Forge Repository

The forge is infrastructure for building i26g rather than part of what i26g delivers. Its configuration and deployment live in a repository of their own, separate from the product.

The Monorepo

The platform’s code, its documentation, and the learning material live in one repository, which builds two of the sites: the learning site from the learning material, and the documentation site from the platform documentation.

Keeping the documentation — including the architecture and decision records — in the same repository as the code means a change, its documentation, and the decision behind it can land in the same review, and the documentation for a release is built from the same commit as the release itself. The learning material evolves independently: sharing a repository lets related changes be reviewed together, without requiring the learning and documentation sites to share a release schedule.

Online and Locally

The learning and documentation sites are published online at their addresses, and can also be built locally. The generated sites are intended to be readable locally without remote assets or services, so a trader running the platform on their own infrastructure can read the documentation for exactly the version they run, without depending on i26g.com being reachable. Packaging the documentation with each platform release would make that possible without building it at all.

How It Fits Together

The addresses are organised around what visitors come to do; the repositories are organised around what needs to change and be released together. The forge hosts the repositories and coordinates the pipelines that build and test i26g; the monorepo produces the platform and the learning and documentation sites; and the main site, from its own repository, points people to each of them.