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

DBAs

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

Proxy

Proxy

ReplicationServiceD/R

Build Replica


Verteilte Infrastrukur - Narrow cloning

Any file typeAny number of filesAny size of history

Art

Code

Core

iOS

Win

Tests

Shared Helix

Code

Core

iOS

Tests

Jill’sHelix repo

Code

Core

Win

Tests

John’sHelix repo


Verteilte Infrastruktur - Shallow cloning

#1

#2

#3

#4

#1

#2

#3

shared local

#3

#2

#4

#3

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: [email protected]

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...