In agilen Umgebungen wie Startups sind starre Trennungen von Softwareentwicklung und IT Operations eher selten anzutreffen. Doch auch viele große Unternehmen wechseln immer öfter auf agile Prozesse und einem dazu passenden IT Umfeld. DevOps ermöglicht die Vernetzung der klassischen Silos. Durch die Einführung intelligenter und automatisierter Prozesse lässt sich die Auslieferung der Software und dessen Qualität erheblich steigern.
Die gängigen DevOps Prozesse und Tools decken die Bereiche Planung, Entwicklung, Build, Test, Release, Deployment, Operations und Monitoring ab. Welche Prozesse dabei automatisiert werden sollen und zu welchem Zeitpunkt hängt maßgeblich vom Reifegrad des Unternehmens und der verfügbaren Zeit ab. Dabei muss die DevOps Umgebung am Anfang nicht so perfekt optimiert sein wie bei Netflix deren Automatiserungsgrad einzigartig ist. Für die Einführung der Tools und Prozesse muss Zeit aufgewendet werden welche dann in der Entwicklung fehlt. Gerade bei Startups die noch ihr MVP (Minimum Viable Product) am Markt erproben wäre eine vollständige Automatisierung noch verfrüht. Dennoch hilft eine frühzeitige Einführung auch hier die Produktivität und Qualität zu erhöhen. Exemplarisch möchte ich die Umsetzung meines letzten Stacks für ein schnell wachsendes Startup Unternehmen beschreiben.
Ausgangslage und Anforderungen
Das MVP ist am Markt erprobt und das Team hat bereits einige Entwickler an Board. Die primären Anforderungen sind somit die Qualität der Software erhöhen, idealerweise durch Testautomatisierung und Code-Quality-Standards. Neue Features müssen jederzeit und von jedem Mitarbeiter getestet werden können bevor diese in die Produktionsumgebung kommen. Somit müssen mehrere Testumgebungen verfügbar sein. Im Hinblick auf weitere neue Entwickler sollen diese schnell produktiv sein. Außerdem müssen alle Umgebungen zur Nachstellung von Problemen gleichartig aufgesetzt und konfiguriert sein.
A fool with a tool is still a fool.
Ein weiteres wichtiges Kriterium ist eine einfache Wartbarkeit und Administration. Probleme und Anforderungen sollen nicht mit einem Zoo aus tausend Tools erschlagen werden. Dabei ist eine wichtige Frage welche Programme selber gehostet werden sollen und wo ein Zukauf bzw. ein SaaS Modell sinnvoll ist. Natürlich gilt es den Datenschutz bei letzterem zu wahren. Selber administrierte Tools müssen immer auf dem aktuellsten Softwarestand und mit sicheren Konfigurationen bestückt sein.
Tools
Ansible
Eines der zwei zentralen Tools ist hier Ansible geworden. In den sogenannten Playbooks und den Konfigurationsdateien lässt sich die gesamte Umgebung definieren. Ansible verfolgt dabei den Ansatz, dass der Endzustand beschrieben wird. Die Definition für den Applikationsserver sieht dann also beispielsweise wie folgt aus.
- [AppServer]
- Server1
- Server2
- [AppServer Installation]
- nginx: installiert
- PM2: gestartet
- DatendankVerbindung: DbServerCluster
Ich nutze Ansible sogar um die Server direkt bei dem Cloud Anbieter aufzusetzen. Somit gibt es zwei Ansible Projekte. Ein Projekt um die gesamte Serverumgebung inkl. Datenbankservern, VPNs, Firewall Regeln, SSH-Keys und Object Storages zu verwalten und ein zweites Projekt welches dann für jeden Server die Software und deren Konfiguration beschreibt. Durch die einfache Konfiguration können somit innerhalb weniger Minuten beliebig viele gleichartige Integrations-/Testumgebungen aufgebaut werden. Alle Umgebungen werden außerdem automatisch in die Monitoring- (Icinga/Nagios) und Loggingumgebung (Graylog 2) eingebunden. Ich habe mich bewusst gegen Datadog und ähnliche SaaS Dienste entschieden weil die Administration und Konfiguration von Tools wie Graylog, Icinga, Elasticsearch und vielen mehr mit Ansible ein Kinderspiel ist. Wichtig sind hier nur zuverlässige und sichere Konfigurationsdefinitionen und sauber abgetrennte Netzwerkbereiche und Firewall Regeln.
Jenkins
Die zweite Zentrale Software ist Jenkins. Dieser löst Deploybot ab um mehr Kontrolle über den gesamten Release Prozess zu haben.
Jenkins kümmert sich um mehrere Teile. Zum einen prüft er sämtliche Check-Ins die auf GitHub getätigt werden. Dies umfasst die Prüfung der Code Qualität (Linting, SonarQube, …).
Zum anderen führt Jenkins Unit Tests durch, startet die API Tests mit postman bzw. newman und führt die User Acceptance Tests von Selenium aus.
Abhängig von den gewählten Branches automatisiert Jenkins auch das Deployment. Sämtliche commits auf den develop branch führen zu einem Deployment auf die Integrationsumgebung.
Alle master commits müssen von mindestens zwei Entwicklern und Jenkins selber geprüft werden und führen dann zu einem Deployment auf die Produktionsumegbung.
Jeder Entwickler hat darüber hinaus jederzeit die Möglichkeit beliebige Branches auf Testumgebungen zu deployen. Dabei kann außerdem festgelegt werden welche Testdaten initial in den Datenbankservern zur Verfügung gestellt werden. Die Testumgebungen werden darüber hinaus in gesonderten virtuellen Netzwerken aufgebaut.
Produktion als lokale Entwicklunsumgebung
Ansible funktioniert auch mit Vagrant. Sämtliche Konfigurationen die für die Serverumgebungen definiert sind funktionieren somit auch lokal. Jeder Entwickler hat daher eine Umgebung deren Softwarestände und Konfiguration 1:1 mit der Produktion übereinstimmen. Lediglich die Datenbank ist in den Entwicklungsumgebung lokal anstelle von dedizierten Servern. Die lokalen Umgebungen können jederzeit auf Knopfdruck neu erstellt werden und erhalten direkt Testdaten. Neue Mitarbeiter lassen sich somit innerhalb von ca. 30 Minuten arbeitsfähig einbinden!
Zusammenfassung
Durch die Automatisierung des Aufbaus der lokalen Entwicklungsumgebung bis hin zur vollständigen Serverumgebung und der Automatisierung der Deployments findet jeder Entwickler jederzeit gleichartige Umgebungen vor. Fehler können lokal nachgestellt werden und notwenige Konfigurationsänderungen werden versioniert und auditiert zentral verwaltet. Jeder Entwickler kann jederzeit Änderungen von Code und Infrastruktur nachvollziehen und überprüfen.
Bildquelle: pixabay.com
