DevOps und Cloud Engineer mit Entwicklerbackground

#Ansible, #APM, #Bitbucket, #CentOS, #Confluence, #Docker, #DockerCompose, #ElasticAPM, #Elasticsearch, #ElasticStack, #Grafana, #Jaeger, #Java, #Jira, #Kibana, #Monitoring, #nginx, #Observability, #OpenTelemetry, #Prometheus, #SQL, #SRE

Als Site Reliability Engineer habe ich diverse APM (Application Performance Monitoring) Lösungen evaluiert und anschließend Elastic APM per Ansible eingebunden.

Das Ziel des Projekts bei der GLS (General Logistics Systems) war eine APM-Lösung zu finden, die es ermöglicht, das Verhalten von Java Applikationen und deren Datenbankabfragen sichtbar zu machen. Die SRE- und Entwickler-Teams sollten befähigt werden, jederzeit die aktuelle und historische Performance einsehen zu können.

Features wie End-to-End Tracing, Auswertungen von Laufzeiten, JVM-Metriken und die Anzeige von SQL Statements wurden als Kernanforderung genannt. Ebenfalls war gewünscht, dass die Lösung sich in bestehende Applikationen ohne großen Aufwand einbinden lässt.

Nach einer Evaluation von diversen Observability Tools, unter anderem Elastic APM und Kibana (aufbauend auf Elastic Stack bzw. ehemals ELK Stack), Grafana, Prometheus, Jaeger und OpenTelemetry – jeweils mit funktionierenden Prototypen – habe ich mit Zustimmung von GLS die Integration von Elastic APM durchgeführt.

Da Elastic APM on-premises gehostet werden sollte, habe ich die Orchestrierung über Docker Compose realisiert, welches ein Elasticsearch Cluster, das APM Backend und einen nginx Reverse Proxy einrichtet.

Das gesamte Setup von Elastic APM wurde über Ansible Playbooks ausgerollt, die ich während der Integration geschrieben habe. Es ist somit nach meinem Austritt möglich, dass die serverseitigen Komponenten jederzeit neu ausgerollt werden, als auch die Konfiguration der zu überwachenden Applikationen. Letztere bindet sich mittels Instrumentation als Java Agent ausschließlich per Modifikation der Startskripte ein.

Somit habe ich für GLS ermöglicht, dutzende Applikationen in das Monitoring einzubinden, ohne dass die zahlreichen Entwickler Teams dafür ihre Applikationen anpassen müssen.

Zum Projektende habe ich dem SRE Team eine ausführliche schriftliche Dokumentation übergeben.

#Ansible, #Automation, #AWS, #AWX, #Bitbucket, #CD, #CentOS, #CI, #CloudComputing, #Confluence, #Docker, #Gerrit, #Git, #InfrastructureAsCode, #Jenkins, #Jira, #Maven, #Nexus, #nginx, #OpenStack, #Python, #SonarQube, #Subversion, #Ubuntu, #WSL

Als Workbench Architect Infrastructure-as-Code und Workbench Architect Continuous Integration habe ich Prozesse mit Ansible automatisiert, Build Pipelines mit Jenkins, Docker und AWS betreut, und Beratung in diesen und angrenzenden Themen geleistet.

Im E2 Support (Engineering Environment Support) Team war unsere Aufgabe die projekt- und länderübergreifende Bereitstellung von CI/CD Systemen, die Konfiguration von VMs (CentOS, Ubuntu) und Workstations (WSL mit Ubuntu), sowie das Automatisieren von Aufgaben in diesen Bereichen.

Die CI/CD Systeme basierten auf Jenkins mit Pipelines, AWS, Docker, Ansible und AWX [die OSS Variante von Red Hat’s Ansible Tower], Git, Bitbucket, SonarQube und Sonatype Nexus.

Während meines Auftrags war ich beteiligt am Refactoring und der Vereinheitlichung zahlreicher Build Pipelines, so dass Projekte eine Library mit wiederverwertbaren Komponenten nutzen. Die Pipelines mit Jenkinsfiles waren Maven-basiert und verfügbar für Java und C Projekte; wobei C Projekte ebenfalls mit Maven und dem NAR-Plugin (“Native Archive Plugin") gebaut wurden.

Die Builds wurden dockerisiert soweit möglich, um die Pipelines cloud-ready und skalierbar zu machen. Diese laufen je nach Projekt in einem On-Premises Datacenter oder einer AWS Private Cloud.

Bestehende CI/CD Installationen wurden zu dieser einheitlichen Lösung migriert, und ich habe Teams und Mitarbeiter eingewiesen in der Nutzung und Migration.

Für Projekte außerhalb der Standardlösung habe ich mit Python, Gerrit und dem OpenStack SDK gearbeitet, um Builds zu automatisieren.

Im E2 Support Team war ich regelmäßig als 2nd Level Support Engineer aktiv, um Troubleshooting bei Maven Builds und Jenkins zu leisten, oder Performance Probleme in der AWS Cloud durch Monitoring zu identifizieren. Einem Team habe ich bei der Migration von SVN (Subversion) zu Git und Bitbucket eine Einführung gegeben.

Im Rahmen des Supports stand ich auch dem Maintainer des Artifact Repositorys (Nexus) zur Seite, und habe die Konfiguration für nginx als Reverse Proxy und die passende Konvention für das Image Tagging des internen Docker Repositorys erarbeitet.

Außerdem habe ich zahlreiche Ansible Playbooks geschrieben, so dass wiederkehrende Aufgaben wie VMs einrichten automatisiert ablaufen können. Die Playbooks haben u. A. die firmeninternen Proxy-Regeln eingespielt, den Docker Daemon eingerichtet, oder Docker Images gebaut. Die Playbooks habe ich in AWX eingebunden und für das Team zugänglich gemacht. In einigen Präsentationen wurden meine Kollegen in diese Themen eingeführt.

Im Oktober habe ich einen Know-How Transfer an meinen Nachfolger (angestellt) und weitere externe Mitarbeiter durchgeführt, vor allem zu den Themen Docker, Ansible und AWX.

Meine Arbeit habe ich regelmäßig und ausführlich in Jira, Confluence und Bitbucket (als README.md mit Markdown) dokumentiert. Einige Themen wie z. B. AWX und Docker sind als Handbuch geschrieben, so dass meine Ergebnisse nach der Beauftragung weiter gepflegt werden können. Die Dokumentationssprache, wie auch die Sprache der Schulungen, war Deutsch und Englisch.

#CD, #CI, #ConcourseCI, #GoCD, #Jenkins, #Kubernetes

Für eine bestehende Jenkins Build Pipeline habe ich als Senior DevOps Engineer mögliche Alternativen aufgezeigt, um die Übersichtlichkeit des Build-Status zu verbessern.

Dafür habe ich einen möglichen Einsatz von verschiedenen CI/CD-Tools, sowie die Erweiterung durch Dashboards evaluiert. Das ISC-EJPD nutzt Microservices mit Kubernetes, weshalb zahlreiche verkettete Build-Jobs in Jenkins Pipelines existieren. Diese hatten im bestehenden Zustand keine Gesamtübersicht pro Projekt.

Um aufzuzeigen, wie eine komplexe Build Pipeline visualisiert werden kann, habe ich nach einer Vorauswahl zahlreicher CI/CD-Tools Mockups erstellt. Diese waren Concourse CI, GoCD und Jenkins Blue Ocean.

Das ISC-EJPD hat sich entschieden, bei der aktuellen Lösung mit Jenkins zu bleiben. Aufgrund dieser Tatsache habe ich im zweiten Schritt den möglichen Einsatz von Hygieia evaluiert, welches Daten aus Jenkins und Jira aggregiert, und aufbereitet samt Historie auf einem Dashboard darstellt.

#Buildmanagement, #Git, #Jenkins, #Maven, #RationalSynergy

In einem Folgeauftrag des BayLfSt habe ich als Buildmanager das Kern-Team unterstützt und Beratung während eines Major Releases geleistet, das ebenfalls die Einführung von Git beinhaltet.

Das BayLfSt hat entschieden, dass die Zusammenarbeit mit dem Standort Hannover neu organisiert werden soll. Statt wie bisher von Hannover, soll nun die Quellcodeverwaltung und der Build basierend auf Maven und Jenkins ab dem neuen Major Release innerhalb der eigenen Organisation geschehen.

Während der Phase vor dem Major Release habe ich dem neuen internen Buildmanager und dem Entwickler-Team geholfen, sowohl bei der Migration von Synergy zu Git, als auch bei der Wahl des passenden Git Branching Models. Der neue Build ist eine Weiterentwicklung des zuvor von Hannover gestalteten Builds und nutzt nun Jenkins Pipelines. Hierfür habe ich dem neuen Buildmanager ebenfalls eine Einführung gegeben.

#Git, #GitHubEnterprise, #Jira, #RationalSynergy

Zwischenzeitlich war ich als Berater bei der HZD beauftragt. Dort habe ich der geplanten Umstellung von Synergy zu Git meine Erfahrungen aus dem vorherigen Auftrag beim Bayerischen Landesamt für Steuern geteilt.

Nach der Migration sollte GitHub Enterprise als Git Repository genutzt werden. Wichtige Aspekte waren die Nutzung von Pull Requests und Verknüpfung zu Jira.

#Confluence, #Docker, #Java, #Jenkins, #Jira, #JMeter, #Testing, #ZephyrForJira

Als Interim Test Engineer habe ich die Fortführung der Tests während einer personellen Lücke gesichert. Das automatisierte und manuelle Testing für eine Java Applikation in Docker lief jeweils am Ende der dreiwöchigen Sprints und diente zur Entscheidung, ob die Software ausgerollt werden soll.

Diese Java Applikation, genannt Core Cloud, wird von der Firma Ergon AG im Auftrag der Belimo AG geschrieben. Meine Arbeit umfasste einen Tag vor Ort bei der Ergon AG zum direkten Austausch mit dem Projektleiter und den Entwicklern.

Zu Beginn habe ich eine zweiwöchige Einarbeitung von dem ausscheidenden Mitarbeiter erhalten. Anschließend habe ich seine Aufgabe übernommen und jedes Release mit den Tests geprüft, die von meinen Vorgängern konzipiert und erstellt wurden.

Bei manuellen Tests kam überwiegend ein Browser zum Einsatz, um Use Cases durchzuspielen. Automatisierte Tests wurden mittels Jenkins und JMeter realisiert. Das Testing des jeweiligen Releases wurde als Test Cycle in Zephyr for Jira abgebildet.

Hierbei war die Herausforderung nicht nur die kurze Einarbeitungszeit für die Core Cloud und deren Tests, vielmehr musste das Konzept zum Testing angepasst werden. Aufgrund des hohen Anteils manueller Tests und Arbeitsschritte dauerte das Testing regelmäßig länger als Zeit zwischen Milestone des Sprints zur Verfügung gestellt wurde.

Daher habe ich mit Tabellen und Grafiken einfache Auswertungen in Confluence erstellt und anhand dieser nach Rücksprache mit dem Auftraggeber Anpassungen und Kürzungen vorgenommen.

Zwischen den Test Cycles habe ich ein Handbuch für das Testing in Confluence geschrieben, mit dem Ziel, meinem Nachfolger einen Arbeitsablauf zu beschreiben, der möglichst bei jedem Test Cycle gleich ist. Dabei geht das Handbuch auf bekannte Probleme mit konkreten Lösungen ein. Es basiert zu gleichen Teilen auf der mündlichen Übergabe und der schriftlichen Dokumentation meiner Vorgänger.

Für das letzte Drittel meiner Beauftragung habe ich ausschließlich meinen Nachfolger eingearbeitet.
Projektsprachen waren Deutsch sowie Englisch für einige Teile der Dokumentation.

#Buildmanagement, #Bash, #Java, #JavaEE, #JBossEAP, #Jenkins, #Maven, #Nexus, #RationalChange, #RationalSynergy, #SLES

Für das Projekt BIENE habe ich als Buildmanager den täglichen Build der Java Software in Jenkins betreut. Während anfangs der Fokus auf der Reparatur, Stabilisierung und dem Tagesgeschäft des Builds lag, habe ich zum Ende der Beauftragung die technische Dokumentation für die Buildumgebung geschrieben, sowie Projektleiter und Entwickler beraten.

Das Projekt BIENE stellt die Software für das Erhebungsverfahren bereit, welches bundesweit in den Finanzämtern genutzt wird. BIENE ist Teil des vom Bundesministerium für Finanzen gestarteten Vorhabens KONSENS.

Bei der BIENE-Software handelt es sich um Java EE Anwendungen, die auf JBoss EAP Servern betrieben werden.

Die gesamte BIENE-Software wurde mit Maven auf Jenkins gebaut. Sie ist aufgeteilt in buildrelevante Maven-Module, sowie in fachliche Unterprojekte. Je nach Projektplan und Grad der fertigstellung wandern die einzelnen Unterprojekte in unterschiedliche Build-Schichten. Dadurch verändert sich der Build und die Paketierung häufig und erfordert manuelle Anpassungen von mir und der anderen Buildmanager.

Die Versionierung wurde mit IBM Rational Synergy durchgeführt, welches von IBM nicht mehr weitergeführt wird. Hierfür habe ich bei fehlenden Plugins für Jenkins die übliche Funktionalität per Bash nachprogrammiert. Der Issue-Tracker für dieses Projekt ist IBM Rational Change.

Das Build-Team ist länderübergreifend aufgestellt und wird federführend im Landesamt für Steuern in Niedersachsen bearbeitet. Für Nürnberg stand ich als Ansprechpartner vor Ort für die Entwickler und Projektleiter zur Verfügung. In meiner Rolle als Buildmanager habe ich auch regelmäßig zwischen Niedersachsen und Nürnberg vermittelt.

Neben dem eigentlichen Build in Niedersachsen war meine Aufgabe auch, einen Schatten-Build in Nürnberg zu betreuen, damit Entwickler bei Problemen mit dem Haupt-Build weiterarbeiten können.

Zudem gibt es diverse Build-Jobs in Nürnberg, die Auswertungen erzeugen über die Build-Struktur.

Zu meinem Eintritt war der Build in einem reparaturbedürftigen Zustand. Tägliche Builds konnten ohne manuelle Korrekturen nicht gebaut werden. Durch Analyse, Korrekturen und Erweiterungen haben meine Kollegen und ich den Build in der Zeit darauf weitestgehend stabilisiert. RPM-Pakete für SLES 12 (SUSE Linux Enterprise Server) wurden regelmäßig erzeugt und in Nexus abgelegt.

Die vorherigen Buildmanager haben die Buildumgebung nicht oder nur unzureichend dokumentiert. Es gab viele Personalwechsel ohne Übergabe. Auch unfertige Umsetzungen hatten Einfluss auf die Nutzbarkeit. Aus diesem Grund habe ich die Aufgabe bekommen, eine technische Nachdokumentation der Buildumgebung anzufertigen.

Die Dokumentation beschreibt den Ist-Zustand und bestand zum Austritt aus ca. 100 Seiten. Zusätzlich zum Ist-Zustand enthält die Dokumentation Handlungsempfehlungen für zukünftige Buildmanager, als auch Prozessbeschreibungen. Projekt- und Dokumentationssprache ist Deutsch. Die Dokumentation wurde mit MS Office erstellt.

#Ansible, #Apache, #Bash, #CentOS, #Confluence, #DevOps, #Docker, #Elasticsearch, #Grafana, #Graylog, #Jenkins, #Jira, #MongoDB, #Monitoring, #nginx, #PHP, #Python, #SpringBoot

In einem Team mit anderen Freelancern habe ich als Senior DevOps Engineer die Migration zu einer per Ansible gemanagten Systemlandschaft fortgeführt. Ich habe des Weiteren im Tagesgeschäft Operations ausgeholfen und Graylog für zentralisiertes Logging im Development Team eingeführt.

Damit das Bestands-Team virtuelle Server (CentOS) automatisiert erstellen und konfigurieren kann, habe ich im Team entsprechende Ansible Rollen geschrieben oder erweitert. Dies umfasst die Installation mit umgebungsspezifischer Konfiguration u. A. von Apache, nginx, Elasticsearch, MongoDB, sowie der myToys-eigenen Software.

Im Tagesgeschäft habe ich ausgeholfen und Tickets abgearbeitet. Diese Tickets sind typischerweise eine Fehleranalyse mit anschließender Anpassung der Ansible Rollen. Das Beheben der Fehler erfolgt dann auf allen Cluster-Instanzen per Ansible.

Hierunter fallen auch diverse Themen wie länderspezifische Erweiterungen für das russische myToys Department (Kommunikation erfolgt in Englisch), Anpassungen der Konfiguration für neue Features in Ansible und Integration neuer Metriken für das Monitoring mit Grafana.

Nach Möglichkeit habe ich Aufgaben als Jenkins Jobs angelegt, die den Entwicklern eigenständiges Handeln erlauben. Je nach Anforderung wurden Jenkins Jobs mit Bash oder Python geschrieben.

myToys nutzt für seinen Online-Shop verschiedene Komponenten in diversen Programmiersprachen. Damit im Fehlerfall eine Analyse möglich ist, wurde mir die Aufgabe zugeteilt, Graylog für zentralisiertes Logging zu etablieren. Ich habe entsprechende Graylog-Rollen in Ansible geschrieben und ausgerollt.

Für die Kollegen aus den PHP- und Java-Teams habe ich eine Dokumentation geschrieben und bei der Implementation des Loggings geholfen.

Weiterhin war das Analysieren und Beheben von Problemen mit teilweise undokumentierter Legacy-Software Teil meiner Aufgaben.

Zuletzt habe ich für das Java-Team Docker per Ansible eingerichtet und Spring Boot Anwendungen als Docker-Images verfügbar gemacht.

#C, #CD, #CI, #Flyway, #Git, #Java, #JavaScript, #Jenkins, #Maven, #Nexus, #PostgreSQL, #Python, #SCA, #SonarQube, #Testing

Ich war als Senior DevOps Engineer verantwortlich für die Entwicklung und Administration des Build Services (Continuous Delivery), den ich als In-House Dienstleistung für Entwickler-Teams bereitgestellt habe.

Die eigene Software wurde bei jeder Änderung auf einer Jenkins Installation gebaut. Dabei wurde die Codequalität überprüft sowie mit automatisierten Tests die korrekte Funktion sichergestellt. Projekte in Java, C, Python und JavaScript durchliefen eine einheitliche Build Pipeline. Jeder Schritt der Build Pipeline erzeugte Metriken, die im Intranet bereitgestellt wurden.

Seit meiner Einstellung habe ich Defizite im täglichen Handeln der Entwickler gesehen, da viele Prozesse wie Releases, Rollouts und Feature Integration manuell durchgeführt wurden und somit sehr fehleranfällig waren. Der Fokus lag oft auf Personen und nicht auf reproduzierbaren und automatisierten Prozessen. Jedes Release wurde unterschiedlich gehandhabt. Es gab eine hohe Quote an Fehlern und Rollbacks. Development, QA und Operations haben kaum eine Schnittmenge gehabt.

Mit dem neuen Build Service habe ich die tägliche Arbeit der Entwickler unterstützt, der nach DevOps Mantra einen fließenden Übergang zwischen Development, QA und Operations schafft. Die QA System Tests, zuvor ebenfalls manuell ausgeführt, habe ich per Software Adapter vereinheitlicht und als ein Quality Gate in die Build Pipeline integriert.

Aus einem früher zähen, personenabhängigen Prozess ist ein schneller automatischer Lauf geworden, der Releases im Hintergrund erstellt; die Teams konnten sich fortan auf ihre Kernkompetenz konzentrieren, wie beispielsweise das Schreiben von Features und Tests.

Continuous Integration war ein elementarer Bestandteil des Build Services. Neue Features und Bugfixes wurden von den Entwicklern stetig parallel eingepflegt und sollten automatisch im nächsten Release verfügbar sein. Unfertige Features wurden dabei mit Feature Toggles versehen und konnten zur Laufzeit scharf geschaltet werden.

Ebenfalls wurde das Konzept von Continuous Testing angewendet. Dazu wurden die Änderungen zuerst in einer Sandbox isoliert getestet. Ein Private Build testet die Änderungen im Code, bevor sie für alle zugänglich gemacht werden. Wenn im Testing keine Fehler gefunden wurden, erfolgte ein Merge durch einen weiteren Release Build. Damit bleibt die Stabilität der Mainline gewährleistet.

Alle verfügbaren Tests liefen für jeden einzelnen Commit. Für Integration- und System-Tests aus Maven wurden PostgreSQL-Datenbanken dynamisch befüllt mit Flyway. Entwickler konnten alle Tests lokal ausführen; hierfür wurde eine embedded HSQLDB oder Derby Datenbank vor dem Test In-Memory gestartet.

Die Entscheidung, ob der Code den gewünschten Qualitätsstandard erfüllt, beruhte weiterhin auf den Ergebnissen der SCA (Static Code Analysis) von SonarQube.

Schließlich wurde in der Build-Pipeline ein Deployable erzeugt und in einem Nexus-Repository abgelegt.
Seit der Einführung des neuen Build Services, welche vollautomatisch und im Hintergrund arbeiten, konnte ich die Build Time für die Java Software von 2 Stunden auf 15 Minuten reduzieren (8 mal schneller).

Über eine frei zugängliche Übersicht des Build Zustands und der Code Metriken, z. B. mit Information Radiators in den Räumen der Entwickler, konnten sich Entwickler-Teams jederzeit über den Zustand des Builds informieren.

In Schulungen von Gruppen und Einzelpersonen zum Thema Continuous Integration und Tools, welche je nach Team in Deutsch oder Englisch gehalten wurden, habe ich den Entwicklern die Einführung eines einfacheren Git Branching Modells erklärt. Dies hat sie befähigt, gleichzeitig an mehreren Features, Bugfixes und Hotfixes arbeiten zu können.

#Grunt, #JavaScript, #Protractor

Für einen ehemaligen Kollegen aus meiner vorherigen Anstellung habe ich in einem kurzen Projekt als Test Automation Engineer gearbeitet.

Die interaktive Consumer-Website, die auf AngularJS basiert, habe ich mit Protractor und JavaScript getestet und in den Build-Mechanismus (via Grunt) integriert.

Ebenfalls seit Februar 2016 habe ich mich auf den Wechsel in die Selbständigkeit als Freelancer vorbereitet.

#Hibernate, #Java, #JavaEE, #Jenkins, #JMS, #JMX, #JPA, #JSF, #Linux, #Maven, #MySQL, #Nexus, #SCA, #Selenium, #SonarQube, #Spring, #Subversion

Bei ATLAS Interactive (heute: InternetQ) habe ich als Java-Entwickler am Mobile Payment System kanzaloo (heute: kanzaroo) gearbeitet.

Als Java-Entwickler habe ich für kanzaloo maßgeblich Code und Infrastruktur beigetragen. Diese Software basiert auf einem Mix von Java EE, Spring, Hibernate, JPA, JSF, RichFaces, JMS, sowie Web-Services mit REST und JSON. kanzaloo ist für den internationalen Markt konzipiert und beherrscht i18n und l10n in allen Layern.

Für das Monitoring von kanzaloo habe ich einen JMX Adapter eingeführt, sowie verteilte transaktionale Sicherheit und automatische Retry-Handler für ein robustes System, das eine hohe Fault Tolerance gegenüber Ausfällen aufweist. Das gesamte Consumer Front-End war durch asynchrones Messaging und Polling entkoppelt vom Backend. Dadurch wird die Stabilität und schnelles Feedback im User Interface gewährleistet.

Als Datenbank Administrator (MySQL) habe ich eine Live-Mirror eingerichtet, auf dem Entwickler Queries mit Live-Daten ausprobieren können, ohne das Produktiv-System zu gefährden. Zusätzlich habe ich für die Entwickler diverse Linux-Server betreut und Installationsroutinen für häufig genutzte Software geschrieben, so dass eine einheitliche Systemlandschaft gegeben war.

Des Weiteren habe ich selbständig das Build-Management mit Maven und Jenkins realisiert. Dazu gehörten ein CI Server (Jenkins), ein Artefakt-Repository (Nexus) sowie ein VCS-Repository mit SVN (Subversion). Ich habe das Konzept von Libraries eingeführt, die häufig benötigte Funktionen für andere Systeme bereitstellen.

Ferner erzeugte die SCA mittels SonarQube Berichte über die Code-Qualität. Legacy Projekte habe ich bereinigt in das neue Build-Management überführt. kanzaloo habe ich mit Unit-, Integration- und System-Tests versehen. Unter anderem haben wir das JSF Frontend mit Selenium getestet. Um Selenium auch in legacy Projekten zu nutzen, habe ich ein Framework für unsere Infrastruktur erstellt, welches die Integration von Selenium per Modul erlaubt.

Die Projektsprache war grundsätzlich Englisch, ebenfalls für die Kunden-Dokumentation.

#Groovy, #JavaScript, #Spring

Für unseren Kunden Hermes Logistik Gruppe habe ich als Software-Entwickler in der Frontend-Entwicklung UIs mit JavaScript für Speditions-Agenten erstellt. Die Front-Ends basierten auf ExtJS und RESTful Services. Im Backend, einer Spring Anwendung mit Groovy Code, habe ich ebenfalls mitgearbeitet.

#Java, #JavaEE

Bei aziza haben wir für unsere Kunden mit der eigenen Full Service E-Commerce Platform Yuma personalisierte Web-Shops erstellt, u. A. für die Parfümerie Douglas. Als Software-Entwickler habe ich diverse Features umgesetzt, unter anderem die Payment-Anbindung für Kreditkarten. Yuma, später umbenannt zu Yula, war eine Java EE Applikation.

Aushilfskraft bei einem IT Systemhaus mit Vor-Ort-Service. Online-Redakteur im Marketing. Praktikant in dem IT-Service Unternehmen, bei dem ich später meine Ausbildung erfolgreich absolviert habe.