# Build- & Testinfrastruktur
#### Situation

- Der Hauptteil der Tests wird vor Release manuell durchgeführt – *oft nur auf einer Plattform*

- Es werden keine neuen VMs verwendet, sondern "bereits eingerichtete"

- Erst *nach* den Tests werden die endgültigen Installationspakete für die Kunden gebaut

- Code wird während des Release-Vorgangs weiterhin geändert, aber *nicht neu getestet*

- Dauer eines Releases: Mehrere Monate

---

# Build- & Testinfrastruktur
#### Änderungen

.column[
- Automatisches Erzeugen der *endgültigen* Installationspakete

- QS arbeitet *nur* mit diesen Paketen

- Anteil der automatisierten Tests drastisch erhöht

    - jMeter

    - Cucumber

    - Selbst geschriebene Tests
]

.column[
- Bei jedem Durchlauf werden neue Tests-VMs erzeugt

- Automatisierung mitels [Vagrant](https://www.vagrantup.com/) und [Terraform](https://www.terraform.io/)

- Alle unterstützten Plattformen werden getestet

- Sowohl Cloud als auch interne Systeme werden verwendet
]

---

# Build- & Testinfrastruktur
#### Ergebnis

- Automatischer Teil des Releasevorgangs innerhalb von Stunden vollständig durchlaufen

- Nutzung der Cloud macht automatisierten Testaufbau sehr einfach

- Sicherheit so hoch, dass bereits ins firmeneigene Produktivsystem deployed wird

- Viel Zeit für Entwicklung, aber auch viel Einsparung

---

# Build- & Testinfrastruktur
#### Anti-Pattern

- Testinfrastruktur muss nicht unbedingt selbst bereitgestellt werden

    - Gerade für kurzlebige Testdurchläufe kann die Cloud günstig sein

    - Cloud besonders für Tests geeignet, die die Ressourcen stark belasten

    - Automatisierung mittels Terraform u.ä. sehr einfach

    - Oft wird der Wartungsaufwand bei eigenen Lösungen unterschätzt

---