JCON 2021

Docker und Testcontainers haben das Erstellen von Integrationstests revolutioniert. Nie war es so einfach, realitätsnahe Datenbanken mit Testdaten, ausgewachsene Browser oder andere Infrastruktur in seine Tests zu integrieren. Für die meisten Systeme stehen fertige Container bereit, öffentliche und private Registries erleichtern die Verteilung, und auf dem ausführenden Rechner müssen nur Java- und Docker-Installationen vorhanden sein. In diesem Vortrag werden die Datenbank- und Browsertests einer Spring-Boot-Anwendung von einer H2-Datenbank und einem lokalen Browser auf Docker-Container umgestellt und dabei die wichtigsten Features von Testcontainers vorgestellt.

Unsere Software-Projekte werden immer größer und komplexer. Technologisch hat sich in den vergangenen Jahren eine Menge getan, um diese Komplexität in den Griff zu bekommen. Aber noch viel wichtiger ist die Kommunikation zwischen allen Projektbeteiligten geworden. Als Voraussetzung braucht es dafür eine möglichst aktuelle, pragmatische und zielführende Dokumentation der Softwarearchitektur. Aber leider hat das Dokumentieren häufig einen niedrigen Stellenwert in unseren Projekten. Zum Teil fehlt die Motivation bei den Verantwortlichen. Oder suboptimale Werkzeuge wie Textverarbeitung, schwergewichtige UML-Tools bzw. Wikis ersticken alle Bemühungen im Keim. Wir wollen den Bann brechen und an konkreten Beispielen zeigen, wie Dokumentieren nicht nur Spaß machen, sondern auch leicht von der Hand gehen kann. Dazu berichten wir aus unseren Erfahrungen und rücken leichtgewichtige Tools und schlanke Text- bzw. Grafikformate in den Fokus. Sie erleichtern die automatisierte Erstellung einer effektiven, allumfänglichen und vor allem redundanzfreien Dokumentation, die sich mit wenig Aufwand für die unterschiedlichen Zielgruppen optimiert in verschiedenen Formaten ausliefern lässt. Das Einbetten dieser Documentation as Code in die Entwicklungs- und Reviewprozesse ermöglicht zudem eine gute Nachvollziehbarkeit und die kontinuierliche Verbesserung und Weiterentwicklung.

Software development has changed dramatically in recent years; no longer can you afford to say, “That’s how we’ve always done it.” Applications are evolving rapidly, which requires you to move fast and fix things. And don’t neglect the cultural shift inherent in any technical change. (Some developers, for instance, reject build-break notifications, going so far as removing themselves from the email list.) If you’re just starting your CI/CD journey, you must ensure everyone understands the benefits, including increased speed-to-market, stable builds, and reduced drama around releases. That way, CI/CD won’t just help you deliver for your customers—it will help you sleep better at night.

The idea of limited work-in-progress (WIP) is coming from Lean methodologies. At its core it means that new tasks should only be started when the current piece of work is done and delivered. Finding the right work-in-progress limit can increase overall system (organisation) throughput. This idea can be applied on many levels including writing code. In this live coding session I will write FizzBuzzWoof code kata in Kotlin showcasing software development workflows which can be used for limiting work-in-progress. In particular: change size notifications, auto-revert, TDD, TCR (test && commit || revert).

Die Entwicklung von APIs beginnt immer mit der alten und mittlerweile langweiligen Schlacht von API oder Code first. Aber die Arbeit mit APIs bezieht sich auf einen Prozess, der Design, Entwicklung und Betrieb umfasst. Mit diesen Gedanken im Hinterkopf und den Möglichkeiten von API-Gateways und -Plattformen, diese Prozesse zu unterstützen, stellt sich sehr schnell die Frage, wie diese Prozesse automatisiert werden können. Daniel Kocot zeigt in seiner Session auf, wie API-Gateways oder -Plattformen den Entwicklungsprozess von APIs nach der DevOps-Idee und dem CALMS-Modell positiv beeinflussen können, um den Konsumenten bessere APIs zu liefern.

In 2010, only Linux kernel committers and other early adopters used Git. Almost everyone else used Subversion. Ten years later, Git is the most popular product. Which makes me wonder: what will we use another ten years from now? And what would YOU want from your version control software in 2030? More speed? Better collaboration support? No merge conflicts ever? In this talk I'll discuss a few post-Git products, including Fossil, Plastic and Pijul, and their support for the features we so dearly desire. I'll also try to predict which one will be 'the top dog' in 2030. So attend this session if you're excited about the future of version control and if you want to have a shot at beating even (!) the early adopters. Now if it turns out I was right, remember that you heard it here first. 😀

​Have a look at the Session Teaser!​​​

I always like to be out in the forest, enjoy the quiet, and pursue my thoughts undisturbed. And recently, a question occurred to me that I get asked again and again at conferences, meetups or workshops: The question is almost always: What are the quick wins or low hanging fruits if you want to deal more with the topic of security in software development? And I want to answer this question right now!

Docker und Testcontainers haben das Erstellen von Integrationstests revolutioniert. Nie war es so einfach, realitätsnahe Datenbanken mit Testdaten, ausgewachsene Browser oder andere Infrastruktur in seine Tests zu integrieren. Für die meisten Systeme stehen fertige Container bereit, öffentliche und private Registries erleichtern die Verteilung, und auf dem ausführenden Rechner müssen nur Java- und Docker-Installationen vorhanden sein. In diesem Workshop werden wir die Basics von Testcontainers erarbeiten und im Anschluss Integrationstests mit Datenbank- und Browernutzung auf die Verwendung von Testcontainers umstellen. Zum Schluss werden wir noch weitere Optionen der Nutzung erarbeiten. Voraussetzung für die Mitarbeit * Rechner mit Docker-Installation (Win 10 Pro/EDU/EE, mac os, Linux) * Java * Freies Netzwerk