End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner

Größe: px

Ab Seite anzeigen:

Download "End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at"

Manfred Stieber
vor 8 Jahren
Abrufe

1 End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner September 2015

2 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile Development Agile Coding Practices DVCS Continuous Integration Continuous Delivery / DevOps Agiles Projekt Managment

Development Agile Coding Practices DVCS Continuous

3 Agile ist Mainstream Rascher auf neue Anforderungen reagieren Feedback beschleunigen Fortschritt visualisieren Risiko reduzieren Time to Market reduzieren

4 SCRUM ist Mainstream Organisatorischer Rahmen Terminologie Rollenmodell Backlog - klare Prioritäten Hilft Probleme aufzuzeigen Ist bewusst unvollständig

5 Agile Praktiken Automatisierte Tests - TDD Agile Coding Pracices Continuous Integration Continuous Delivery Agile Estimating and Planning Agile Portfolio Management

6 Mainline Model hotfix1! release-1.0 Release-1.1! mainline develop feature1 feature2 zend_webapp

7 Branch Based Workflows Regeln für die Erzeugung von Branches Regeln für das Mergen von Branches Regeln für Continuous Integration Namenskonvention für Branches Integration von Code Reviews Gemeinsames Verständnis

für Continuous Integration Namenskonvention für

8 Branch Based Workflow (git-flow) Feature Branches Entwicklung Release Branches Hotfixes Master Zeit Neues Feature A Neues Feature B Bugfix in Entwicklung integrieren Problem in Produktion Hotfix 0.2 Tag 0.1 Tag 0.2 Von diesem Punkt an bedeutet nächste Release > 1.0 Beginn Release- Branchs 1.0 Nur Bugfixes! Bugfixes aus dem Release Branch können kontinuierlich in den Entwicklungszweig zurückgemerget werden Tag 1.0

2 Tag 0.1 Tag 0.2 Von diesem Punkt an bedeutet nächste Release > 1.0 Beginn Release- Branchs 1.

9 Kritik an Feature Branches Je länger ein Feature Branch existiert, desto schwieriger wird der Merge Je mehr Änderungen ein Feature Branch enthält, desto wahrscheinlicher bricht ein Merge am Ende den Build Lokale Feature Branches verzögern Feedback Arbeit in parallelen Feature Branches erschwert Refaktorisierung

desto wahrscheinlicher bricht ein Merge am Ende den Build Lokale Feature

10 Automatische Plan Branches

11 Trunk Based Development release-1.0 release-1.1! trunk (mainline) feature1 hotfix feature3 feature4 Verwendung von kurzlebigen Feature Branches möglich. Reviews vor dem Commit/Merge in den TRUNK sind erwünscht.

12 Trunk Based Development TRUNK based bedeutet nicht SVN based TRUNK = Mainline Alle Entwickler arbeiten im TRUNK Auch Bugs werden im TRUNK behoben Erstellung von Release Branches Kein Code Freeze

13 Trunk Based Development Möglichst rasche und häufige Integration Erfolgreich eingesetzt in großen Teams Es ist wichtig, dass die Software immer auslieferbar bleibt Feature Toggles Branch by Abstraction

14 Agile - Mainline Check Haben Sie eine klare Branching Strategy Branch/Trunk Based? Werden Reviews/Pull Requests verwendet? Verzögern unvollständige Features eine Release oder den Abschluss eines Sprints? Werden Produkt-Varianten im Code oder der Konfiguration abgebildet?

Verzögern unvollständige Features eine Release oder den Abschluss

15 Continuous Integration

16 Continuous Integration Check Häufigkeit Automatisierungsgrad Struktur: Plan - Stage - Job - Task Umfang: Binaries, Datenbank, Konfiguration Durchlaufzeit Reproduzierbarkeit

17 Water-SCRUM-Fall Agile Software Entwicklung Portfolio Management und Deployments folgen weiterhin klassischen Ansätzen Auslieferung in die Produktion erweitern - Continuous Delivery Priorisierung am Ende jedes Sprints und bei jeder Release - Agile Portfolio Management

in die Produktion erweitern - Continuous Delivery Priorisierung am

18 Continuous Delivery Check Was ist der Ausgangspunkt für Continuous Delivery Continuous Integration Source Code Checkout Static Code Analysis Automated Tests Compilation Packaging

19 Database Structure Database Content Database Migrations Installable Software Executables / Libraries Packages Installers Deployment Continuous Delivery Check

20 Häufige Probleme Nicht alle Änderungen an Abhängigkeiten lösen einen Build aus. Die Datenbank wird nicht vollständig verwaltet. Builds sind nicht reproduzierbar. Status von Builds/Deployments ist nicht für alle Stakeholder klar erkennbar.

21 Deployment Typen Personal Nur unser Guru versteht das System und kann es aufsetzen Manual Es gibt genug Dokumentation, dass das System ohne unseren Guru aufgesetzt werden kann. Scripted Es gibt Scripts mit denen unser System aufgesetzt werden kann Defined Wir nutzen IT Automation um den Zustand des Systems zu definieren und laufend zu überprüfen bzw. sicherzustellen. Defined Deployments setzen IT-Automation, Traceability und Disziplin voraus.

22 IT-Automation mit Puppet 1! Define. 4! 2! Simulate. Report. 3! Enforce.

23 Modules Modulare Deployments with Puppet Database Web Server Application Server Security 1! Module definieren Deployments!!!!!!!!!!!!!Via Puppet Dashboard Custom External Source!!!!!!!!!!!! (CMDB,!LDAP,!etc.)! 2! Zuordnung von Modulen zu Rollen Web Servers Database Servers Application Servers 3! Wiederverwendbare modulare Konfigurationen

24 Continuous Deployment with Bamboo

25 Continuous Deployment mit Bamboo

26 Agiler Entwicklungs Ablauf Video: Atlasian Integrated Development Workflow -

27 Agiles Portfolio Management Never understimate the Backlog Priorisierung am Ende jedes Sprints und bei jeder Release Anpassung an geänderte Anforderungen erwarten What-if Szenarien nutzen

28 JIRA Portfolio

29 JIRA Portfolio

30 End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner

Ähnliche Dokumente

AGILE APPLICATION LIFECYCLE MANAGEMENT IM ATLASSIAN ECOSYSTEM

AGILE APPLICATION LIFECYCLE MANAGEMENT IM ATLASSIAN ECOSYSTEM 09.07.2015 NATALIE WENZ JAN GERTGENS Vorstellung Natalie Wenz Studium Medieninformatik an der Hochschule Reutlingen mit Abschluss als Master