Verteilte Entwicklung Herausforderung, Betrachtungen und ... · Continuous Integration / Delivery...

Verteilte EntwicklungHerausforderung, Betrachtungen und Lösungansätze

Embedded Computing Conference 2016Winterthur, Schweiz31 Mai 2016

Philip Zollinger

1 - © EVOCEAN www.evocean.com

Administrativer Aufwand für verteilte Entwicklungsnimmt überproportional zu

Zusammenarbeit nimmt ständig zu

Globalisierung nimmt zu

Entwicklungs-Takt und -Schnelligkeit nimmt ständig zu

Zugriff auf korrekte „Entwicklungsdaten“ Ressourcen,ortsunabhängig ist kritisch

Fokus auf Kernkompetenzen ist wichtig

Sicherheitsaspekte

Stabile, robuste „Infrastruktur“ immer wichtiger

Flexibilität / Agilität nimmt einen immer höherenStellenwert

Entwickler müssen einfach zu den Information kommen

Was bewegt mich darüber zu sprechen

EVOCEAN – www.evocean.com

Configuration Management

Model Driven Development

RequirementsManagement

Lean & Agile

Quality Management

Continuous Improvement

Improving Software-, Product-and Systems Engineering.

Internet of ThingsThreat Detection

SORRY – Meine Folien sind in deutsch und englisch …

Wachstum

Akquisition

Zusammenarbeit mit Partner

Zugriff auf Ressourcen

Flexibilität von Arbeitsmodellen

Innovativ bleiben

Lokal sein auch wenn global

Treiber einer verteilten Entwicklung

Agilitätschneller, Feedback, adaptieren

Continuous Integration / Deliverybraucht „zentrale“ Infrastruktur

DevOps / „DevProd“Kleine Schritte - Zusammenarbeit zwischenEntwicklung und Operations / bzw.Produktion

Collaborative Engineering über mehrereDisziplinen (Systems Engineering)

IoT , Industrie 4.0 wird dies verstärken

Einfluss von aktuellen TrendsAgilität – Continuous Delivery – DevOps – Collaborative Eng.

https://www.zukunftsinstitut.de/dossier/megatrends/

Herausforderungunterschiedliche Stakeholder Anforderungen

DeveloperProductivity

Non-TechnicalContributorProductivity

ProductionNeeds

Corporate Goals

Qualityand

Security

Was braucht die EntwicklungAus Entwicklersicht

Einfacher Zugriff auf Daten

Klare Kommunikation von Produktstrategie, Aufgaben und Prioritäten

Möglichst schneller Feedback auf Arbeit

Einfache Zusammenarbeit im Kontext mit anderen

Zufriedene Entwickler sind sehr wichtig für Produktivität

Was braucht die Entwicklungaus IT Adminsicht

Schlanke Admin der Infrastruktur

Sicherstellung der Verfügbarkeit der Infrastruktur und Zugriff

Sie will sicherstellen dass User immer arbeiten können

Monitoring zwecks schnellem agieren bei Problemen

Hybrid Cloud Strategie – möglichst offene Standards

Was braucht die Entwicklungaus Entwicklungsleitungssicht

Sichere robuste Infrastruktur, damit die Entwicklung arbeiten können – hoher SLA.- klare HA/DR Strategie

Klare Produkt Linien, bzw. Plattform Strategie -> Wiederverwendung

Klare System- / Produkt- / Software-Entwicklungs Lifecycle Strategie, Change Management

Schlanke Prozesse die keinen unnötigen Ballast haben

Raum für Innovation, klare Prioritäten, Ziele

Automatisation wo sinnvoll

Möglichst einfach skalierbar Infrastruktur, flexibles Ressourcenplanung

Schlankes zielorientiertes Reporting.

Klare transparente Sicht „wo“ die Projekte stehen, was fehlt …

Verbesserungsinitiativen: Schnelligkeit, Produktivität, Zusammenarbeit

Was braucht die Entwicklungaus Unternehmersicht

Schutz von IP / Daten

Möglichst einfach skalierbare Infrastruktur

Konformität bezüglich gesetzlichen Regulatorien (Compliance / Standards)

Schlankes zielorientiertes Reporting

GL will zu jedem Zeitpunkt wissen „wo“ die Projekte sind.

Produkt (Portfolio) / Markt / Innovation-Strategie

Verbesserungs-Initiativen bezüglich Time to Market, Innovation, Produktivität

Was wir öfters antreffen ….

Repository sprawl• Teams use their own stores• SCM tool limits force artificial splits• Siloes, poor visibility, no sharing, low security, broken builds

Inefficient CI / DevOps• Little/no CI• Slow, broken builds• Multiple security models

Poor scaling for distributed teams• Add-ons needed• Complex setup, on-going management• Poor performance

Techniken

Lean, agile Prinzipien

Requirements Engineering

Klare Produktlinienstrategie , bzw. Platformstrategie zwecks Wiederverwendung

Versionieren, Varianten Management über alle ArtefakteKeywords „Streams“ bzw. „global Configurations“

Visual Management – Boards

Collaboration im Kontext– Reviews, Konversationen über Artifakte

Systems Engineering – Model Based Systems Engineering, Model Driven Development

Continuous Integration / DevOps / Continuous Delivery(Automated Testing: PreComit, PostComit)

AssetStorage

Vision – Single Source of Truth

Asset Storage as “Nerve Center” for entire Organization

Release ManagementOperations

Systems EngineeringQuality Assurance

Development

Production state flags

Automated Installs

Operation scripts

Automated Deploymentsfor dev/QA/production

Source code repository

Logging for all automation

Historical reportingrepository

Puppet manifests

Puppet logs

SAE scripts

Oracle scripts

SQL server scripts

SQL server packages

QA application configurations

All installs taken from Perforce

Source Code Repository

Unit testing configurations

Development tools/scripts

Drawings etc.

MonoRepo

Lösungsvision

Digital Asset Storage

PlanningTask Man.

Require-ments

Develop-ment

QualityAssurance

Deploy-ment

Maint-enance

Collaboration - Realtime Reporting - Traceabilty

Verteilte Infrastruktur (Digital Storage)

Versioning Service

ReplicationServiceD/R

Build Replica

Verteilte Infrastrukur - Narrow cloning

Any file typeAny number of filesAny size of history

Shared Helix

Jill’sHelix repo

John’sHelix repo

Verteilte Infrastruktur - Shallow cloning

shared local

clone –m 2

CSODevOps

Infrastruktur optimiert für Continuous Delivery

Trunk Based Development Continuous Integration

Infrastructure as Code Continuous Testing

Open Standard to share data more easily

Better integration between tools

Flexible, robust connections

Exposing more data

Many contributors from many industires

Simple specifications as a commonbaseline which can be extended

Inspired by the web and linked datastandards

Access with RESTful services throuh URL

Challenge: Tool IntegrationOpen Service Lifecycle Management (OSLC)

http://www.oasis-oslc.orghttp://www.open-services.net

Engineering teams are meeting the challenge withContinuous Engineering platform

Requirements

Design

Tracking, planning, change managementConfiguration management

Reporting and analysis

Validation &Verification

Verteilte Entwicklung: Streams

Enforce trunk-based development principlesBuilt-in tracking of parent-child relationshipsAutomate trunk integration,everyone in syncTask streams for per-task branchingQuick context-switching

Component-based development (CBD)

• Complex project broken down into smaller independentcomponents

• Each component has its own lifecycle• There can be multiple releases

• CBD assembles components in configurations

Component-based development

• Streams are the versionedconfigurations of components

import radio/... //Comp/Radio/Radio.rel2/...

import satnav/... //Comp/SatNav/main/...@lastgood

import display/... //Comp/Display/dev1/...

• Streams are the versionedconfigurations of components

Collaboration in Context - Code Review &Conversations

Fast, rich code reviewConversations & history stored with thecodeGroup approvals/quoraCI Integration

Visual Management – Developer ViewSee what are my tasks , who is working on what

Visual Management – Product Owner ViewCreate Product Roadmaps

Visual Management – Program ManagerDefine Programs and Business Intiatives

Software-Entwicklung für CAM und CNC.

3 Standorte in der Schweiz.

Ca. 30 Personen

Case Study 1 - kleine FirmaMCS Engineering – Überblick

Aufrechterhaltung von 2 Entwicklungsinfrastrukturen.

Internetverbindungn zwischen Standorten bezüglich uptime nicht kritisch.

Da Artefakte zum Teil gross /bzw Menge sollend diese lokal zur Verfügung stehen.(Internetverbindung nicht genügend performant)

Kein Budget für Dienstleistungen, Trainings

Praxisbeispiel 1 – Kleine FirmMCS Engineering - Herausforderung

Versionierungssystem mit integrierter Unterstützung von verteilter Infrastruktur.

Adminaufwand von 2tem Standort gleich Null

Adminaufwand von Hauptstandort vernachlässigbar klein.

Vorteile gegenüber Opensource

1 Produkt deckt mehrere Anforderungen an Infrastruktur.

Adminaufwand sehr viel kleiner (deckt bei weitem Lizenzkosten)

Zusätzlicher Benefit:Exzellenter Produktsupport

Praxisbeispiel 1 – Kleine FirmaMCS Engineering – Lösungsansatz und Resultate

mcs engineering - Zitate

„Wir arbeiten zunehmend in verteilten Teams an verschiedenen Standorten. Daher brauchtenwir eine Lösung, mit der mehrere Personen gleichzeitig an einem Projekt arbeiten können –

effizient und Standort unabhängig“

“Es ist sehr einfach, einen Proxy-Server für das Arbeiten mit geographisch verteilten Teamsaufzusetzen und zu betreiben. Auch der Download von Daten ist ein Kinderspiel. Wir waren

erstaunt, wie viel Zeit wir einsparen konnten“

Eric Gutmann - Projektleiter

Firma hatte damals 6 (heute ca. 10)Entwicklungstandorte, gewachsen durchAcquisitionen

Internetverbindungn zwischen Standortenbezüglich uptime zum Teil kritisch (zumBeispiel 1 Standort in Lahore – Pakistan).

Verschiedene Tools im Einsatz fürVersionierung: Git, Subversion, Clear-Caseund andere …und für Collaboration: Gerrit,Bitbucket(Stash)

Entwicklungen über mehrere Standorte:„Cross Team“ und „Cross-Product“

Ca. 270 auf 6 Standorten

Praxisbeispiel 2 – Mittelgrosse Firmau-blox - Herausforderung

Versionierungs-/Kollaborationssystem mitunterstützung von verteilter Infrastruktur, inkl.Aufrechterhaltung von verteilten Standorten beiInternetverbindungsabbruch.

Einführung von „Stream“ Philosophie fürvereinfachte Zusammenarbeit.

Zentraler Continous Integration Server (Jenkins)mit „Edge Server“ zwecks Performance –Lastverteilung.

Collaboration/Review à la Facebook um Artefactmit Pre-Comit und Post-Comit Review integration.

Architektur von Lösungsansatz hat keinenEinfluss auf Kosten (flat cost model per humanuser)

Zentraler Server in Thalwil

Nur Standard Hardware für Server

Praxisbeispiel 2 – Mittelgrosse Firmau-blox AG – Lösungsansatz

Bild vonhttp://de.slideshare.net/perforce/perforce-on-tour-2015-optimising-the-developer-pipeline-at-ublox

Ca. 350 User, > 6 Standorte

Seit Einführung 3 Tage Trainings und 6Tage Workshops TOTAL.

Adminaufwand ca. 0.5 Personen.

Vorteile gegenüber anderen Lösungen.

1 Produkt deckt mehrere Anforderungen anInfrastruktur.

Skalierung, Unterstützt hohe Anforderungan Performance von ContinuousIntegration.

Zusätzlicher Benefit: ExzellenterProductsupport

Praxisbeispiel 2 – Mittelgrosse Firmau-blox AG – Resultate - heute

Bild vonhttp://de.slideshare.net/perforce/perforce-on-tour-2015-optimising-the-developer-pipeline-at-ublox

u-blox

„Perforce bietet uns die Leistungsfähigkeit, die wir für jedes Element unserer hochgradig verteiltenUmgebung benötigen. Das System ist in der Lage, mit grossen binären Assets umzugehen,

wodurch wir Dateien unabhängig von Typ oder Größe versionieren können", fügt Vesnaver an.„Wir waren beeindruckt, wie einfach die Installation ablief und wie gut sich die Lösung in unsere

bestehende IT-Umgebung einfügt.„

„Perforce erfüllt alle unsere strengen Kriterien, von denen wir die Wahl unseres neuenVersionsmanagementsystems abhängig gemacht haben. Der Replikations- und Proxyserver vonPerforce ermöglicht uns eine herausragende Remote-Site-Performance ganz ohne zusätzliche

Kosten.“

„Perforce unterstützt von allen Systemen, die wir evaluiert haben, die Funktionalitäten für dasVerzweigen und Zusammenführen von Entwicklungspfaden am besten. Der feingranulare und

berechtigungsbasierte Dateizugang der Lösung ermöglicht uns eine sehr gute Kontrolle über dieNutzung, sowohl auf Branch- bzw. Repository-Ebene, wie auch auf Ebene der einzelnen Dateien.

Das Konfigurieren von Berechtigungen und der Sicherheitsmechanismen erfüllten ebenfallsunsere Anforderungen.„

Fabio Vesnaver – Manager of Strategic Purchasing and Partnerships

Outlook: Hybrid Cloud und PAAS

CloudMuss hybride Cloud Strategie unterstützen

Local Cloud

Dedicated Cloud Public Cloud

Cloud Based Developmentzum Beispiel Bluemix

The Bluemix Watson OoT Foundation is one of (many) services inside Bluemix thatallows you to rapidly build server based Application

With the the IBM IoT Foundation for example we can rapidly establish a cloud basedMQTTBroker, connect Devices and Applications

IBM Watson IoT Foundation

Infrastruktur muss verteilte Entwicklungunterstützen.

Team hat Einfluss auf Vorgehen.

Immer auf Wert achten und möglichstschnelles Feedback.

Collaborative Engineering Techniquen,Model basiertes Systems Engineering,Archtektur uancen von verteilterEntwicklung nutzen.

Mit den richtigen Werkzeugen kannverteilte Entwicklung sehr gut ablaufen.

Ständige Verbesserung hilft:Kleine Schritte zum Erfolg.

Schluss BemerkungenVerteilte Entwicklung als Chance nehmen.

THANK YOU

Philip ZollingerEVOCEANMobile: +41 78 800 03 88Email: Philip.Zollinger@evocean.com

linkedin.com/philipzollinger

xing.com/philipzollinger

www.facebook.com/evocean

@philzol

@EVOCEAN_GmbH

Verteilte Entwicklung Herausforderung, Betrachtungen und ... · Continuous Integration / Delivery...

Documents

Transcript of Verteilte Entwicklung Herausforderung, Betrachtungen und ... · Continuous Integration / Delivery...

Effizente Entwicklung für verteilte Projekte

Unzeitgemässe Betrachtungen

Verteilte Datenbanken

Verteilte Snapshots Vortrag im Rahmen des Seminars Parallele und verteilte Programmierung Matthias Bedarff.

Verteilte Systeme 2012

Herausforderung im Innovationsmanagement von …...2015/11/30 · Herausforderung Innovationsmanagement_PFI_20151130.pptx Herausforderung im Innovationsmanagement von Unternehmen

Hallauer, Ottokar Grundsätzliche Betrachtungen über den ...

5.7.2006Heidelberger Investoren-Runde Goethes Geschäfte Historische Betrachtungen.

Herausforderung Mitarbeiterqualifizierung

Grundlagen Rechnernetze und Verteilte Systeme

Verteilte Versionskontrolle in der Praxis

Verteilte Simulation und Emulation von ...

Betrachtungen zu Wortakrobatik, Guerilla Marketing und ...onomasticafelecan.ro/iconn3/proceedings/4_24_Turcanu_Rodica... · Betrachtungen zu Wortakrobatik, Guerilla Marketing und

Verteilte Web-basierte Systeme Part VI · Verteilte Web-basierte Systeme Vorlesung SS2006 > > /> /> / > />

Illik verteilte systeme

Verteilte Systeme Dozent: Clemens Düpmeier

Mobile und verteilte Systeme

Verteilte Web-basierte Systeme Part II · Verteilte Web-basierte Systeme Vorlesung SS2006 © 1999-2006 by Dr.-Ing. M. Gaedke 1 Verteilte Web-basierte Systeme – SS 2006 Verteilte

Philotomys Betrachtungen - System Matters

Praktikum Datenbanken und verteilte Systeme SoSe2007 · Praktikum Datenbanken und verteilte Systeme Jadex Einführung SoSe 2013 Kai Jander 5. Aug. 2012 Verteilte Systeme und Informationssysteme