Enterprise Angular Apps


In der Welt der Softwareentwicklung wird oft über technische Schulden gesprochen, häufig in einem negativen Kontext. Doch wie bei vielen Dingen im Leben gilt: Technische Schulden sind nicht per se schlecht. Tatsächlich können sie strategisch genutzt werden, um bestimmte Ziele zu erreichen. In diesem Blog möchte ich die Balance zwischen den Vorteilen und den Risiken technischer Schulden beleuchten und zeigen, wie ein bewusster Umgang mit ihnen die Produktentwicklung unterstützen kann.

#### Was sind Technische Schulden?

Der Begriff "Technical Debt" (Technische Schulden) wurde 1992 vom Softwareentwickler Ward Cunningham geprägt. Er verwendete diese Metapher, um zu beschreiben, wie kurzfristige Entscheidungen bei der Softwareentwicklung, die aus Zeitdruck oder Kompromissen resultieren, langfristige Nachbesserungen erforderlich machen können.

Technische Schulden entstehen, wenn bei der Entwicklung von Software bewusste Kompromisse eingegangen werden, um kurzfristig bestimmte Ziele zu erreichen. Diese Entscheidungen führen oft zu **zusätzlichen Nachbesserungen**, die nötig sind, weil die Entwicklung entweder schneller oder nachlässiger durchgeführt wurde. Dabei kann es sich um suboptimale Lösungen handeln, die es ermöglichen, eine Deadline zu erreichen oder eine schnelle Markteinführung zu realisieren.

#### Die Unterscheidung von Technischer Schuld nach Martin Fowler

Der bekannte Softwarearchitekt **Martin Fowler** hat das Konzept der technischen Schulden weiter differenziert, indem er sie in vier Kategorien unterteilt: **leichtsinnig** und **umsichtig** sowie **absichtlich** und **versehentlich**. Diese Unterscheidung hilft dabei, besser zu verstehen, wie technische Schulden entstehen und welche Herangehensweise dahinter steckt. Fowler teilt die technische Schuld in vier Quadranten auf, die je nach Bewusstsein und Absicht variieren.

**1. Leichtsinnig und versehentlich**

Diese Art von technischer Schuld entsteht, wenn Entscheidungen getroffen werden, ohne das notwendige Wissen oder Verständnis zu haben. Ein Beispiel hierfür wäre: "Was ist Layering?" – ein Zeichen dafür, dass die Entwickler grundlegende Prinzipien oder Best Practices nicht kennen. Hier resultieren die Schulden aus Unwissenheit und unüberlegtem Handeln.

**2. Leichtsinnig und absichtlich**

In diesem Fall weiß das Team, dass es eine schlechte Entscheidung trifft, wählt diesen Weg aber bewusst aus, oft aufgrund von Zeitdruck oder mangelnden Ressourcen. Ein klassisches Beispiel ist: "Wir haben keine Zeit für Design." Hier wird absichtlich auf Qualitätsstandards verzichtet, um schnell zu liefern, obwohl den Entwicklern die Konsequenzen klar sind.

**3. Umsichtig und absichtlich**

Diese Form der technischen Schuld entsteht, wenn man sich der Risiken und Konsequenzen bewusst ist, aber trotzdem eine informierte Entscheidung trifft, weil es unter den gegebenen Umständen notwendig ist. Ein typisches Szenario wäre: "Wir müssen jetzt das Produkt liefern und müssen mit den Problemen fürs Erste leben." Hier wird eine bewusste Risikoabwägung vorgenommen, um ein vorrangiges Ziel, wie eine rechtzeitige Markteinführung, zu erreichen.

**4. Umsichtig und versehentlich**

In dieser Kategorie entstehen technische Schulden aus Fehlern, die erst im Nachhinein als solche erkannt werden. Das Team hatte ursprünglich die besten Absichten und glaubte, eine gute Entscheidung getroffen zu haben, stellt aber später fest, dass es besser hätte gehen können. Ein Beispiel hierfür wäre: "Jetzt wissen wir, wie wir es hätten machen sollen." In diesem Fall wird aus den Fehlern gelernt, und künftige Projekte können davon profitieren.

![](/images/blog/technical-debt/technical-debt-dra-of-martin-fowler.png 'Darstellung der technischen Schulden nach Martin Fowler')

Diese Unterscheidung von Martin Fowler zeigt, dass nicht alle technischen Schulden gleich sind. Der Kontext und die Intention hinter den Entscheidungen spielen eine große Rolle, wenn es darum geht, wie kritisch diese Schulden bewertet werden sollten und wie man sie zukünftig vermeiden kann.

#### Technische Schulden sind nützlich, wenn...

- **Wichtige Deadlines erreicht werden müssen:** Es kann sinnvoll sein, bestimmte Qualitätsstandards zu senken, um ein Projekt termingerecht abzuschließen.

- **Die schnelle Markteinführung entscheidend ist:** In stark umkämpften Märkten zählt oft die Zeit. Ein Produkt kann schneller auf den Markt gebracht werden, auch wenn der Code nicht perfekt ist.

- **Ein MVP (Minimum Viable Product) gebaut wird:** Beim Start eines neuen Projekts ist es oft wichtiger, schnell Feedback vom Markt zu erhalten, als perfekten Code zu schreiben.

Doch auch wenn technische Schulden in diesen Fällen nützlich sein können, sollten sie so schnell wie möglich wieder abgebaut werden. Das bedeutet, dass nach der Erreichung kurzfristiger Ziele Zeit für Refactoring eingeplant werden sollte, um die entstandenen Schulden zu beseitigen.

#### Warum Technische Schulden nicht ignoriert werden sollten

Technische Schulden werden häufig als Synonym für schlechten Code verwendet. Es gibt jedoch einen wesentlichen Unterschied: Technische Schulden sind das bewusste Akzeptieren von Kompromissen in der Qualität zugunsten von kurzfristigen Zielen, während schlechter Code oft aus Nachlässigkeit oder fehlendem Know-how entsteht.

Technische Schulden können auf unterschiedliche Weise entstehen. Es ist wichtig, nicht nur die unmittelbaren Ursachen während der Entwicklungsphase zu betrachten, sondern auch die langfristigen Effekte, die durch das Nicht-Weiterentwickeln der Software auftreten können.

#### Technische Schulden während der Entwicklung

Technische Schulden entstehen oft direkt im Entwicklungsprozess, insbesondere wenn Teams unter starkem Zeitdruck stehen oder Anforderungen unklar formuliert sind. In solchen Situationen werden häufig Kompromisse bei der Codequalität eingegangen. Einige der häufigsten Ursachen sind:

- **Zeitdruck:** Wenn ein Projekt schnell fertiggestellt werden muss, wird häufig der saubere, durchdachte Code zugunsten von schneller umsetzbaren, aber weniger wartungsfreundlichen Lösungen vernachlässigt. Dies kann kurzfristig zu einem fertigen Produkt führen, erfordert aber in der Zukunft aufwendige Nachbesserungen.

- **Unklare Anforderungen:** Wenn die Anforderungen an ein Softwareprojekt nicht präzise definiert sind, besteht die Gefahr, dass Entwickler Lösungen umsetzen, die später überarbeitet werden müssen. Änderungen in den Anforderungen führen oft zu schnellen Anpassungen, die nicht optimal integriert sind und somit technische Schulden erzeugen.

- **Unzureichende Tests:** Wenn Tests nicht ausreichend oder gar nicht durchgeführt werden, steigt das Risiko von Bugs und Fehlfunktionen, die später behoben werden müssen. Dieser Mangel an Qualitätssicherung führt zu einem langfristigen Wartungsaufwand.

- **Schlechte Dokumentation:** Eine unvollständige oder unklare Dokumentation erschwert es den Entwicklern, den Code zu verstehen und zu pflegen. Dies führt zu Mehraufwand, wenn der Code später angepasst oder erweitert werden soll.

- **Unsauberer Code:** Suboptimale Code-Strukturen oder übermäßig komplexer Code, der schlecht lesbar oder wartbar ist, sind ein weiteres klassisches Beispiel für technische Schulden. Solche Codefragmente müssen in der Regel bei späteren Updates refactort oder gar neu geschrieben werden, um die Wartbarkeit und Erweiterbarkeit der Software zu gewährleisten.

#### Technische Schulden durch Nicht-Entwicklung

Technische Schulden entstehen nicht nur aktiv während der Entwicklung, sondern können sich auch durch das **Nicht-Weiterentwickeln** der Software anhäufen. Software, die nicht regelmäßig gepflegt wird, gerät oft technisch ins Hintertreffen. Diese „unsichtbaren“ technischen Schulden können genauso schwerwiegende Auswirkungen haben wie die Schulden, die durch aktive Entwicklung entstehen:

- **Technologischer Wandel:** Technologien und Best Practices in der Softwareentwicklung ändern sich stetig. Neue Programmiersprachen, Tools oder Frameworks bieten oft effizientere oder sicherere Möglichkeiten, Software zu entwickeln. Wird eine bestehende Software nicht regelmäßig modernisiert oder angepasst, entsteht eine Diskrepanz zwischen dem aktuellen Stand der Technik und der eingesetzten Technologie, was die zukünftige Wartung und Erweiterung erheblich erschweren kann.

- **Veraltete Bibliotheken und Frameworks:** Bibliotheken und Frameworks werden regelmäßig aktualisiert, um neue Funktionen zu integrieren, Sicherheitslücken zu schließen oder die Performance zu verbessern. Wenn eine Software auf veralteten Abhängigkeiten aufbaut und diese nicht regelmäßig aktualisiert werden, kann das zu Inkompatibilitäten, Sicherheitsrisiken oder eingeschränkter Funktionalität führen. Das Nachziehen dieser Updates kann dann aufwendiger und risikoreicher werden, je länger es hinausgezögert wird.

- **Neue Architekturkonzepte:** In der Softwarearchitektur entstehen immer wieder neue Paradigmen und Designmuster, die es erlauben, Systeme skalierbarer, robuster oder leichter wartbar zu gestalten. Unternehmen, die ihre Architektur nicht an diese neuen Konzepte anpassen, könnten langfristig darunter leiden, dass ihre Software schwerer erweiterbar oder weniger effizient ist. Auch das Ignorieren dieser Fortschritte kann technische Schulden akkumulieren, die später aufwändig beseitigt werden müssen.

Diese Art von technischen Schulden, die sich durch Nicht-Weiterentwicklung ansammeln, sind oft schwer zu erkennen, da sie nicht sofort sichtbar sind. Dennoch sind sie genauso kritisch, da sie die Flexibilität und Zukunftsfähigkeit der Software beeinträchtigen.

#### Wie technische Schulden abgebaut werden können

Technische Schulden müssen ernst genommen und strategisch angegangen werden, um langfristig eine stabile Codebasis zu gewährleisten. Hier sind einige Wege, um technische Schulden zu verringern:

- **Bewusster Umgang mit technischen Schulden** Technische Schulden sollten dokumentiert und überwacht werden. Es ist wichtig, stets im Auge zu behalten, wo und warum sie entstehen.

- **Feedback von Entwicklern einholen** Die Entwickler wissen am besten, wo sich technische Schulden verbergen. Regelmäßige Team-Meetings können helfen, diese Schulden zu identifizieren.

- **Automatisierte Tests und Tools verwenden** Tools wie [SonarQube](https://www.sonarsource.com/products/sonarqube/) können dabei helfen, technische Schulden zu visualisieren und die Codequalität zu verbessern.

- **Refactoring-Zeit einplanen** Es sollte in jedem Sprint Zeit für Aufräumarbeiten (Refactoring) eingeplant werden, um technische Schulden kontinuierlich abzubauen.

#### Das Projektmanagement von der Wichtigkeit überzeugen

Eine der größten Herausforderungen beim Umgang mit technischen Schulden ist, das Projektmanagement davon zu überzeugen, dass ihre Beseitigung wichtig ist. Hier ist es entscheidend, die **Ziele des Unternehmens** mit der Notwendigkeit des Abbaus technischer Schulden in Einklang zu bringen.

Drei Argumente können helfen, das Projektmanagement zu überzeugen:

- **Zahlen sprechen lassen:** Konkrete Metriken, die die negativen Auswirkungen technischer Schulden auf die Produktivität zeigen, sind oft das beste Argument.

- **Langfristige Probleme aufzeigen:** Technische Schulden, die nicht behoben werden, verschlimmern sich über die Zeit und können zukünftige Projekte erheblich verlangsamen.

- **Risikomanagement:** Der Aufbau technischer Schulden ist vergleichbar mit einem wachsenden Risiko. Je länger sie ignoriert werden, desto schwieriger und teurer wird ihre Beseitigung.

#### Fazit

Technische Schulden sind ein unvermeidlicher Teil der Softwareentwicklung. Sie können, wenn sie bewusst eingesetzt werden, sogar ein wertvolles Werkzeug sein, um schnelle Ergebnisse zu erzielen. Wichtig ist jedoch, dass sie stets im Auge behalten und so schnell wie möglich abgebaut werden, um langfristige Stabilität zu gewährleisten. Ein transparenter und geplanter Umgang mit technischen Schulden hilft dabei, die Balance zwischen Entwicklungsgeschwindigkeit und Codequalität zu wahren.

#### Links

- [Martin Fowler Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html)
- [Martin Fowler Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
- [LeadDev Technical Debt](https://leaddev.com/tech/tech-debt-engineering-leaders-how-shortcut-today-impacts-tomorrow?utm_source=tldrwebdev)
- [Engineering Leadership Technical Debt](https://newsletter.eng-leadership.com/p/engineers-guide-to-convincing-your?utm_source=tldrwebdev)
- [DevBoost Der richtige Umgang mit technischen Schulden](https://devboost.com/blog/tipps-fuer-den-richtigen-umgang-mit-technischen-schulden?utm_source=9-3)


Technische Schulden: Fluch oder Segen für die Softwareentwicklung?


Das Windows-Terminal bietet eine deutlich verbesserte Kommandozeile in Windows 10 und 11.
Es ist vollgepackt mit nützlichen Funktionen wie Tabs, Bereichen, Themes und Tastenkombinationen
sowie vollständiger Unterstützung für verschiedene Umgebungen wie PowerShell, Eingabeaufforderung
und Windows Subsystem für Linux.

In diesem Artikel beschreibe ich einige Möglichkeiten, wie das Terminal an deine Bedürfnisse angepasst
werden kann, und gebe ein paar Tipps und Tricks preis, damit deine Arbeit in der Kommandozeile reibungslos
und produktiv verläuft.

### Windows Terminal Features

Auf den ersten Blick sieht das Windows Terminal ziemlich einfach aus, aber es gibt einige Funktionen,
die es von der Standard Windows-Befehlszeile unterscheidet:

- Vollbildmodus
- Tab-Basierte Benutzeroberfläche
- Shortcut Tastenkombinationen
- Zoom mit der Maus (STRG + Mausrad)
- Unicode und UTF-8 Zeichenunterstützung erlaubt die Verwendung von Emojis 👩‍💻🔥👍
- Benutzerdefinierte Themes und Stile können erstellt werden
- Unterstützung für Windows Subsystem für Linux (WSL), SSH, PowerShell, Command Prompt, und Azure Cloud Shell

### Windows Terminal installieren

Leider liefert Microsoft das Windows Terminal nicht standardmäßig in Windows aus. Deshalb muss das Terminal entweder
über den [Microsoft App Store](https://aka.ms/terminal), [Github](https://github.com/microsoft/terminal/releases)
oder einen Package Manager (z.B.: winget, chocolatey, scoop) installiert werden.

### Windows Terminal konfigurieren

Nach der Installation kann das Terminal über mehrere Wege geöffnet werden:

- Über das Startmenü “Terminal” suchen
- WIN+R drücken und wt eingeben
- In Windows Explorer auf einem Ordner, oder in einem Leerbereich rechtsklicken und “In Terminal öffnen” auswählen
- In Windows Explorer in der Adressleiste wt eingeben
- Windows 11: WIN+X drücken und Terminal öffnen

Um die Einstellungen anzupassen wähle "Einstellungen" im Dropdown Menü oder drücke CTRL+,. Hier hast du die Möglichkeit
dein Terminal bis ins kleinste Detail zu konfigurieren. Es können verschiedene Profile für jede Shell angelegt werden
in denen Icons, Schriftart und Farben definiert werden. Das beste am Windows Terminal ist aber das die Konfiguration
im JSON Format gespeichert wird. Somit können Konfigurationen untereinander geteilt werden oder auf einen anderen PC übertragen werden.

Um das ganze noch visuell aufzupeppen empfehle ich die Installation von [Oh My Posh](https://ohmyposh.dev/).
Mit Oh My Posh liefert bessere Theme Funktionen mit denen beispielsweise der aktuellen Git status direkt im Terminal angezeigt werden kann.

Microsoft liefert hier ein Tutorial mit der die Installation ganz leicht klappt:

[Windows Terminal Custom Prompt Setup](https://learn.microsoft.com/en-us/windows/terminal/tutorials/custom-prompt-setup)

Ebenfalls zu empfehlen ist der Blog Post von Scott Hanselman:

[My Ultimate PowerShell prompt with Oh My Posh and the Windows Terminal](https://www.hanselman.com/blog/my-ultimate-powershell-prompt-with-oh-my-posh-and-the-windows-terminal)

![Windows Terminal konfiguriert mit Oh My Posh](/images/blog/windows-terminal/terminal-1.png)

### Bonus: Git Shortcuts

Um die tägliche Arbeit mit Git zu erleichtern habe ich mir noch einige PowerShell Alias erstellt.
Ein Alias unter PowerShell ist ein Synonym für einen PowerShell Befehl.
Um PowerShell Alias zu erstellen, öffne dein PowerShell Profil mit diesem Befehl:

```powershell[class="line-numbers"]
notepad $PROFILE
```

Um nicht immer die Befehle in der Konsole eintippen zu müssen und Typos entgegenzuwirken,
habe ich für jeden dieser Git Befehle PowerShell Alias erstellt:

```powershell[class="line-numbers"]
# Git Alias
# git status -> gco
function Get-GitStatus { & git status $args }
New-Alias -Name gst -Value Get-GitStatus

# git commit -> gco
function Set-GitCommit { & git commit -am $args }
New-Alias -Name gco -Value Set-GitCommit

# git checkout -> go
function Set-GitCheckout { & git checkout $args }
New-Alias -Name go -Value Set-GitCheckout

# git add -> ga
function Set-GitAdd { & git add $args }
New-Alias -Name ga -Value Set-GitAdd

# git pull -> pull
function Set-GitPull { & git pull }
New-Alias -Name pull -Value Set-GitPull

# git push -> push
function Set-GitPush { & git push }
New-Alias -Name push -Value Set-GitPush

# git add .
# git commit $args
# git push
# -> push-all commit message
function Set-GitSync { & ga . && gco $args && push}
New-Alias -Name push-all -Value Set-GitSync
```

Mit diesem Setup kann nun ganz leicht auf einen neuen Branch mit dem Befehl `go "branch-name"`
gewechselt werden. Zusätzlich gibt es einen `push-all` Alias mit dem es möglich ist alle aktuellen Änderungen
in das zentrale Repository zu pushen:

```powershell[class="line-numbers"]
push-all <commit-message>
```

### Fazit

Mit dem Windows-Terminal steht den Benutzern eine leistungsstarke und anpassbare Umgebung zur Verfügung,
um ihre Kommandozeilenarbeit zu verbessern. Egal, ob du ein Entwickler, Systemadministrator oder einfach
ein begeisterter Benutzer bist, das Terminal bietet die Werkzeuge, um effizienter zu arbeiten und Aufgaben
schneller zu erledigen. Wenn du noch nicht das volle Potenzial des Windows-Terminals ausgeschöpft hast,
solltest du definitiv die vorgestellten Tipps und Tricks ausprobieren, um das Beste herauszuholen.


Windows Terminal für Entwickler


### Wer bin ich überhaupt?

Wie erwähnt ist mein Name Tobias Hämmerle und ich studiere derzeit in Innsbruck am MCI. Dort habe ich gerade mein 2. Semester im Studienzweig Management, Communication & IT beendet. Ursprünglich komme und wohne ich im schönen Vorarlberg oder um genauer zu sein Lustenau.

### Wieso denn Fortix?

Es wurde mir schnell klar, dass Fortix für mich die richtige Option ist. Die Gründe dafür sind:

- der Aufgabenbereich der Firma: Schon in der HTL und nun auch teilweise im Studium habe ich mit Softwareentwicklung, speziell mit Webseiten, zu tun. Seither habe ich bemerkt, dass ein gewisses Interesse dafür vorhanden ist.
- Weiters ist das Büro in Dornbirn als (autoloser) Student von Lustenau aus mit Öffis sehr gut erreichbar.
- Der wahrscheinlich ausschlaggebendste Punkt war Martin Hämmerle, mein Cousin und zugleich Geschäftsführer von Fortix. Es führte fast kein Weg daran vorbei ihm zumindest in den Ferien etwas unter die Arme zu greifen.

### Was hatte ich zu tun?

Mein Aufgabenbereich bzw. mein Mitspracherecht, war tatsächlich größer als gedacht. Grundlegend war die Aufgabe den Webauftritt von Fortix neu zu gestalten. Das Design war zu 95% schon festgelegt und ich sollte das ganze nur noch in der Sprache des Webs umsetzen. Betonung liegt hier jedoch auf 95 und nicht 100%, denn dadurch war noch nicht alles in Stein gemeißelt.

Das wiederum bedeutete, dass ich meine Meinung und Designvorschläge ebenfalls miteinfließen lassen konnte. Somit hatte ich nicht nur wie ursprünglich geplant Codezeilen zu schreiben, sondern ich konnte auch meiner kreativen Seite freien Lauf lassen.

### Die Highlights

Highlights gibt’s einige die ich hier gerne kurz anführen möchte. So ist grundlegende die gemütliche Atmosphäre definitiv erwähnenswert und hat mir persönlich geholfen ohne Stress und dadurch auch produktiver und konzentrierter zu arbeiten.

Weiters haben alle Mitarbeiter einen guten Humor, was zum einen oder anderen Lacher führte und gute Erinnerungen hinterlässt. Für Aufregen und Ablenkung führte bei mir vor allem Cooper. Nein kein direkter Mitarbeiter, sondern „nur“ der Hund von Pius. So wurde ich beim Arbeiten das ein oder andere Mal von einer liebevollen Hundenase angestupst oder so lange von zwei braunen Knopfaugen beobachtet, bis ich meine Aufmerksamkeit auf sie richtete. Dann gab es für die nächsten paar Minuten jedoch kein Entkommen mehr. Cooper lässt sich nur durch eine große und lange Streicheleinheit oder durch Sessions mit dem Hundespielzeug zufriedenstellen.

Das Beste kommt zum Schluss und im Falle Fortix sind das definitiv die legendären Tischfußballspiele. Diese finden vor allem zur Mittagszeit oder als Auflockerung am Nachmittag statt. Das Ganze kann bei gutem Stellungsspiel so weit führen, dass gegen Ende nicht nur die Nerven blank liegen, sondern auch ein paar Schweißperlen zu sehen sind. Meine Entwicklung vom leicht Fortgeschrittenen Anfänger im Tischfußball zum Amateur macht sich inzwischen definitiv auf dem Spielfeld bemerkbar und diese Fähigkeit werde ich aus meinem Praktikum bestimmt mitnehmen!

### Das Fazit

Abschließend kann ich sagen, dass ich definitiv noch nie so viel Spaß beim, aber vor allem an der Arbeit selbst hatte. Das Ganze hat mir sogar so gut gefallen, dass dies sicherlich nicht meine letzten Zeilen Code bei FORTIX waren. Also jedem der überlegt bei Fortix ein Praktikum oder ähnliches zu machen, dem kann ich das Ganze nur wärmsten empfehlen.


Mein bisher bester Ferialjob


Die Twelve-Factor App Methode lässt sich auf Software anwenden, die in jeder beliebigen Programmiersprache (C#, Java, TypeScript, PHP, Python, …) entwickelt wird. Die Methode unterstützt zudem eine beliebige Kombination von Diensten (Datenbank, Message Queue, Cache, …). Die Konzepte können ebenfalls auf jedes beliebige Framework, wie das Web-Framework [Angular](https://angular.io/) oder das Mobile-Framework [Flutter](https://flutter.dev/), angewendet werden.

Wir haben die 12 Faktoren in einer Checkliste zusammengefasst:

### 1. Codebasis

Änderungen am Code sollen mit Hilfe von Versionsverwaltung getrackt werden. Mit Tools wie [Git](https://git-scm.com/) wird die Zusammenarbeit im Team erst ermöglicht. Dabei hat jeder Entwickler seine eigene Version des Codes und der Single-Point-of-Truth ist der Code in der Versionsverwaltung (repository). Für einen Release der Software wird der Code im Repository dann kompiliert, getestet und in der Cloud bereitgestellt.

### 2. Abhängigkeiten

Softwareabhängigkeiten (dependencies) sind externe Bibliotheken, die in vielen verschiedenen Apps verwendet werden können. Falls externe Bibliotheken verwendet werden, müssen diese explizit in einem „package manager“ spezifiziert werden. Es darf nie die Annahme getroffen werden das eine Abhängigkeit auf einem System schon vorhanden ist.

### 3. Konfiguration

Die Konfiguration einer App ist alles was sich wahrscheinlich zwischen verschiedenen Bereitstellungen (dev, test, staging, production) verändert. Konfigurationen dürfen nicht als Konstanten im Code gespeichert werden. Konfiguration und Code müssen immer strikt getrennt sein. Am besten wird die Konfiguration in Umgebungsvariablen (env) gespeichert. Dadurch wird ausgeschlossen, dass versehentlich [Zugangsdaten](https://dzone.com/articles/git-secrets-api-keys) in die Versionsverwaltung eingecheckt werden 😉

### 4. Unterstützende Dienste

Ein unterstützender Dienst ist jeglicher Dienst, den die App über das Netzwerk abruft. Dazu zählen zum Beispiel Datenspeicher (SQL/No-SQL Datenbanken, Objektspeicher), Message-Queue Systeme (RabbitMQ, Google Cloud Pub/Sub, …) oder SMTP-Dienste für das Senden von E-Mails (Sendgrid, [Mailchimp](https://mailchimp.com/de/), …). Jeder Dienst soll über eine URL, die in der Konfiguration gespeichert ist, erreichbar sein. Wenn z.B. eine Datenbank ausgetauscht wird, soll keine Änderung am Code erfolgen. Änderungen sollen lediglich über die Konfiguration gemacht werden.

### 5. Build, Release, Run

Jede Codeänderung muss diese drei Phasen durchlaufen. Es soll nicht möglich sein, Änderungen am Code während der Laufzeit zu machen. Um diese Phasen zu automatisieren soll ein CI/CD Tool (Travis CI, Jenkins, Bitrise, …) verwendet werden. Neue Build‘s werden durch die Entwickler der App ausgelöst, indem sie neuen Code in die Versionsverwaltung einchecken. Somit ist jeder Build eindeutig auf eine bestimmte Version des Codes zurückzuführen.

### 6. Prozesse

Die App sollte auf einer [„Shared Nothing“](https://de.wikipedia.org/wiki/Shared_Nothing_Architecture) Architektur aufgebaut werden. D.h. die App ist unabhängig von anderen Apps und kann einen eigenen Prozessor und Speicher verwenden. Ein Abstürzen der Applikation darf nie dazu führen das andere Services beeinträchtigt werden. Alle Daten, die von der App verwendet werden, müssen in einer Datenbank gespeichert werden. Dies garantiert die Skalierung unter hoher Last, da nahezu unbegrenzt neue Instanzen der App gestartet werden können. 🚀

### 7. Bindung an Ports

Eine Zwölf-Faktoren-App soll nicht an einen Anwendungscontainer wie Apache Tomcat gebunden sein. Die Anwendung soll einen eigenen Web Server o.ä. integrieren, damit diese über einen bestimmten Port erreichbar ist.

### 8. Nebenläufigkeit

Die Anwendung soll anhand von Prozesstypen wie Hintergrund-, Web- und Worker-Prozessen in unabhängige Prozesse aufgeteilt werden. Somit kann eine einfache Skalierung garantiert werden. Falls ein Teil der Anwendung eine hohe Auslastung widerfährt, können von diesem Prozesstyp mehrere Instanzen gestartet werden.

### 9. Einweggebrauch

Prozesse einer App sollen schnell gestartet und gestoppt werden können. Dies erleichtert schnelles skalieren während Belastungsspitzen und ein schnelles Bereitstellen von Code. Die Startzeit eines Prozesses sollte so gering wie möglich sein. Zusätzlich sollten Prozesse auch schnell gestoppt werden können, damit sie die verwendeten Ressourcen wieder für andere Services zur Verfügung stellen.

### 10. Dev-Prod-Vergleichbarkeit

Die Entwicklungsumgebung sollte so sehr wie möglich der Produktionsumgebung ähneln. Unterschiede zwischen den verwendeten Diensten können Inkompatibilitäten verursachen, die erst beim Bereitstellen in der Produktionsumgebung erkennbar werden. Eine Zwölf-Faktoren-App ist auf [Continuous Deployment](https://www.dev-insider.de/was-ist-continuous-deployment-a-652804/) ausgelegt, indem sie die Unterschiede zwischen Entwicklung und Umgebung klein hält.

### 11. Logs

Logs sind ein Datenstrom von Ereignissen, die das Verhalten einer laufenden App sichtbar machen. Eine Zwölf-Faktoren-App soll sich nicht selbst um Logs kümmern und diese z.B. in eine Datei schreiben. Es sollte ein separater Service verwendet werden, der diese Logs verwaltet und übersichtlich darstellt.

### 12. Admin-Prozesse

Verwaltungsprozesse wie das Erstellen von Berichten oder die Migration von Datenbankschemas müssen von der Anwendung selbst entkoppelt sein. Die Ausführung eines Admin-Prozess darf die eigentliche Anwendung in keiner Weise beeinflussen.

Das Zwölf-Faktoren-Modell deckt also viele Aspekte der Entwicklung einer Anwendung ab. Das Modell ist gut dazu geeignet, zukunftsorientierte Anwendungen für die Cloud zu entwickeln. 👍

Je nach Anwendungsfall müssen die Methoden angepasst werden, für Internet-of-Things Anwendungen gelten natürlich andere Regeln wie für Web-Anwendungen. Dennoch stellt diese Methode eine gute Basis dar, um einen Überblick an die Anforderungen moderner App-Entwicklung zu bekommen.

**[FORTIX](https://fortix.io)** hat die Methode für Zwölf-Faktoren-Anwendungen verinnerlicht und entwickelt für Sie moderne Software die nahtlos skaliert werden kann. 💪💻

Dabei halten wir uns an eine Vielzahl von Best Practices, um die Wartbarkeit und Erweiterbarkeit des Codes zu verbessern. Wir entwickeln Cloud native und Internet-of-Things (IoT) Anwendungen die auf jedem beliebigen Cloud Provider (AWS, Azure, Google Cloud, Software AG, …) ausgeführt werden können.

Wenn Sie mehr über den Entwicklungsprozess bei FORTIX erfahren wollen können Sie uns gerne [kontaktieren](https://fortix.io/die-12-faktoren-app/#). Wir freuen uns! 🎉

### Links

- [Twelve-Factor App](https://12factor.net/)
- [Twelve-factor app development on Google Cloud](https://cloud.google.com/solutions/twelve-factor-app-development-on-gcp)
- [Applying the Twelve-Factor App Methodology to Serverless Applications](https://aws.amazon.com/de/blogs/compute/applying-the-twelve-factor-app-methodology-to-serverless-applications/)
- [Twelve-Factor WordPress App](https://roots.io/twelve-factor-wordpress/)


The Twelve-Factor App


### Ein Unternehmen, welches über seine alte Identität hinausgewachsen und nun bereit für neue Höhen ist. 

Im Juli 2020 durfte ich als InterMedia-Absolvent der FH Vorarlberg dem Team von FORTIX als kreativer Kopf beitreten. Die Aufgabe lautete: Bring Farbe in unser Unternehmen und stärke unsere Marke! Eine spannende Aufgabe und nach dem langen Studium eine willkommene Herausforderung.

Zuerst benötigte ich dabei etwas Hintergrundwissen: Der bisherige Auftritt von FORTIX wurde bis dato ausschließlich in Eigenregie entwickelt. Die Basis des Unternehmens wurde in den Räumen des Coworking-Campus V gelegt. Schnell wurde den jungen Gründern klar, dass dieses Forum zwar Startups einen idealen Raum zur Entfaltung bietet, langfristig betrachtet aber eine eigene Lokalität einen Mehrwert zusichert. Eine neue Bürofläche sollte dies beheben und gleichzeitig die Identität nach innen und außen stärken.

![FORTIX](/images/fortix-logo.jpg)

Das neu renovierte, helle Büro in der Marktstraße in Dornbirn erstrahlt durch eine elegante Einrichtung in modernem Glanz und schafft somit eine ausgezeichnete Basis für erfolgreiche Projekte. Der Umzug in die neuen Geschäftsräume im Herzen von Vorarlbergs größter Stadt, verlieh uns nicht nur eine angenehmere Arbeitsatmosphäre, sondern brachte auch ein Auffrischen der Markenidentität mit sich.

Es gab kleine visuelle Änderungen beim alten Schriftzug. Dieser wurde durch einen neuen, passend zum fortschrittlichen Unternehmen, ersetzt. Kritisch wurden auch die Aufgabenfelder begutachtet. Das Ergebnis war eine leicht veränderte Marktpositionierung, in dem deutlich definiert wurde, welche Themen zukünftig die Hauptrolle des Unternehmens einnehmen werden. Das Credo: Eindeutiger Fokus auf tiefere Spezialisierungen in den Bereichen, in denen wir extrem zuverlässig sind.

Der Aufbau der Website wurde ebenso analysiert und diskutiert. Wir kamen zum Entschluss, dass eine neue, sauber strukturierte Seite benötigt wird.  Die neue Website entspricht nun der aufgefrischten Marktpositionierung, beinhaltet das neue Branding und unterstreicht die hohen Ambitionen unseres jungen Teams.

Unsere Außendarstellung reflektiert ein widerspruchsfreies und einheitliches Erscheinungsbild. Sowohl der digitale als auch der analoge Auftritt wurde überarbeitet. Das neue Konzept ist präzise und widerspiegelt die Werte unseres Teams. FORTIX wird in Zukunft sicherlich nicht nur durch die imposante Gaupe im Stadtzentrum Aufmerksamkeit erregen.

Wir haben hohe Ansprüche und liefern starke Ergebnisse.

Wir hinterfragen die Dinge und treffen mutige Entscheidungen.

Wir lieben Herausforderungen und suchen energisch nach einer Lösung.

Wir sind bereit!


Refreshing FORTIX


Kollegen und Bekannte erzählen mir, dass in ihren Unternehmen derzeit über die Maßnahme Home-Office nachgedacht wird. Aufgrund der Tätigkeiten wäre das in einigen Fällen auch sehr gut möglich. Man könnte die kommende Zeit — keiner weiß ja schlussendlich was uns genau erwartet — sicher überbrücken und das ohne, dass gesamte Unternehmen stillstehen. Allerdings scheitert es oft an der Infrastruktur. Das meist quer durch die Bank: Großunternehmen, kleine 5-Mann-Buden oder öffentliche Institute. Branchenunabhängig.

Meine persönliche Meinung ist deshalb folgendes: Wir sollten in Politik, Wirtschaft und Medien den Einsatz von plakativen Buzzwords wie beispielsweise High-Tech-Startups, Blockchain, Artificial Intelligence und Co. reduzieren. Versteht mich nicht falsch! Die Themen sind alle wichtig und zukunftsträchtig (vorausgesetzt man weiß wovon man spricht 😉). Allerdings sollte es zunächst unser Ziel sein eine flächendeckende, solide Basis zu erreichen.

![](/images/pexels-thisisengineering.jpg)

Über Tätigkeiten wie zeit- und ortsunabhängiger Zugriff auf arbeitsnotwendige Dokumente sollten wir im Jahr 2020 eigentlich nicht mehr diskutieren. Ein Buchhalter der täglich 8 Stunden am PC arbeitet, sollte ohne großen Aufwand, auch von zu Hause arbeiten können. Themen wie Berechtigung und Access stellen aufgrund der Vielzahl von Lösungen keine unüberwindbare Challenge mehr dar.

Ich gehe sogar noch einen Schritt weiter und behaupte, trotz Berücksichtigung von Faktoren wie Produktivität und etwaigen Kontrollverlust, dass ein modernes Unternehmen seinen Mit-arbeitern die Möglichkeit geben sollte, von zu Hause zu arbeiten. Vorausgesetzt es gibt eine klare Regelung, wie beispielsweise in vereinbarten Maßen (z.B. Freitag = Homeoffice, insofern keine Termine anstehen) oder bei Bedarf (ungünstiger Arzttermin, Tochter von Schule abholen, etc.). Die Vorteile überwiegen meiner Meinung nach den Nachteilen. Aber am besten ist, wenn sich jeder selbst eine Meinung davon bildet: Success-Stories, Warnungen und Pro-/Kontra-Listen zu dem Thema gibt es im Internet bereits genug.

![](/images/mac-dashboard.jpg)

Long story short: In Bezug auf die Digitalisierung müssen wir uns klare Gedanken machen. Derzeitige Maßnahmen scheinen, wie die unglückliche Situation zeigt, nicht zu fruchten. Natürlich ist jedes Unternehmen auch selbst in der Pflicht, sich zu informieren und weiterzuentwickeln. Allerdings kann ich verstehen, dass die ganze Debatte bezüglich digitaler Transformation mit der Zeit unübersichtlich und komplex erscheint. Wie heißt es so schön: _„Man kann vor lauter Bäumen den Wald nicht sehen“_. Deshalb denke ich, dass weniger mehr ist. Etwas weniger „Bullshit-Bingo“ und dafür konkrete Lösungen, welche auch umsetzbar sind und uns als Wirtschaftsstandort weiterbringen.

Aber wie können wir euch gezielt unter die Arme greifen? Vor allem für kleine Unternehmen haben wir in letzter Zeit verschiedene Szenarien ausgearbeitet und auch umgesetzt. Unser gemeinsames Ziel ist es, mit möglichst geringen technischen Aufwendungen und folglich auch geringen Kosten, eine Lösung für die Arbeit von zu Hause zu ermöglichen. Wir haben uns den Aspekt bezüglich Remotezugriff auf die firmeninterne Infrastruktur und vor allem die Kommunikation der nun verteilten Mitarbeiter mit Chat-Tools zu optimieren genauer unter die Lupe genommen. Bei Fragen zu einzelnen Tools, Erfahrungsberichten oder auch konkreter Hilfe bei der Umsetzung bitte einfach melden. Wir helfen gerne.


Web Entwicklung

Enterprise Angular Apps

Share this post

Weitere Blogs

Eine Auswahl unserer letzten Blogs

Technische Schulden: Fluch oder Segen für die Softwareentwicklung?

Windows Terminal für Entwickler

Mein bisher bester Ferialjob

The Twelve-Factor App

Refreshing FORTIX

Anno 2020: Irgendwo zwischen Blockchain & Faxgerät