X-I-A Framework
Introduction
- Abstraction of Devops level by using configuration files
- A routine to less code or code less
- Describing business needs instead of technical details
Main component relationships
- Cosmos is the root component
- Realm represents a directory-like component holds Foundation as file-like objects
- Foundation represents a socle on which application should run on
graph TD
Cosmos -->|Contains| Realm_A
Realm_A -->|Holds| Realm_B
Realm_A -->|Manages| Foundation_A
Realm_B -->|Manages| Foundation_B
Foundation_A -->|Manages| Application_A1
Foundation_A -->|Manages| Application_A2
Foundation_B -->|Manages| Application_B1
Foundation_B -->|Manages| Application_B2
Remark: Foundation, realm or cosmos are nothing but a special application
Foundation - Application - Module Design
- All application is installed on a foundation
- Each application could have instance of modules
- Before module is usable in each application, they must be enabled in foundation
graph TD
F(Foundation) -->|Manages| A1(Application 1)
F -->|Manages| A2(Application 2)
F -->|Activates| M1(Module 1)
F -->|Activates| M2(Module 2)
F -->|Activates| M3(Module 3)
A1 -->|Has Instance of| M1
A1 -->|Has Instance of| M2
A2 -->|Has Instance of| M2
A2 -->|Has Instance of| M3
Cosmos - Realm - Foundation - Module Design
The same relationship is also defined between Cosmos/Realm and Application
- All foundation is installed on a realm or cosmos
- Each foundation could have instance of modules
- Before module is usable in each foundation, they must be enabled in their manager realm
graph TD
Cosmos -->|Contains| Realm_A(Realm A)
Realm_A -->|Holds| Realm_B(Realm B)
Realm_A -->|Manages| Foundation_A(Foundation A)
Realm_B -->|Manages| Foundation_B(Foundation B)
Foundation_A -->|Activates| M1(Module 1)
Foundation_A -->|Activates| M2(Module 2)
Foundation_B -->|Activates| M1
Git Integration
Generally, there types of git repository are used:
- Cosmos Git Repository
- Defining Cosmos - Realm - Foundation structure
- Activating modules to be used at Foundation level
- Initializing modules to be used
- Foundation Git Repository
- Defining Foundation - Application structure
- Activating modules to be used at Application level
- Initializing modules to be used
- Application Git Repository
- Initializing modules to be used
CLI/UI/Devops Design
Basic activities contains three action parts:
- Activate module
- Initialize module
- CI/CD
Basic ways to activate changes
makecommandsmake activate-module: activate modulemake init-module: initialize modulemake plan: terraform planmake apply: terraform apply
- CI/CD triggered by Git repository
Configuration files:
Common configuration files
modules.yaml:- Module class location
- Activation scope and parameters
- Deployment scope and parameters
- Dependencies
packages.yaml: Where the module of which package should be installedlandscape.yaml: relationships among cosmos, realm, foundation and application- Cosmos repository
- tree structure from cosmos to foundation
- Foundation repository
- related cosmos, realm information
- environments and related ci/cd trigger
- Application repository
- environments and related ci/cd stage configurations
- Cosmos repository
Module related configuration files
Module related configuration files should be placed with subdirectories. For example:
- /core: Git, Terraform related
- /platform: GCP, AWS, Azure organization level objects
Example
Use case 1: Google Cloud Platform with GitHub
GCP + GitHub with GCS as terraform state file storage is a common case
- Cosmos
- init modules: The module represents structure of cosmos
- gcp-module-organization: realm/foundation will be installed as folders
- gh-module-foundation: creation of a GitHub repository for each foundation
- gcs-terraform: possible to deploy cosmos landscape
- module-foundation-state-gcs: place to save foundation tf files
- activate modules: Enable foundation capacities
- module-application-state-gcs: possible to create tf file for application attached to foundation (bucket rights to sa)
- gcp-module-project: possible to create gcp project under a folder (folder owner rights to sa)
- gh-module-application: possible to create a GitHub repository under a team (token in the secret of foundation repository)
- init modules: The module represents structure of cosmos
- Foundation
- init module: The module represents structure of foundation
- gcp-module-project: application will be installed in projects
- gh-module-application: creation of a GitHub repository for each application
- module-application-state-gcs: place to save application tf files
- active module: *
- init module: The module represents structure of foundation
-
- Need to define three environments to form dev -> test -> production chain
- Directory of GCP and with the following module enabled
- gcp-module-project: GCP Project Handling
- Each environment relates to a dedicated GCP project
- gh-module-application: GitHub Repository Handling
- Each environment relates to a branch / event combination
- gcp-module-project: GCP Project Handling
- Application
- If application needs a BQ table the following modules should be enabled:
- module-state-gcs
- gcp-module-dataset
- gcp-module-table
- Both modules should be enabled at foundation level and configured at application level
- If application needs a BQ table the following modules should be enabled:
Use case 1 extensions
- Foundation
- Could be based on GCP / AWS / AZure at the same time
- Could use GitLab
- Could use other ways to handle state files
- Application
- Could activate other functionalities
GCP Foundation Introduction
Usage
Preparation
Starting from scratch
make bigbang
Foundation Operations
make create
Module Operations
make init-module module_class=module_class package=package
Application Operations
make create-app app_name=application_name
1 maintainer
Metadata
1 maintainer
Release files for xia-framework 0.0.66
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| xia-framework-0.0.66.tar.gz | 14.4 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| xia_framework-0.0.66-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 30.7 kB
Release files / xia-framework-0.0.66.tar.gz
| Download URL | xia-framework-0.0.66.tar.gz |
|---|---|
| Size | 14.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e6db5a6faf5e43af75d7e226715a3ae2452522105d5ba4c6d5ff868c6c61739d
|
|
BLAKE2b-256 checksum How to use checksums |
0e85229d9f2a633e0ed9de3a829c403ef8eedd1c89510f2c879f34edbffe4446
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.12.9
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 6, 2025.
Transparency logRelease files / xia_framework-0.0.66-py3-none-any.whl
| Download URL | xia_framework-0.0.66-py3-none-any.whl |
|---|---|
| Size | 16.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ec32411f4d039268f75418a3ff0129b71540fc5c8b010ddbf3377800d986581e
|
|
BLAKE2b-256 checksum How to use checksums |
7c23b2c747c5725f5ea2edbcba6edfe1e1c9917311b90ff97793e78b5382d335
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.12.9
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 6, 2025.
Transparency logSecurity for xia-framework 0.0.66
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for xia-framework-0.0.66.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 6, 2025.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
