# Überblick in fünf Minuten

Organisationen, Projekte und die generierten Repositories, der Weg vom Push bis zur Produktion und die zwei Arbeitswege bilden den Rahmen, in dem du als Entwickler mit der Plattform arbeitest.

> Source: https://www.application-platform.com/de/docs/developer-overview/

Die Plattform generiert aus einer Projekt-Konfiguration GitLab-Repositories mit Code-Gerüst, Pipelines und Deployment-Konfiguration und betreibt den Weg von `git push` bis zum laufenden Container; dein Anteil ist der Produktcode.

## Organisation, Projekt und Repositories

Eine **Organisation** bündelt Mitglieder, Abrechnung, Server, Store-Accounts und Anbindungen wie Sentry, Cloudflare oder SMTP; Administratoren verwalten sie, Developer arbeiten an ihren Projekten. Ein **Projekt** ist ein Produkt darin und bekommt eine GitLab-Gruppe auf `gitlab.application-platform.com` mit einem Repository pro Komponente, `gitlab-profile` für die README und zwei Repositories der Plattform:

- `local-configuration` enthält die Editor- und Agent-Konfiguration (`AGENTS.md`, `CLAUDE.md`, `.cursor`, `.claude`, `.codex`, `.vscode`) und liegt per Symlink im Projektordner.
- `gitops-configuration` beschreibt pro Umgebung (Dev und Prod), welche Version mit welcher Konfiguration läuft; die Pipelines schreiben die Versionen hinein, eigene Werte gehören in `custom.yaml`.

## Vom Push zur Produktion

```mermaid
flowchart LR
  push["Push oder Merge auf main"] --> pipeline["Pipeline: Test, Version, Build"]
  pipeline -->|"automatisch"| dev["Dev"]
  pipeline -->|"manueller Job"| prod["Prod"]
```

Ein Push oder Merge auf `main` startet die Pipeline, die die Version aus den Commit-Nachrichten (`feat:`, `fix:`) berechnet, das Artefakt baut und den Stand in `gitops-configuration` einträgt; Dev wird automatisch ausgerollt, Produktion per manuellem Job in GitLab, und Feature-Branches bauen ohne Versions-Commit. Den Ablauf mit Rollback beschreibt [Git-Workflow und Deployment]({{< relref "git-workflow" >}}).

## Wo was liegt

In der **Web-Oberfläche** unter `app.application-platform.com` verwaltest du Organisationen, **Projekte**, **Server**, **Anbindungen**, **Docker Apps**, **Domains** und **Workspaces**. In **GitLab** liegen Code, Pipelines, Job-Logs und Merge Requests, und **Sentry** sammelt Fehler, sobald unter **Anbindungen** ein Sentry-Konto verbunden ist. Wie Ansible, Image-Tags und Server zusammenspielen, steht unter [Architektur]({{< relref "architecture" >}}).

## Zwei Arbeitswege

Lokal richtet die [Setup-App]({{< relref "local-app" >}}) deinen Rechner ein und klont alle Repositories nach `~/Documents/application-platform/<organisations-slug>/<projekt-slug>/`; alternativ arbeitest du in einem [Remote-Workspace]({{< relref "workspaces-overview" >}}), einer Ubuntu-VM in der Cloud. In beiden Fällen öffnest du den Projektordner im Editor und startest jede Anwendung mit `ap run-local` im Repo-Root, siehe [Lokal entwickeln]({{< relref "local-development" >}}) und [CLI und Agent-Plugin]({{< relref "cli-and-agent-plugin" >}}). Danach legst du ein [neues Projekt an]({{< relref "create-project" >}}) oder [importierst ein bestehendes Repository]({{< relref "agent-project-import" >}}).