Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qualitätsszenarien - DevDay Dresden
•
0 gefällt mir•744 views
Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll das Richtige richtig zu implementieren und Software schneller ausliefern zu können. Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Ansätze sind meist zu schwergewichtig, da sie eher auf Wasserfallprojekte zugeschnitten sind. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein? In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.
Melden
Teilen
Melden
Teilen
Downloaden Sie, um offline zu lesen
Empfohlen
Effizient arbeiten mit Architecture Decision Records (ADR)
Dokumentation gehört oft nicht zu den Lieblingsaufgaben im Softwareentwicklungsalltag. Das resultiert in vielen Fällen daraus, dass nicht klar ist, warum etwas dokumentiert werden sollte. Der in der Praxis gelebte Ansatz einen Dokumentationsort, zum Beispiel in Form eines Wikis, ist zum Scheitern verurteilt. Entweder es wird kaum dokumentiert oder zu viel und es wird schwer Informationen zu finden, die man sucht.
Ein leichtgewichtiger Ansatz ist arc42, bei dem je nach Bedarf die vorgegebenen Unterpunkte ausgefüllt werden. Dort werden im Unterpunkt neun Entwurfsentscheidungen dokumentiert, also genau die Entscheidungen, die die Softwarearchitektur entscheidend prägen. Die Auswirkungen von nicht dokumentierten Entscheidungen gehen von immer wiederkehrenden Diskussionen, bis hin zu fehlerhaften Folgeentscheidungen die das Projekt zum Scheitern bringen können. Doch wie können viele Entscheidungen effizient und nachvollziehbar dokumentiert werden?
In diesem Vortrag wird ein kompaktes Format namens Architecture Decision Records (ADR) vorgestellt und gezeigt, wie sie effizient eingesetzt werden können. Neben Kleinigkeiten wie der Titelvergabe für eine ADR wird ein Lösungsvorschlag aufgezeigt, um bei einer großen Sammlung von Entwurfsentscheidungen (>50) nicht den Überblick zu verlieren. Dabei kommt der Docs-As-Code Ansatz mit AsciiDoc und JBake zum Einsatz, mit dem die technische Architektur in einer Microsite gerendert wird. Durch Tagging und eine effiziente Suche, wird die Dokumentation nicht nur lebendig, sondern zum täglichen Arbeitsmittel.
Rock Solid Software Architecture with ADRs, arc42 and Microsites
Das arc42-Architektur-Template verleitet dazu, alle Kapitel von oben nach unten durchzuarbeiten. Ein Architektur-Review offenbart aber eine sinnvollere Herangehensweise, um Softwarearchitektur zu erarbeiten. Dabei werden zuerst In-Scope sowie Out-Of-Scope des Vorhabens definiert und anschließend Qualitätsattribute aufgenommen, um schließlich konkrete Qualitätsszenarien abzuleiten.
Die Dokumentation dieser Ergebnisse im arc42 stellt uns vor viele Aufgaben und Fragestellungen: Wie erarbeite Architekturentscheidungen, Qualitätsattribute und Qualitätsszenarien? Und wie dokumentiere ich diese effizient?
In diesem Vortrag zeigen wir anhand des Docs-as-Code-Ansatzes, wie wir mit dem arc42-Template effizient arbeiten und die Dokumentation als Microsite jedem zur Verfügung gestellt wird. Durch diese Vorgehensweise ist es effizient möglich, eine Architekturdokumentation zu erstellen, die jeder Review standhält.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll, das Richtige richtig zu implementieren und Software schneller ausliefern zu können.
Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Vorgehensweisen wirken zu schwergewichtig, da sie sich eher für Wasserfall-Projekte eignen. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein?
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit Zusatzinformationen, wie Kontext und Randbedingungen. Nicht-funktionale Anforderungen werden als Qualitätsszenarien beschrieben, deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein Instrument zur Kommunikation mit allen Stakeholdern
Skalierbare Flutter Architektur - eine Einführung
Von einzelnen Dateien zur skalierbaren App. Über Konvention und States zu einer State Architektur mit Rivperod.
Roadshow: What's new in Microsoft SQL Server 2016
SQL Server 2016 ist der nächste logische und evolutionäre Schritt in der Entwicklung des SQL Server. In der Roadshow gab Referent Dieter Rüetschi den Teilnehmern die Entscheidungsgrundlage für eine Migration mit auf den Weg.
In der Roadshow wurden die evolutionären Erweiterungen, welche Microsoft SQL Server 2016 bietet, vorgestellt. Dazu gehören die höhere Performance dank verbesserter In-Memory-Leistung, die nächste Generation der Hochverfügbarkeit durch Always On, bessere Skalierbarkeit und erweiterte Reporting-Möglichkeiten. Zudem bietet SQL Server 2016 sowohl lokal wie auch in der Cloud eine einheitliche Umgebung - was das Arbeiten unabhängig davon macht, ob Ihre Daten in Ihrem Rechenzentrum oder in Ihrer Private Cloud sind.
Neben den Erweiterungen gab Dieter Rüetschi auch einen Einblick in die fundamentalen neuen Techniken, welche in SQL Server 2016 eingesetzt werden. Besonders erwähnt seien hier die Advanced Analytics, Query Data Store, und die Always Encrypted Technologie.
Gerne stellen wir Ihnen die Slides der SQL Server 2016 Roadshow zur Verfügung.
Infrastructure Solution Day | Core
• Einleitung
• Windows Server und System Center vNext Investments
• Windows 10 und Enterprise Mobility News
Empfohlen
Effizient arbeiten mit Architecture Decision Records (ADR)
Dokumentation gehört oft nicht zu den Lieblingsaufgaben im Softwareentwicklungsalltag. Das resultiert in vielen Fällen daraus, dass nicht klar ist, warum etwas dokumentiert werden sollte. Der in der Praxis gelebte Ansatz einen Dokumentationsort, zum Beispiel in Form eines Wikis, ist zum Scheitern verurteilt. Entweder es wird kaum dokumentiert oder zu viel und es wird schwer Informationen zu finden, die man sucht.
Ein leichtgewichtiger Ansatz ist arc42, bei dem je nach Bedarf die vorgegebenen Unterpunkte ausgefüllt werden. Dort werden im Unterpunkt neun Entwurfsentscheidungen dokumentiert, also genau die Entscheidungen, die die Softwarearchitektur entscheidend prägen. Die Auswirkungen von nicht dokumentierten Entscheidungen gehen von immer wiederkehrenden Diskussionen, bis hin zu fehlerhaften Folgeentscheidungen die das Projekt zum Scheitern bringen können. Doch wie können viele Entscheidungen effizient und nachvollziehbar dokumentiert werden?
In diesem Vortrag wird ein kompaktes Format namens Architecture Decision Records (ADR) vorgestellt und gezeigt, wie sie effizient eingesetzt werden können. Neben Kleinigkeiten wie der Titelvergabe für eine ADR wird ein Lösungsvorschlag aufgezeigt, um bei einer großen Sammlung von Entwurfsentscheidungen (>50) nicht den Überblick zu verlieren. Dabei kommt der Docs-As-Code Ansatz mit AsciiDoc und JBake zum Einsatz, mit dem die technische Architektur in einer Microsite gerendert wird. Durch Tagging und eine effiziente Suche, wird die Dokumentation nicht nur lebendig, sondern zum täglichen Arbeitsmittel.
Rock Solid Software Architecture with ADRs, arc42 and Microsites
Das arc42-Architektur-Template verleitet dazu, alle Kapitel von oben nach unten durchzuarbeiten. Ein Architektur-Review offenbart aber eine sinnvollere Herangehensweise, um Softwarearchitektur zu erarbeiten. Dabei werden zuerst In-Scope sowie Out-Of-Scope des Vorhabens definiert und anschließend Qualitätsattribute aufgenommen, um schließlich konkrete Qualitätsszenarien abzuleiten.
Die Dokumentation dieser Ergebnisse im arc42 stellt uns vor viele Aufgaben und Fragestellungen: Wie erarbeite Architekturentscheidungen, Qualitätsattribute und Qualitätsszenarien? Und wie dokumentiere ich diese effizient?
In diesem Vortrag zeigen wir anhand des Docs-as-Code-Ansatzes, wie wir mit dem arc42-Template effizient arbeiten und die Dokumentation als Microsite jedem zur Verfügung gestellt wird. Durch diese Vorgehensweise ist es effizient möglich, eine Architekturdokumentation zu erstellen, die jeder Review standhält.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...
Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll, das Richtige richtig zu implementieren und Software schneller ausliefern zu können.
Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Vorgehensweisen wirken zu schwergewichtig, da sie sich eher für Wasserfall-Projekte eignen. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein?
In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit Zusatzinformationen, wie Kontext und Randbedingungen. Nicht-funktionale Anforderungen werden als Qualitätsszenarien beschrieben, deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein Instrument zur Kommunikation mit allen Stakeholdern
Skalierbare Flutter Architektur - eine Einführung
Von einzelnen Dateien zur skalierbaren App. Über Konvention und States zu einer State Architektur mit Rivperod.
Roadshow: What's new in Microsoft SQL Server 2016
SQL Server 2016 ist der nächste logische und evolutionäre Schritt in der Entwicklung des SQL Server. In der Roadshow gab Referent Dieter Rüetschi den Teilnehmern die Entscheidungsgrundlage für eine Migration mit auf den Weg.
In der Roadshow wurden die evolutionären Erweiterungen, welche Microsoft SQL Server 2016 bietet, vorgestellt. Dazu gehören die höhere Performance dank verbesserter In-Memory-Leistung, die nächste Generation der Hochverfügbarkeit durch Always On, bessere Skalierbarkeit und erweiterte Reporting-Möglichkeiten. Zudem bietet SQL Server 2016 sowohl lokal wie auch in der Cloud eine einheitliche Umgebung - was das Arbeiten unabhängig davon macht, ob Ihre Daten in Ihrem Rechenzentrum oder in Ihrer Private Cloud sind.
Neben den Erweiterungen gab Dieter Rüetschi auch einen Einblick in die fundamentalen neuen Techniken, welche in SQL Server 2016 eingesetzt werden. Besonders erwähnt seien hier die Advanced Analytics, Query Data Store, und die Always Encrypted Technologie.
Gerne stellen wir Ihnen die Slides der SQL Server 2016 Roadshow zur Verfügung.
Infrastructure Solution Day | Core
• Einleitung
• Windows Server und System Center vNext Investments
• Windows 10 und Enterprise Mobility News
BATbern41 Die Evolution zu Microservices
Die Mobiliar setzt seit 2014 Microservices ein. Schrittweise wurden bis heute 450 Microservices in die Produktion gebracht.
Dabei haben wir viel über die Schnittstellen, Granularität, Plattformarchitektur aber auch viel über Continous Delivery von
Microservices gelernt.
Wir implementierten einen Approach wie man eine lose Architektur für die Teams und die IT Architektur messen und verwalteten kann (Architecture as Code). Die Veränderung der Entwicklungskultur (DevOps, Leadership) konnte ebenfalls beobachtet werden. Einige Aspekte dieser Erfahrungen werden vorgestellt und geteilt.
Roadshow Oracle Database 12c: News & Features
Oracle implementierte über 500 neue Funktionen in die neuste Datenbankversion 12c. Da ist es schwierig, eine einzelne neue Funktion herauszupicken. Multitenant Pluggable Database, Life Cycle Management oder neue Funktionen im Bereich «High Availablity» sind nun verfügbar.
Fachspezialisten von Oracle gaben im Rahmen der Partnerschaft von Digicomp zu Oracle University einen Einblick in die Fülle und die Möglichkeiten der Version 12c.
Die Inhalte zielen auf alle Benutzergruppen der Oracle-DB: Administratoren, Entwickler, technische Berater, Consultants, High-Level-Manager, IT-Entscheider und alle anderen mit Interesse an der Weiterentwicklung der DB.
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
JAX 2017, Mainz: Vortrag von Josef Fuchshuber (@fuchshuber, Cheftechnologe bei QAware) und Tobias Placht (@knacht, Software Ingenieur bei QAware).
Abstract: Wie oft kannst du ein neues Feature releasen? Jede Woche? Jeden Tag? Jede Stunde? Continuous Delivery ist einer der wesentlichen Treiber, warum wir Cloud-native Anwendung bauen. Für Software-driven Organisationen ist das der Schlüssel für eine sicherere, stabilere Software bei minimiertem Risiko und kurzen Feedbackschleifen. Die Herausforderung dabei ist, aus jeder Codeänderung möglichst schnell eine lauffähige und gründlich getestete Software zu machen. Das ist für viele Firmen ein wesentlicher Wettbewerbsvorteil. Wir zeigen in diesem Vortrag eine Werkzeugkette, mit der Continuous Delivery nicht nur für Cloud-native Anwendungen, sondern auch auf Cloud-nativer Infrastruktur möglich ist. Ganz im Gedanken von „Everything is Code“ betrachten wir dabei nicht nur das Bauen und Testen von Software, sondern auch die Automatisierung der Infrastrukturbereitstellung, der Deployments und Roll-outs. Dabei treffen alte Bekannte (z.B. Jenkins, SonarQube) auf Cloud-Computing-Technologien wie z.B. Docker für Betriebssystemvirtualisierung und DC/OS für das Clustermanagement.
Cloud Native & Java EE: Freund oder Feind?
JavaLand 2017, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware)
Abstract:
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Cloud Native und Java EE: Freund oder Feind?
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln- ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
#dachnug50 | Erfolgreiche Digitalisierung | Notes Anwendungen mit Low-Code Lösung erstellen am Beispiel DNUG Call for Abstracts | Werner Götz
Roadshow: «Whats new in sql server 2014»
Mit SQL Server 2014 bringt Microsoft im 2. Quartal 2014 den Nachfolger von SQL Server 2012 auf den Markt.
In dieser Roadshow präsentierte Kursleiter Dieter Rüetschi die wesentlichen Erweiterungen und Ergänzungen. Unter anderem folgende Themen:
- Neuerungen in der Entwicklung von Datenbanklösungen
- In-Memory Datenbanken
- Scripting
- Security Erweiterungen
- High Availability
Our way to 19c - DOAG 2020
Already 4 years we plan the upgrade from 11c to a new supported version.
Somehow, on the one hand business projects were more important, on the other hand the exact technical procedure was not clear.
All databases have to be migrated, but some software vendors did not offer support at all.
The requirements diverged: consolidation to save costs versus dedicated environments to manage security and operations more easily.
When we finally knew how we wanted to proceed, technical details quickly threw the planning off course.
The target platform became 12c, 18 and now 19c
At some point, however, the threat of the final loss of support for 11g and the accumulating other requirements put the necessary pressure on the implementation.
This presentation will show you how and why we proceeded in this way and how we finally reached the finish line.
Maybe our experiences will help some of you to finally take the step!
Exchange Server 2019 MetaCache Database und BigFunnel
Diese Präsentation für die Exchange Server User Group erläutere ich die Funktion und Vorteile der MetaCache Datenbank von Exchange Server 2019. Die MetaCache Datenbank (MCDB) verbessert mit der neuen Suchfunktion (BigFunnel) die Performance von Exchange Server 2019.
Sql Server Grundlagen für Sharepoint Administratoren
Vortrag von Steffen Krause, Technical Evangelist, Microsoft Deutschland auf der Sharepoint User Group Dresden am 11.06.2009.
Sql Server GrundlagenfüR Share Point Admins
Sql Server Grundlagen für Share Point Admins
von Steffen Krause
On the Portability of Applications in Platform as a Service
Get the book "On the Portability of Applications in Platform as a Service" at https://www.amazon.de/dp/3863096312
PHD thesis defense presentation.
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
ECN Summit 2019, München: Workshop von Josef Adersberger (@adersberger, CTO QAware), Helmut Weiss (Beck et al.) und Mario Lohner (Syncier Cloud)
Abstract:
Um eine Anwendungslandschaft in die Zukunft zu führen wird immer deutlicher, dass kein Weg mehr an Cloud Native Plattformen wie Kubernetes vorbei führt. Eine flexiblere Entwicklung, hochfrequente Releases sowie geringere Betriebskosten und eine bessere Skalierbarkeit zählen mit zu den Hauptvorteilen dieser Technologie. Dies erreicht man jedoch nicht durch eine simple Migration der bestehenden Anwendungen in einen Container und einem Betrieb auf Kubernetes.
Im Workshop gliedert sich dabei in drei Teile:
- Migration von IT-Services in die Cloud
- Migration von Anwendungen in die Cloud
- Aufbau einer Kubernetes-Plattform mit Blick auf Day 2
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cl...
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cluster
Vortrag auf dem Expertenkreis Java, GEDOPLAN GmbH, Bielefeld
Developer Relations Metrics - A Humble Guide
Metrics in Developer Relations can be perplexing, often leading to confusion and vague advice.
In this talk, I share practical insights gathered from my extensive research and hands-on application within my current company.
If you've ever felt lost in discussions where specific recommendations are elusive, join me. This session is a down-to-earth guide for both newcomers and experienced professionals, offering practical wisdom to navigate the metrics maze.
Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf
Testing workflows that span multiple applications and platforms is a challenging task. Imagine a test case that calls an API first, then an operator has to enter information at his web app so that the end user finally sees the update in his native app on a smartphone. Real End-to-End automation is nearly impossible today.
Current approaches try to automate cross-platform with the help of web apps running on (mobile) browsers. Native apps on Android or iOS can only be included in the workflow using time-intensive techniques like picture-in-picture search because they lack code selectors that operate on the Document-Object-Model (DOM).
With the rise of machine learning/artificial intelligence, we can train models to recognize elements on User Interfaces based solely on visual attributes. With that, it becomes possible to automate any platform when you combine it with automation on the Operating System level.
In this talk, I will show a live demo that will walk the audience step-by-step through a typical 2-Factor Authentication using a physical smartphone. We will see what automation is possible today and how it enables testing currently untestable workflows.
Weitere ähnliche Inhalte
Ähnlich wie Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qualitätsszenarien - DevDay Dresden
BATbern41 Die Evolution zu Microservices
Die Mobiliar setzt seit 2014 Microservices ein. Schrittweise wurden bis heute 450 Microservices in die Produktion gebracht.
Dabei haben wir viel über die Schnittstellen, Granularität, Plattformarchitektur aber auch viel über Continous Delivery von
Microservices gelernt.
Wir implementierten einen Approach wie man eine lose Architektur für die Teams und die IT Architektur messen und verwalteten kann (Architecture as Code). Die Veränderung der Entwicklungskultur (DevOps, Leadership) konnte ebenfalls beobachtet werden. Einige Aspekte dieser Erfahrungen werden vorgestellt und geteilt.
Roadshow Oracle Database 12c: News & Features
Oracle implementierte über 500 neue Funktionen in die neuste Datenbankversion 12c. Da ist es schwierig, eine einzelne neue Funktion herauszupicken. Multitenant Pluggable Database, Life Cycle Management oder neue Funktionen im Bereich «High Availablity» sind nun verfügbar.
Fachspezialisten von Oracle gaben im Rahmen der Partnerschaft von Digicomp zu Oracle University einen Einblick in die Fülle und die Möglichkeiten der Version 12c.
Die Inhalte zielen auf alle Benutzergruppen der Oracle-DB: Administratoren, Entwickler, technische Berater, Consultants, High-Level-Manager, IT-Entscheider und alle anderen mit Interesse an der Weiterentwicklung der DB.
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
JAX 2017, Mainz: Vortrag von Josef Fuchshuber (@fuchshuber, Cheftechnologe bei QAware) und Tobias Placht (@knacht, Software Ingenieur bei QAware).
Abstract: Wie oft kannst du ein neues Feature releasen? Jede Woche? Jeden Tag? Jede Stunde? Continuous Delivery ist einer der wesentlichen Treiber, warum wir Cloud-native Anwendung bauen. Für Software-driven Organisationen ist das der Schlüssel für eine sicherere, stabilere Software bei minimiertem Risiko und kurzen Feedbackschleifen. Die Herausforderung dabei ist, aus jeder Codeänderung möglichst schnell eine lauffähige und gründlich getestete Software zu machen. Das ist für viele Firmen ein wesentlicher Wettbewerbsvorteil. Wir zeigen in diesem Vortrag eine Werkzeugkette, mit der Continuous Delivery nicht nur für Cloud-native Anwendungen, sondern auch auf Cloud-nativer Infrastruktur möglich ist. Ganz im Gedanken von „Everything is Code“ betrachten wir dabei nicht nur das Bauen und Testen von Software, sondern auch die Automatisierung der Infrastrukturbereitstellung, der Deployments und Roll-outs. Dabei treffen alte Bekannte (z.B. Jenkins, SonarQube) auf Cloud-Computing-Technologien wie z.B. Docker für Betriebssystemvirtualisierung und DC/OS für das Clustermanagement.
Cloud Native & Java EE: Freund oder Feind?
JavaLand 2017, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware)
Abstract:
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
Cloud Native und Java EE: Freund oder Feind?
Anwendungen nativ für den Betrieb in der Cloud auszulegen, ist der Architekturstil der Stunde: Microservices, 12-Factor Apps und Serverless-Architecturen sind en vogue. Daneben gibt es Java EE, das sich über Jahre bewährt hat beim Bau von Java-Anwendungen fürs Unternehmen. Java-EE-Anwendungen im modernen Cloud-Native-Stil zu entwickeln- ist kein Widerspruch, sondern ein Zugewinn: Man kann damit Enterprise-Anwendungen bauen, die reif für die Cloud-Ära sind.
Der Vortrag zeigt am laufenden Beispiel, wie man eine Cloud-Native-Java-EE-Anwendung entwickelt und wie sich Java-EE-APIs wie JAX-RS, CDI und JPA integrieren mit Cloud-Native-Infrastruktur wie DC/OS, Kubernetes, Hystrix, Traefik, Consul und Docker. Dabei wird nicht nur blanke Technologie gezeigt, sondern auch das Thema Cloud Native Java EE auf Architekturebene betrachtet.
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
#dachnug50 | Erfolgreiche Digitalisierung | Notes Anwendungen mit Low-Code Lösung erstellen am Beispiel DNUG Call for Abstracts | Werner Götz
Roadshow: «Whats new in sql server 2014»
Mit SQL Server 2014 bringt Microsoft im 2. Quartal 2014 den Nachfolger von SQL Server 2012 auf den Markt.
In dieser Roadshow präsentierte Kursleiter Dieter Rüetschi die wesentlichen Erweiterungen und Ergänzungen. Unter anderem folgende Themen:
- Neuerungen in der Entwicklung von Datenbanklösungen
- In-Memory Datenbanken
- Scripting
- Security Erweiterungen
- High Availability
Our way to 19c - DOAG 2020
Already 4 years we plan the upgrade from 11c to a new supported version.
Somehow, on the one hand business projects were more important, on the other hand the exact technical procedure was not clear.
All databases have to be migrated, but some software vendors did not offer support at all.
The requirements diverged: consolidation to save costs versus dedicated environments to manage security and operations more easily.
When we finally knew how we wanted to proceed, technical details quickly threw the planning off course.
The target platform became 12c, 18 and now 19c
At some point, however, the threat of the final loss of support for 11g and the accumulating other requirements put the necessary pressure on the implementation.
This presentation will show you how and why we proceeded in this way and how we finally reached the finish line.
Maybe our experiences will help some of you to finally take the step!
Exchange Server 2019 MetaCache Database und BigFunnel
Diese Präsentation für die Exchange Server User Group erläutere ich die Funktion und Vorteile der MetaCache Datenbank von Exchange Server 2019. Die MetaCache Datenbank (MCDB) verbessert mit der neuen Suchfunktion (BigFunnel) die Performance von Exchange Server 2019.
Sql Server Grundlagen für Sharepoint Administratoren
Vortrag von Steffen Krause, Technical Evangelist, Microsoft Deutschland auf der Sharepoint User Group Dresden am 11.06.2009.
Sql Server GrundlagenfüR Share Point Admins
Sql Server Grundlagen für Share Point Admins
von Steffen Krause
On the Portability of Applications in Platform as a Service
Get the book "On the Portability of Applications in Platform as a Service" at https://www.amazon.de/dp/3863096312
PHD thesis defense presentation.
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
ECN Summit 2019, München: Workshop von Josef Adersberger (@adersberger, CTO QAware), Helmut Weiss (Beck et al.) und Mario Lohner (Syncier Cloud)
Abstract:
Um eine Anwendungslandschaft in die Zukunft zu führen wird immer deutlicher, dass kein Weg mehr an Cloud Native Plattformen wie Kubernetes vorbei führt. Eine flexiblere Entwicklung, hochfrequente Releases sowie geringere Betriebskosten und eine bessere Skalierbarkeit zählen mit zu den Hauptvorteilen dieser Technologie. Dies erreicht man jedoch nicht durch eine simple Migration der bestehenden Anwendungen in einen Container und einem Betrieb auf Kubernetes.
Im Workshop gliedert sich dabei in drei Teile:
- Migration von IT-Services in die Cloud
- Migration von Anwendungen in die Cloud
- Aufbau einer Kubernetes-Plattform mit Blick auf Day 2
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cl...
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cluster
Vortrag auf dem Expertenkreis Java, GEDOPLAN GmbH, Bielefeld
Ähnlich wie Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qualitätsszenarien - DevDay Dresden (20)
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
AdminCamp 2014: Quo Vadis – Wohin mit IBM Notes/Domino?
AdminCamp 2014: Quo Vadis – Wohin mit IBM Notes/Domino?
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
Exchange Server 2019 MetaCache Database und BigFunnel
Exchange Server 2019 MetaCache Database und BigFunnel
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
On the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a Service
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cl...
Infinispan / JBoss Data Grid - Schneller Zugriff auf große Datenmengen im Cl...
Mehr von Johannes Dienst
Developer Relations Metrics - A Humble Guide
Metrics in Developer Relations can be perplexing, often leading to confusion and vague advice.
In this talk, I share practical insights gathered from my extensive research and hands-on application within my current company.
If you've ever felt lost in discussions where specific recommendations are elusive, join me. This session is a down-to-earth guide for both newcomers and experienced professionals, offering practical wisdom to navigate the metrics maze.
Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf
Testing workflows that span multiple applications and platforms is a challenging task. Imagine a test case that calls an API first, then an operator has to enter information at his web app so that the end user finally sees the update in his native app on a smartphone. Real End-to-End automation is nearly impossible today.
Current approaches try to automate cross-platform with the help of web apps running on (mobile) browsers. Native apps on Android or iOS can only be included in the workflow using time-intensive techniques like picture-in-picture search because they lack code selectors that operate on the Document-Object-Model (DOM).
With the rise of machine learning/artificial intelligence, we can train models to recognize elements on User Interfaces based solely on visual attributes. With that, it becomes possible to automate any platform when you combine it with automation on the Operating System level.
In this talk, I will show a live demo that will walk the audience step-by-step through a typical 2-Factor Authentication using a physical smartphone. We will see what automation is possible today and how it enables testing currently untestable workflows.
The Future of UI Testing - Challenges in UI Automation
UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention.
In addition to classical selector-based approaches, more and more image-based methods are being pursued. This talk will cover the "state of the art" of UI testing with an overview of tools and techniques.
In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done. In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.
Managed Cloud to GitOps: Deploying Several Client Clusters
What is the best practice to roll out a product in a multi-client group environment? Hopefully, purchase a multi-client capable product that meets the requirement of process separation for clients. Unfortunately, we did not have such a product available in our team and were faced with the challenge of having to set up a separate system for each client.
In this talk, we will describe the three development stages of our deployment process with respect to the server infrastructure in AWS including separation of AWS accounts into test and production environments. The first phase describes the setup of a managed cloud with fixed servers. Although these can be set up automatically, the automatic scalability is insufficient.
The next iteration highlights the "infrastructure as code" approach via cloudformation, which worked very well for a dedicated system. Problems we had were the proper Git flow and the lack of support for true separation of systems per AWS account.
In our current and hopefully final iteration, we switched to a consistent GitOps approach. We describe how we have been using this approach for months to bring stable infrastructure deployments into production via Gitlab, what challenges had to be solved in terms of Configuration as Code and proper Git flow. We also talk about how this process facilitates compliance with various corporate requirements, such as ISO 20000 for release and change management.
Stoizismus - Praktische Philosophie für den IT-Alltag (Pecha Kucha)
Es vergeht kaum ein Jahr in dem keine neue disruptive Technologie auftaucht. War es früher möglich mit moderatem Aufwand sich auf dem neuesten Stand zu halten, ist es inzwischen praktisch unmöglich geworden. Zusätzlich wird mit agilen Methoden entwickelt und gerade im Konzernumfeld schlagen vorhandene zwischenmenschliche und politische Spannungen dadurch oft bis auf den einzelnen Mitarbeiter durch.
Auch ich sah mich in dieser Situation und war auf der Suche, wie ein sinnvoller Umgang damit aussehen kann.
Dabei stieß ich auf die griechische Philosophie namens Stoizismus. Sie wird von vielen Menschen praktiziert, die sich in herausfordernden Lebensumständen befinden. Als ganzheitliche praxisfokusierte Philosophie richtet sich der Stoizismus vor allem an den einzelnen Menschen und hilft ihm dabei das höchste Ziel des glücklichen Daseins (Eudaimonía) anzustreben.
In diesem Vortrag werden die Grundzüge des Stoizismus vorgestellt. Anschließend beschäftigen wir uns mit den wichtigsten Eigenschaften eines übenden Stoikers. Darunter auch emotionale Selbstbeherrschung. Diese können durch geeignete Übungen gezielt trainiert werden, um im Alltag mehr Gelassenheit zu bekommen und resilienter zu werden. Im Alltag lässt sich damit Stress vermeiden und der Fokus auf die möglichen Lösungen lenken anstatt nicht gewinnbringende Auseinandersetzungen einzugehen.
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
Was ist die beste Vorgehensweise um ein Produkt im Konzernumfeld für mehrere Mandanten auszurollen? Hoffentlich ein multimandantenfähiges Kaufprodukt einkaufen, das der Vorgabe der Prozesstrennung für Mandanten entspricht. Leider hatten wir in unserem Team kein solches Produkt zur Verfügung und standen vor der Herausforderung für jeden Mandanten einen eigenes System aufsetzen zu müssen.
In diesem Vortrag beschreiben wir die drei Entwicklungsstufen unseres Deploymentprozesses hinsichtlich der Server-Infrastruktur in AWS inklusive Trennung der AWS-Accounts in Test- und Produktiv-Umgebungen. Die erste Phase beschreibt dabei den Aufbau einer managed Cloud mit festen Servern. Diese können zwar automatisiert eingerichtet werden, die automatische Skalierbarkeit ist aber unzureichend.
Die nächste Iteration beleuchtet den Ansatz des "Infrastructure as Code" über Cloudformation, der für ein dediziertes System sehr gut funktionierte. Probleme bereiteten uns der richtige Git-Flow und die fehlende Unterstützung für eine echte Trennung der Systeme pro AWS-Account.
In unserer aktuellen und hoffentlich finalen Iteration sind wir auf einen konsequenten GitOps-Ansatz gewechselt. Wir beschreiben, wie wir mit diesem Vorgehen seit Monaten stabile Infrastuktur-Deployments über Gitlab in Produktion bringen, welche Herausforderungen zu lösen waren im Hinblick auf Configuration as Code und dem richtigen Git-Flow. Auch die Erleichterung hinsichtlich der Einhaltung verschiedener Konzernvorgaben, beispielsweise der ISO 20000 an Release- und Changemanagement, darf hierbei nicht fehlen.
Managed Cloud to GitOps: Deploying Several Client Clusters
What is the best practice to roll out a product in a multi-client group environment? Hopefully, purchase a multi-client capable product that meets the requirement of process separation for clients. Unfortunately, we did not have such a product available in our team and were faced with the challenge of having to set up a separate system for each client.
In this talk, we will describe the three development stages of our deployment process with respect to the server infrastructure in AWS including separation of AWS accounts into test and production environments. The first phase describes the setup of a managed cloud with fixed servers. Although these can be set up automatically, the automatic scalability is insufficient.
The next iteration highlights the "infrastructure as code" approach via cloudformation, which worked very well for a dedicated system. Problems we had were the proper Git flow and the lack of support for true separation of systems per AWS account.
In our current and hopefully final iteration, we switched to a consistent GitOps approach. We describe how we have been using this approach for months to bring stable infrastructure deployments into production via Gitlab, what challenges had to be solved in terms of Configuration as Code and proper Git flow. We also talk about how this process facilitates compliance with various corporate requirements, such as ISO 20000 for release and change management.
Griechische Philosophie für moderne Softwareentwicklung
Es vergeht kaum ein Jahr in dem keine neue disruptive Technologie auftaucht. War es früher möglich mit moderatem Aufwand sich auf dem neuesten Stand zu halten, ist es inzwischen praktisch unmöglich geworden. Zusätzlich wird mit agilen Methoden entwickelt und gerade im Konzernumfeld schlagen vorhandene zwischenmenschliche und politische Spannungen dadurch oft bis auf den einzelnen Mitarbeiter durch.
Auch ich sah mich in dieser Situation und war auf der Suche, wie ein sinnvoller Umgang damit aussehen kann.
Dabei stieß ich auf die griechische Philosophie namens Stoizismus. Sie wird von vielen Menschen praktiziert, die sich in herausfordernden Lebensumständen befinden. Als ganzheitliche praxisfokusierte Philosophie richtet sich der Stoizismus vor allem an den einzelnen Menschen und hilft ihm dabei das höchste Ziel des glücklichen Daseins (Eudaimonía) anzustreben.
In diesem Vortrag werden die Grundzüge des Stoizismus vorgestellt. Anschließend beschäftigen wir uns mit den wichtigsten Eigenschaften eines übenden Stoikers. Darunter auch emotionale Selbstbeherrschung. Diese können durch geeignete Übungen gezielt trainiert werden, um im Alltag mehr Gelassenheit zu bekommen und resilienter zu werden. Im Alltag lässt sich damit Stress vermeiden und der Fokus auf die möglichen Lösungen lenken anstatt nicht gewinnbringende Auseinandersetzungen einzugehen.
Lessons Learned Using arc42 in a Real DevOps Team
In this presentation, the speaker will talk about his experiences, successes and failures with the arc42 architecture template in a DevOps team in a corporate environment with a product development focus.
Product development is often characterised by short iteration cycles and is therefore often operated in an agile manner, as in the speaker's team. There the existing unstructured documentation was transferred to the arc42 template and stored in a wiki. In the course of time, it turned out that tooling plays a decisive role for the quality of the documentation and therefore switched to Docs-as-Code.
In the course of the presentation, the most important decision points for the current iteration of the technical software architecture will be discussed. These include the handling of "developer prose", outdated documentation and the architecture decisions that are particularly important for a DevOps team. The integration into the methodical procedure Kanban was made possible with arc42 and a microsite based on AsciiDoc.
Not left out are the mistakes made, such as missing quality assurance of created documentation or the mixing of business and technical topics.
Lessons Learned: arc42 in einem echten DevOps Team
n diesem Vortrag berichtet der Sprecher von seinen Erfahrungen, Erfolgen und Fehlern mit dem arc42-Architekturtemplate in einem DevOps-Team im Konzernumfeld mit Produktentwicklungsfokus.
Produktentwicklung ist geprägt von kurzen Iterationszyklen und wird darum gerne agil betrieben, wie im Team des Sprechers. Dort wurde die vorhandene unstrukturierte Dokumentation in das arc42-Template überführt und in einem Wiki abgelegt. Im Laufe der Zeit stellte sich heraus, dass das Tooling eine entscheidende Rolle für die Qualität der Dokumentation bedeutet und deswegen auf Docs-as-Code umgestellt.
Im Laufe des Vortrags wird auf die wichtigsten Entscheidungspunkte für die aktuelle Iteration der technischen Softwarearchitektur eingegangen. Darunter unter anderem der Umgang mit "Entwicklerprosa", veralteter Dokumentation und der für ein DevOps-Team besonders wichtigen Architekturentscheidungen. Die Einbindung in das methodische Vorgehen Kanban wurde mit arc42 und einer Microsite basierend auf AsciiDoc möglich.
Nicht ausgespart werden die gemachten Fehler, wie zum Beispiel fehlende Qualitätssicherung erstellter Dokumentation oder die Vermischung von fachlichen und technischen Themen.
Work efficiently with Architecture Decision Records
Documentation is not one of the favorite tasks in everyday software development. Either there is hardly any documentation or too much. This makes it difficult to find information. A lightweight approach is the arc42 template. It also documents design decisions that shape the software architecture. Undocumented design decisions can lead to incorrect follow-up decisions that can cause the project to fail. But how can many decisions be documented efficiently and comprehensibly? This presentation will introduce a compact format called Architecture Decision Records (ADR) and show how they can be used efficiently. In addition to small details such as title assignment, a proposed solution is shown for dealing with a large collection of design decisions (>50). The Docs As Code approach is used. Through tagging and an efficient search, the documentation becomes a daily work tool.
The Dev, The Ops, And The Team: What works in a DevOps Team?
Mit DevOps sollen Dev und Ops zusammenwachsen. Dadurch sollen Teams in die Lage versetzt werden, die komplette Wertschöpfungskette abzudecken. Von der Anforderungen bis hin zum Betrieb in der Produktion. Die Qualität der produzierten Lösung soll sich dadurch signifikant erhöhen, da keine lokale Optimierung mehr stattfindet.
Das hört sich zuerst einmal sinnvoll und attraktiv für Mitglieder eines DevOps-Teams an. Mit der gleichen Einstellung war ich vor einem Jahr einem DevOps-Team in der DB Systel beigetreten.
In diesem Vortrag schildere ich meine persönlichen Erfahrungen in diesem Team. Was für uns funktioniert und was nicht funktioniert hat. Dabei werden schmerzhafte Erkenntnisse nicht ausgespart, aber auch gezeigt, welche Strategien zum Erfolg führen können.
Spock vs Supermutanten: Spezifikationstesten trifft Mutationstesten
Das Spock Testframework verwendet das ausdrucksstarke Groovy um BDD als Testansatz zu realisieren. Neben einer klaren Teststruktur punktet es mit lesbaren Reports, die dank einer Template-Engine auch in AsciiDoc generiert werden können. Kann man das noch verbessern? Wir treten den Beweis an und kombinieren Spock mit Mutationstests. Denn eine Testabdeckung von über 80 % beweist noch nicht, dass die Testsuite in der Lage ist Fehler zuverlässig zu erkennen. Der Vortrag zeigt, wie sich Spock mit Mutationstesten zu einem cleveren Duo kombinieren lässt.
Everything as Code: Pipeline, Infrastructure, Configuration, Documentation
Everything as Code ist die Antwort auf Cloudifizierung und Automatisierung.
Wird alles zu Code, dann wird die Arbeit durch die immer gleichen Tools wie Git erheblich vereinfacht. Dafür gibt es sogar einen Begriff: GitOps.
Die Vorteile basieren darauf, dass Codeänderungen immer versioniert vorliegen, dadurch nachvollziehbar, testbar und wiederholbar werden.
In diesem Foliensatz werden die Grundlagen gezeigt, wie Pipelines, Infrastruktur, Konfiguration und Dokumentation als Code abgelegt werden und welche Vorteile sich daraus ergeben.
DevOps im Konzern - Autonomie vs Betriebssicherheit (Continuous Lifecycle)
Aus Sicht eines DevOps-Teams ist für eine hohe angestrebte Geschwindigkeit hohe Autonomie bei allen Architektur- und Implementierungsentscheidungen notwendig. Aus Sicht der DB Systel, die den stabilen IT-Betrieb der Deutschen Bahn sicherstellen soll, ist die Forderung nach Autonomie jedoch ein Risiko.
Zur Lösung dieses Konfliktes findet man daher in der Industrie häufig Ansätze, bei der Betriebseinheiten zentral betreute CI/CD-Pipelines bereitstellen. Während die mit dieser Lösung verbundene Automatisierung eine gute Kontrolle von Betriebsaspekten mit sich bringt, stellt die damit auch verbundene notwendige Standardisierung von Architekturaspekten häufig eine zu starke Einschränkung der Autonomie von DevOps-Teams dar.
In diesem Talk möchten wir darauf eingehen, wie die DB Systel ihren DevOps-Teams durch Verortung der Betriebsverantwortung in den DevOps-Teams eine optimale Autonomie gewährt und gleichzeitig die Risiken für Stabilität, Datenschutz und Compliance kontrolliert.
Wir geben Ihnen auch einen Einblick in den Alltag eines DevOps-Teams in der DB Systel aus Sicht eines Betroffenen. Wir stellen dar, wie hohe Autonomie und umfängliche Verantwortung eine völlig neue Arbeitsweise erfordern.
Pride & Prejudice: Teambildung & Motivation im agilen Umfeld
Im agilen Umfeld hat das Team die Arbeitsgemeinschaft ersetzt. Crossfunktional, T-Shaped und selbstorganisiert soll es sein. Was sich nach einer idealen Arbeitsumgebung anhört, kann langfristig trotzdem zu Frust und Motivationsverlust führen. Was können die Ursachen sein?
Im ersten Teil des Vortrags (Stolz) geht es um die Mechanismen rund um Teambildung. Im Großen sind das Bestimmung einer Teamvision und -Mission und die Ermittlung von gemeinsamen Werten. Im Kleinen ist es das Konzept der „Psychological Safety“, das allen erfolgreichen Teams gemeinsam ist. Außerdem wird mit Stoizismus eine Geisteshaltung vorgestellt, mit der jeder Einzelne aktiv sein teamorientiertes Handeln verbessern kann.
Es ist aber ein Vorurteil, wenn man glaubt, dass ein funktionierendes Team einmal zusammengestellt dauerhaft gut zusammenarbeitet. Daher werfen wir im zweiten Teil einen Blick auf den aktuellen Forschungsstand und die Historie von Motivation. Teilnehmer verstehen, was es mit extrinsischer und intrinsischer Motivation auf sich hat und welche Menschenbilder Taylorismus und die X-Y-Theorie propagieren. Wir gehen auf verschiedene evolutionäre Organisationsformen von Unternehmen ein und zeigen, wie gut die verschiedenen Motivationstheorien zu bestimmten Organisationsformen passen.
Abschließend bringen wir Stolz & Vorurteil zusammen: wir zeigen, wie in agilen Teams mit der individuell passenden Motivation langfristig erfolgreich zusammengearbeitet werden kann.
DevOps im Konzern: Autonomie vs Betriebssicherheit
Aus Sicht eines DevOps-Teams ist für eine hohe angestrebte Geschwindigkeit hohe Autonomie bei allen Architektur- und Implementierungsentscheidungen notwendig. Aus Sicht der DB Systel, die den stabilen IT-Betrieb der Deutschen Bahn sicherstellen soll, ist die Forderung nach Autonomie jedoch ein Risiko.
Zur Lösung dieses Konfliktes findet man daher in der Industrie häufig Ansätze, bei der Betriebseinheiten zentral betreute CI/CD-Pipelines bereitstellen. Während die mit dieser Lösung verbundene Automatisierung eine gute Kontrolle von Betriebsaspekten mit sich bringt, stellt die damit auch verbundene notwendige Standardisierung von Architekturaspekten häufig eine zu starke Einschränkung der Autonomie von DevOps-Teams dar.
In diesem Talk möchten wir darauf eingehen, wie die DB Systel ihren DevOps-Teams durch Verortung der Betriebsverantwortung in den DevOps-Teams eine optimale Autonomie gewährt und gleichzeitig die Risiken für Stabilität, Datenschutz und Compliance kontrolliert.
Wir geben Ihnen auch einen Einblick in den Alltag eines DevOps-Teams in der DB Systel aus Sicht eines Betroffenen. Wir stellen dar, wie hohe Autonomie und umfängliche Verantwortung eine völlig neue Arbeitsweise erfordern.
Und wer testet die Tests? - Mutationstesten mit PIT
Eine Testabdeckung von 50-80% ermöglicht es eine Codebasis wartbar zu halten. Refaktorisierungen sind dadurch sicherer durchführbar. Doch diese Sicherheit ist trügerisch. Denn wer garantiert, dass die Tests das richtige Testen? An dieser Stelle tritt eine "alte" Technik auf den Plan: Das Mutationstesten. Bereits 1971 vorgeschlagen, gewinnt es heute mit leistungsfähigen Multicore-Prozessoren immer mehr an Bedeutung. Der Vortrag zeigt die Leistungsfähigkeit dieser Technik am Beispiel der ausgereiften Bibliothek PIT. Mit dieser wurden Tests aus einem realen Projekt überprüft und deren Qualität erheblich gesteigert.
Type Script 3.x - Was war. Was kommt!
TypeScript ist in der heutigen JavaScript-Welt ein immer wieder auftauchender Bestandteil. Mit TypeScript 2.0 wurde der Grundstein gelegt, die Sprache endgültig in das bestehende JavaScript-Tooling mit npm zu integrieren. In dieser Livecoding-Session werden wegweisende Features vorgestellt. Darunter die immer bessere Control-Flow-Analyse zur Typinferenz als auch Non-nullable Types, Sprachkonstrukte für besseres OOP und ganz neue Typen wie never. Ein weiteres Thema sind die ESNext-Features, wie Async/Await und Decorators, die schon heute nach ES3/ES6 transpiliert werden können.
Ist das Softwarearchitektur oder kann das weg?
Softwarearchitektur ist in aller Munde. Doch was ist diese Disziplin über die jeder gerne spricht? Die Antwort ist selbst in der Literatur nicht eindeutig. Fest steht: Sie ist immer vorhanden. Entweder implizit oder explizit. Meistens wird aber nur die technische Seite der Softwarearchitektur betrachtet. Dabei ist sie vielseitiger als es den Anschein hat. In diesem Vortrag werden überraschende Eigenschaften von Softwarearchitektur vorgestellt. Dabei wird bewusst auf weniger im Fokus stehende Themen wie zum Beispiel Risikomanagement eingegangen. Diese Eigenschaften können genutzt werden, um die Kommunikation mit Stakeholdern zu verbessern und ein Softwareprojekt effizient zu steuern.
Mehr von Johannes Dienst (20)
Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf
Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf
The Future of UI Testing - Challenges in UI Automation
The Future of UI Testing - Challenges in UI Automation
Managed Cloud to GitOps: Deploying Several Client Clusters
Managed Cloud to GitOps: Deploying Several Client Clusters
Stoizismus - Praktische Philosophie für den IT-Alltag (Pecha Kucha)
Stoizismus - Praktische Philosophie für den IT-Alltag (Pecha Kucha)
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
Managed Cloud to GitOps: Deploying Several Client Clusters
Managed Cloud to GitOps: Deploying Several Client Clusters
Griechische Philosophie für moderne Softwareentwicklung
Griechische Philosophie für moderne Softwareentwicklung
Lessons Learned: arc42 in einem echten DevOps Team
Lessons Learned: arc42 in einem echten DevOps Team
Work efficiently with Architecture Decision Records
Work efficiently with Architecture Decision Records
The Dev, The Ops, And The Team: What works in a DevOps Team?
The Dev, The Ops, And The Team: What works in a DevOps Team?
Spock vs Supermutanten: Spezifikationstesten trifft Mutationstesten
Spock vs Supermutanten: Spezifikationstesten trifft Mutationstesten
Everything as Code: Pipeline, Infrastructure, Configuration, Documentation
Everything as Code: Pipeline, Infrastructure, Configuration, Documentation
DevOps im Konzern - Autonomie vs Betriebssicherheit (Continuous Lifecycle)
DevOps im Konzern - Autonomie vs Betriebssicherheit (Continuous Lifecycle)
Pride & Prejudice: Teambildung & Motivation im agilen Umfeld
Pride & Prejudice: Teambildung & Motivation im agilen Umfeld
DevOps im Konzern: Autonomie vs Betriebssicherheit
DevOps im Konzern: Autonomie vs Betriebssicherheit
Und wer testet die Tests? - Mutationstesten mit PIT
Und wer testet die Tests? - Mutationstesten mit PIT
Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qualitätsszenarien - DevDay Dresden
- 1. Johannes Dienst (@JohannesDienst) Leichtgewichtige Softwarearchitektur Mit Architecture Decision Records und Qualitätsszenarien
- 2. Johannes Dienst (@JohannesDienst)3 Was ist eine Entwurfsentscheidung? Code-Ebene Bubble-Sort statt Merge-Sort Solution-Ebene Circuit Breaker Applikations-Ebene Hystrix
- 4. Akzeptieren oder ändern Johannes Dienst (@JohannesDienst)5
- 5. Johannes Dienst (@JohannesDienst)6 https://arc42.de/
- 7. Softwarearchitektur im Agilen Kontext Johannes Dienst (@JohannesDienst)8
- 8. Architecture Decision Record (ADR) Johannes Dienst (@JohannesDienst)10 Titel Kontext / Hintergrund Alternativen Entscheidung Status Konsequenz(en)
- 9. Johannes Dienst (@JohannesDienst)11 ADR-3: Staging-Umgebung für CMS Kontext Es wird eine Lösung gesucht um Skalierbarkeit für das gesamte System sicherzustellen. Alternativen Cluster-Lösung • Betrieb des CMS im Cluster Push Publishing • Verwendung für mehrere Stages Entscheidung Wir verwenden kein Push-Publishing bzw. verschiedene Staging Umgebungen. Status BESCHLOSSEN Konsequenz Änderung der System-Architektur notwendig • Abbau der beiden Public Instanzen • Dekonfigurieren von Push Publishing Es wird keine Umgebung zur Verfügung gestellt, auf der Content gepushed wird
- 11. Qualitätsattribute (ilities) - ISO 25010 Johannes Dienst (@JohannesDienst)13 Functional Suitability Software Product Quality Usability Security Performance Efficiency Maintainability Compatibility Reliability Portability
- 12. Qualitätsattribute (Ilities) – Im Detail Johannes Dienst (@JohannesDienst)14 Usability • Appropriatness Recognizability • Learnability • Operability • User Error Protection • User Interface Aesthetics • Accessibility
- 15. Johannes Dienst (@JohannesDienst)17 Und dann?
- 16. Qualitätsszenarien – Allgemeiner Fall Johannes Dienst (@JohannesDienst)18 Mess- kriteriumArtefakt Umgebung Stimulus Antwort Quelle
- 17. Qualitätsszenarien – Konkreter Fall Johannes Dienst (@JohannesDienst)19 Keine DowntimeProzess Normal- betrieb Quelle: Heartbeat Stimulus: Server unerreichbar Antwort: Cockpit informieren
- 18. Zusammenbringen mit ADRs Johannes Dienst (@JohannesDienst)22 Icons made by Freepik and Smashicons from www.flaticon.com Qualitätsattribute Qualitätsszenarien ADR
- 19. Learnings Johannes Dienst (@JohannesDienst)23 ADRs als probates Mittel Entwurfsentscheidungen zu dokumentieren Qualitätsszenarien als Kommunikationsmittel für alle Stakeholder Diese sind anfangs schwer zu formulieren
- 20. Wie geht es weiter? Johannes Dienst (@JohannesDienst)24 Docs as Code mit AsciiDoc Lightweight ADRs im Code Qualitätsszenarien als ausführbare Dokumentation
- 21. Welche zwei Fragen sind noch offen? Johannes.Dienst@DeutscheBahn.com @JohannesDienst