Continuous Delivery

Der pragmatische Einstieg
 
 
dpunkt (Verlag)
  • 2. Auflage
  • |
  • erschienen am 31. März 2016
  • |
  • 282 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-86491-931-2 (ISBN)
 
Continuous Delivery ermöglicht es, Software viel schneller und mit wesentlich höherer Zuverlässigkeit in Produktion zu bringen, als es bisher möglich war. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen reproduzierbaren, risikoarmen Prozess für die Bereitstellung neuer Releases bietet. Dieses Buch macht Sie mit dem Aufbau einer Continuous-Delivery-Pipeline vertraut und erklärt, welche Technologien Sie dazu einsetzen können.

Dabei lernen Sie u.a. folgende Themen kennen:
Infrastruktur-Automatisierung mit Chef, Docker und Vagrant
Automatisierung von Builds und Continuous Integration
Akzeptanztests, Kapazitätstests, exploratives Testen
Einführung von Continuous Delivery im Unternehmen
Continuous Delivery und DevOps
Auswirkungen auf die Softwarearchitektur

Als praktisches Beispiel wird ein konkreter Technologie- Stack vorgestellt. Zahlreiche Aufgaben und Vorschläge für weitergehende Experimente laden Sie darüber hinaus zur praktischen Vertiefung des Themas ein.

Nach der Lektüre können Sie abschätzen, welche Vorteile Continuous Delivery konkret bietet, und Sie verfügen über das nötige Handwerkszeug, um Continuous Delivery in Ihrem eigenen Arbeitsumfeld zu etablieren.

Die Neuauflage wurde in Bezug auf Werkzeuge wie Docker, Jenkins, Graphite und den ELK-Stack aktualisiert. An neuen Themen sind Docker Compose, Docker Machine, Immutable Server, Microservices und die Einführung von Continuous Delivery ohne DevOps hinzugekommen.
aktualisierte und erweiterte Auflage
  • Deutsch
  • Heidelberg
  • |
  • Deutschland
  • 18,61 MB
978-3-86491-931-2 (9783864919312)
weitere Ausgaben werden ermittelt
Eberhard Wolff beschäftigt sich seit vielen Jahren mit Softwareentwicklung und -architektur. Er ist Autor zahlreicher Fachartikel sowie Bücher und regelmäßiger Sprecher auf internationalen Konferenzen. Außerdem ist er im Programmkomitee verschiedener Konferenzen vertreten. Er ist Fellow bei der innoQ.
Continuous Delivery und die Auswirkungen hat er in verschiedenen Projekten in unterschiedlichen Rollen kennen gelernt. Der Ansatz verspricht, die Produktivität der IT-Projekte erheblich zu erhöhen, und hat Auswirkungen auf das Vorgehen, aber auch auf die Architektur und die Technologien. Daher lag es für ihn auf der Hand, dieses Buch zu schreiben.
1 - Inhaltsverzeichnis [Seite 5]
2 - 1 Einleitung [Seite 11]
2.1 - 1.1 Überblick über Continuous Delivery und das Buch [Seite 11]
2.2 - 1.2 Warum überhaupt Continuous Delivery? [Seite 12]
2.3 - 1.3 Für wen ist das Buch? [Seite 15]
2.4 - 1.4 Neu in der 2. Auflage [Seite 15]
2.5 - 1.5 Übersicht über die Kapitel [Seite 17]
2.6 - 1.6 Pfade durch das Buch [Seite 18]
2.7 - 1.7 Danksagung [Seite 20]
3 - 2 Continuous Delivery: Was und wie? [Seite 23]
3.1 - 2.1 Was ist Continuous Delivery? [Seite 23]
3.2 - 2.2 Warum Software-Releases so kompliziert sind [Seite 23]
3.3 - 2.3 Werte von Continuous Delivery [Seite 24]
3.4 - 2.4 Vorteile von Continuous Delivery [Seite 27]
3.4.1 - 2.4.1 Continuous Delivery für Time-to-Market [Seite 27]
3.4.2 - 2.4.2 Continuous Delivery zur Risikominimierung [Seite 30]
3.4.3 - 2.4.3 Schnelleres Feedback und Lean [Seite 33]
3.5 - 2.5 Aufbau und Struktur einer Continuous-Delivery- Pipeline [Seite 34]
3.6 - 2.6 Links & Literatur [Seite 38]
4 - 3 Infrastruktur bereitstellen [Seite 39]
4.1 - 3.1 Einleitung [Seite 39]
4.2 - 3.2 Installationsskripte [Seite 41]
4.3 - 3.3 Chef [Seite 44]
4.3.1 - 3.3.1 Technische Grundlagen [Seite 47]
4.3.2 - 3.3.2 Chef Solo [Seite 54]
4.3.3 - 3.3.3 Chef Solo: Fazit [Seite 56]
4.3.4 - 3.3.4 Knife und Chef Server [Seite 56]
4.3.5 - 3.3.5 Chef Server: Fazit [Seite 61]
4.4 - 3.4 Vagrant [Seite 61]
4.4.1 - 3.4.1 Ein Beispiel mit Chef und Vagrant [Seite 63]
4.4.2 - 3.4.2 Vagrant: Fazit [Seite 65]
4.5 - 3.5 Docker [Seite 65]
4.5.1 - 3.5.1 Dockers Lösung [Seite 66]
4.5.2 - 3.5.2 Docker-Container erstellen [Seite 69]
4.5.3 - 3.5.3 Beispielanwendung mit Docker betreiben [Seite 71]
4.5.4 - 3.5.4 Docker und Vagrant [Seite 73]
4.5.5 - 3.5.5 Docker Machine [Seite 76]
4.5.6 - 3.5.6 Komplexe Konfigurationen mit Docker [Seite 78]
4.5.7 - 3.5.7 Docker Compose [Seite 80]
4.6 - 3.6 Immutable Server [Seite 83]
4.7 - 3.7 Infrastructure as Code [Seite 84]
4.8 - 3.8 Platform as a Service (PaaS) [Seite 87]
4.9 - 3.9 Umgang mit Daten und Datenbanken [Seite 89]
4.10 - 3.10 Fazit [Seite 92]
4.11 - 3.11 Links & Literatur [Seite 93]
5 - 4 Build-Automatisierung und Continuous Integration [Seite 97]
5.1 - 4.1 Überblick [Seite 97]
5.2 - 4.2 Build-Automatisierung und Build-Tools [Seite 98]
5.2.1 - 4.2.1 Ant [Seite 100]
5.2.2 - 4.2.2 Maven [Seite 100]
5.2.3 - 4.2.3 Gradle [Seite 105]
5.2.4 - 4.2.4 Weitere Build-Tools [Seite 108]
5.2.5 - 4.2.5 Das geeignete Tool auswählen [Seite 109]
5.2.6 - 4.2.6 Links und Literatur [Seite 110]
5.2.7 - 4.2.7 Experimente und selber ausprobieren [Seite 110]
5.3 - 4.3 Unit-Tests [Seite 111]
5.3.1 - 4.3.1 »Gute« Unit-Tests schreiben [Seite 113]
5.3.2 - 4.3.2 TDD - Test-driven Development [Seite 115]
5.3.3 - 4.3.3 Clean Code und Software Craftsmanship [Seite 116]
5.3.4 - 4.3.4 Links und Literatur [Seite 116]
5.3.5 - 4.3.5 Experimente und selber ausprobieren [Seite 117]
5.4 - 4.4 Continuous Integration [Seite 117]
5.4.1 - 4.4.1 Jenkins [Seite 118]
5.4.2 - 4.4.2 Continuous-Integration-Infrastruktur [Seite 124]
5.4.3 - 4.4.3 Fazit [Seite 125]
5.4.4 - 4.4.4 Links und Literatur [Seite 126]
5.4.5 - 4.4.5 Experimente und selber ausprobieren [Seite 126]
5.5 - 4.5 Codequalität messen [Seite 128]
5.5.1 - 4.5.1 SonarQube [Seite 130]
5.5.2 - 4.5.2 Links und Literatur [Seite 132]
5.5.3 - 4.5.3 Experimente und selber ausprobieren [Seite 132]
5.6 - 4.6 Artefakte managen [Seite 133]
5.6.1 - 4.6.1 Integration in den Build [Seite 135]
5.6.2 - 4.6.2 Weiterreichende Funktionen von Repositories [Seite 137]
5.6.3 - 4.6.3 Links und Literatur [Seite 137]
5.6.4 - 4.6.4 Experimente und selber ausprobieren [Seite 137]
5.7 - 4.7 Fazit [Seite 138]
6 - 5 Akzeptanztests [Seite 141]
6.1 - 5.1 Einführung [Seite 141]
6.2 - 5.2 Die Test-Pyramide [Seite 141]
6.3 - 5.3 Was sind Akzeptanztests? [Seite 145]
6.4 - 5.4 GUI-basierte Akzeptanztests [Seite 149]
6.5 - 5.5 Alternative Werkzeuge für GUI-Tests [Seite 155]
6.6 - 5.6 Textuelle Akzeptanztests [Seite 157]
6.7 - 5.7 Alternative Frameworks [Seite 160]
6.8 - 5.8 Strategien für Akzeptanztests [Seite 162]
6.9 - 5.9 Fazit [Seite 164]
6.10 - 5.10 Links & Literatur [Seite 165]
7 - 6 Kapazitätstests [Seite 167]
7.1 - 6.1 Einführung [Seite 167]
7.2 - 6.2 Kapazitätstests - wie? [Seite 168]
7.3 - 6.3 Kapazitätstests implementieren [Seite 173]
7.4 - 6.4 Kapazitätstests mit Gatling [Seite 174]
7.5 - 6.5 Alternativen zu Gatling [Seite 179]
7.6 - 6.6 Fazit [Seite 181]
7.7 - 6.7 Links & Literatur [Seite 182]
8 - 7 Exploratives Testen [Seite 183]
8.1 - 7.1 Einleitung [Seite 183]
8.2 - 7.2 Warum explorative Tests? [Seite 183]
8.3 - 7.3 Wie vorgehen? [Seite 185]
8.4 - 7.4 Fazit [Seite 189]
8.5 - 7.5 Links & Literatur [Seite 190]
9 - 8 Deploy - der Rollout in Produktion [Seite 191]
9.1 - 8.1 Einleitung [Seite 191]
9.2 - 8.2 Rollout und Rollback [Seite 192]
9.3 - 8.3 Roll Forward [Seite 193]
9.4 - 8.4 Blue/Green Deployment [Seite 195]
9.5 - 8.5 Canary Releasing [Seite 196]
9.6 - 8.6 Continuous Deployment [Seite 198]
9.7 - 8.7 Virtualisierung [Seite 200]
9.8 - 8.8 Jenseits der Webanwendungen [Seite 202]
9.9 - 8.9 Fazit [Seite 203]
9.10 - 8.10 Links und Literatur [Seite 204]
10 - 9 Operate - Produktionsbetrieb der Anwendungen [Seite 205]
10.1 - 9.1 Einleitung [Seite 205]
10.2 - 9.2 Herausforderungen im Betrieb [Seite 206]
10.3 - 9.3 Log-Dateien [Seite 208]
10.3.1 - 9.3.1 Werkzeuge zum Verarbeiten von Log-Dateien [Seite 210]
10.3.2 - 9.3.2 Logging in der Beispielanwendung [Seite 212]
10.4 - 9.4 Logs der Beispielanwendung analysieren [Seite 213]
10.4.1 - 9.4.1 Experimente und selber ausprobieren [Seite 218]
10.5 - 9.5 Andere Technologien für Logs [Seite 221]
10.6 - 9.6 Fortgeschrittene Log-Techniken [Seite 222]
10.7 - 9.7 Monitoring [Seite 223]
10.8 - 9.8 Metriken mit Graphite [Seite 224]
10.9 - 9.9 Metriken in der Beispielanwendung [Seite 226]
10.9.1 - 9.9.1 Experimente und selber ausprobieren [Seite 227]
10.10 - 9.10 Andere Monitoring-Lösungen [Seite 229]
10.11 - 9.11 Weitere Herausforderungen beim Betrieb der Anwendung [Seite 230]
10.12 - 9.12 Fazit [Seite 231]
10.13 - 9.13 Links & Literatur [Seite 232]
11 - 10 Continuous Delivery im Unternehmen einführen [Seite 235]
11.1 - 10.1 Einleitung [Seite 235]
11.2 - 10.2 Continuous Delivery von Anfang an [Seite 235]
11.3 - 10.3 Value Stream Mapping [Seite 236]
11.4 - 10.4 Weitere Optimierungsmaßnahmen [Seite 239]
11.5 - 10.5 Zusammenfassung [Seite 243]
11.6 - 10.6 Links & Literatur [Seite 243]
12 - 11 Continuous Delivery und DevOps [Seite 245]
12.1 - 11.1 Einführung [Seite 245]
12.2 - 11.2 Was ist DevOps? [Seite 245]
12.3 - 11.3 Continuous Delivery und DevOps [Seite 249]
12.4 - 11.4 Continuous Delivery ohne DevOps? [Seite 253]
12.5 - 11.5 Fazit [Seite 255]
12.6 - 11.6 Links & Literatur [Seite 256]
13 - 12 Continuous Delivery, DevOps und Softwarearchitektur [Seite 257]
13.1 - 12.1 Einleitung [Seite 257]
13.2 - 12.2 Softwarearchitektur [Seite 257]
13.3 - 12.3 Komponentenaufteilung für Continuous Delivery optimieren [Seite 260]
13.4 - 12.4 Schnittstellen [Seite 262]
13.5 - 12.5 Datenbanken [Seite 265]
13.6 - 12.6 Microservices [Seite 268]
13.7 - 12.7 Umgang mit neuen Features [Seite 271]
13.8 - 12.8 Fazit [Seite 274]
13.9 - 12.9 Links & Literatur [Seite 275]
14 - 13 Fazit: Was bringt's? [Seite 277]
14.1 - 13.1 Links & Literatur [Seite 278]
15 - Index [Seite 279]
16 - www.dpunkt.de [Seite 0]

1 Einleitung


1.1 Überblick über Continuous Delivery und das Buch


Continuous Delivery ermöglicht es, Software schneller und mit wesentlich höherer Zuverlässigkeit in Produktion zu bringen als bisher. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen reproduzierbaren, risikoarmen Prozess für die Bereitstellung neuer Releases darstellt.

Woher kommt der Begriff Continuous Delivery?

Das agile Manifest (http://agilemanifesto.org) definiert als wichtigstes Ziel:

»Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.«

Die deutsche Übersetzung findet sich ebenfalls auf der Website:

»Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.«

Also ist Continuous Delivery eine Technik aus dem agilen Umfeld.

Dieses Buch erläutert, wie eine solche Pipeline praktisch aufgebaut werden kann und welche Technologien dazu eingesetzt werden können. Dabei geht es nicht nur um das Kompilieren und die Installation der Software, sondern auch um verschiedene Tests, die dazu dienen, die Qualität der Software abzusichern.

Das Buch zeigt außerdem, welche Auswirkungen Continuous Delivery auf das Zusammenspiel zwischen Entwicklung (Development) und Betrieb (Operations) im Rahmen von DevOps hat. Schließlich werden die Auswirkungen auf die Softwarearchitektur beschrieben. Neben der Theorie wird ein möglicher Technologie-Stack vorgestellt, der Build, Continuous Integration, Lasttests, Akzeptanztests und Monitoring abdeckt. Für die einzelnen Bestandteile des Technologie-Stacks gibt es jeweils ein Beispielprojekt, mit dem der Leser praktische Erfahrungen sammeln kann. Das Buch bietet einen Einstieg in den Technologie-Stack und zeigt außerdem auf, wie man sich mit den Themen tiefergehend beschäftigen kann.

Durch Experimente und Vorschläge zum selber Ausprobieren lädt es zur weiteren praktischen Vertiefung ein. Die Leser erhalten so Anregungen, wie sie sich weiter in die Themen vertiefen und eigene Erfahrungen sammeln können. So können die Beispielprojekte Basis für eigene Experimente oder für den Aufbau einer eigenen Continuous-Deployment-Pipeline sein.

Unter http://continuous-delivery-buch.de steht die Website zum Buch bereit mit Informationen, Errata und Links zu dem Beispiel.

1.2 Warum überhaupt Continuous Delivery?


Warum sollte man überhaupt Continuous Delivery einsetzen? Eine kleine Geschichte soll diese Frage beantworten - ob sie wahr ist oder nicht, bleibt offen.

Eine kleine Geschichte

Das Marketing eines Unternehmens - nennen wir es Raffzahn Online Commerce GmbH - hatte entschieden, den Registrierungsprozess auf der E-Commerce-Website zu überarbeiten. Dadurch sollten mehr Kunden gewonnen und der Umsatz erhöht werden. Also machte sich ein Entwicklerteam an die Arbeit. Nach nicht allzu langer Zeit waren sie fertig.

Zunächst mussten die Änderungen getestet werden. Dazu hatte das Team der Raffzahn Online Commerce GmbH in einem aufwendigen Prozess eine Testumgebung aufgebaut, auf der die Software manuell getestet wurde. Und es wurden tatsächlich Fehler gefunden. Mittlerweile waren die Entwickler aber schon bei dem nächsten Projekt und mussten sich wieder einarbeiten, bevor sie die Fehler mit einem Fix beheben konnten. Und wegen der manuellen Tests stellte sich bei einigen »Fehlern« heraus, dass die Tester nicht richtig getestet hatten oder die Fehler aus irgendwelchen Gründen nicht reproduzierbar waren.

Nun galt es, den Code in Produktion zu bringen. Der Prozess dazu war aufwendig - denn die E-Commerce-Website der Raffzahn Online Commerce GmbH war über die Jahre gewachsen und daher sehr komplex. Nur dieses eine Feature auszuliefern, rechtfertigte den Aufwand nicht. Daher wurde nur einmal pro Monat deployt. Schließlich konnte die Änderung zusammen mit den anderen Änderungen aus dem letzten Monat in Produktion gehen. Dazu war eine Nacht reserviert. Leider gab es beim Rollout einen Fehler. Das Team machte sich an die Arbeit, das Problem zu analysieren. Aber das war so schwierig, dass das System am nächsten Morgen nicht zur Verfügung stand. Zu diesem Zeitpunkt waren die Mitarbeiter übernächtigt und standen unter großem Stress - jede Minute Ausfall kostete bares Geld. Und zurück zur alten Version ging es nicht, weil einige Änderungen im Deployment nicht ohne Weiteres rückgängig gemacht werden konnten. Erst im Laufe des Tages, nach einer ausführlichen Fehleranalyse, konnte eine Task Force das Problem beheben und die Website stand wieder zur Verfügung. Der Fehler war eine Konfigurationsänderung gewesen, die in der Testumgebung vorgenommen, aber bei der Produktionseinführung vergessen worden war.

Also schien alles in Ordnung zu sein - aber es gab einen weiteren Fehler, der zunächst nicht entdeckt wurde. Dieser Fehler hätte eigentlich durch die manuellen Tests gefunden werden sollen. Der Test, der den Fehler gefunden hätte, wurde auch erfolgreich durchgeführt. Aber in der Testphase wurden auch einige Fehler gefixt und dieser Test wurde nur vor den Fixes durchgeführt. Der Fehler wurde erst durch einen der Fixes eingeführt. Nach den Fixes wurde der Test nicht noch einmal durchgeführt - daher konnte der Fehler es bis in die Produktion schaffen.

Am nächsten Tag stellte sich also mehr zufällig heraus, dass die Registrierung für die Website der Raffzahn Online Commerce GmbH gar nicht mehr funktionierte. Das war niemandem aufgefallen und erst, nachdem der erste potenzielle Kunde sich bei der Hotline meldete, wurde das Problem erkannt. Wie viele Registrierungen dieser Ausfall gekostet hatte, konnte leider niemand sagen - dazu fehlten Informationen über die Nutzung der Website. Wie schnell die optimierte Registrierung diesen Nachteil ausgleichen konnte, ist fraglich. So konnte es gut sein, dass die Änderung nicht wie ursprünglich geplant zu mehr Registrierungen, sondern zu weniger geführt hatte. Und außerdem war das neue Release wesentlich langsamer - ein Umstand, mit dem vorher auch niemand gerechnet hatte.

Und so begann die Raffzahn Online Commerce GmbH, die nächsten Features zu implementieren, um in einem Monat wiederum ein Update der Website auszurollen. Was wohl dieses Mal passieren würde?

Continuous Delivery hilft.

Continuous Delivery löst solche Probleme durch verschiedene Maßnahmen:

  • Es wird öfter deployt - bis hin zu mehreren Malen pro Tag. Dadurch wird die Zeit, bis ein neues Feature genutzt werden kann, verringert.

  • Durch häufige Deployments ist auch das Feedback auf neue Features und Code-Änderungen schneller. Die Entwickler müssen sich nicht erst wieder darauf besinnen, was sie vor einem Monat implementiert haben.

  • Um schneller zu deployen, müssen der Aufbau von Umgebungen und die Tests weitgehend automatisiert werden, da der Aufwand sonst zu hoch ist.

  • Die Automatisierung führt zu Reproduzierbarkeit: Wenn die Testumgebung erfolgreich aufgebaut werden kann, dann lässt sich mit demselben Automatismus auch die Produktion aufbauen - und zwar mit derselben Konfiguration. Das Problem durch die Fehlkonfiguration der Produktionsumgebung wäre also nicht aufgetreten.

  • Außerdem führt die Automatisierung zu mehr Flexibilität. Testumgebungen können On-Demand aufgesetzt werden. So kann es z.B. bei einem Redesign der Oberflächen zeitlich begrenzt eine separate Testumgebung für Marketing geben. Oder für großangelegte Lasttests können zusätzliche Umgebungen aufgesetzt werden, um eine produktionsnahe Umgebung zu haben, die nach den Tests wieder abgerissen werden, so dass keine dauerhaften Investitionen in Hardware notwendig sind - wenn beispielsweise eine Cloud genutzt wird.

  • Automatisierte Tests führen dazu, dass Fehler leichter reproduziert werden können. Da die exakt gleichen Schritte bei jedem Test ausgeführt werden, gibt es auch keine Fehler bei der Testdurchführung.

  • Wenn Tests automatisiert sind, können sie öfter ausgeführt werden. Also wäre der Fix durch den gesamten Testprozess gegangen und dieser Fehler nicht erst in Produktion aufgefallen.

  • Das Risiko eines neuen Release wird weiter reduziert, indem das Deployment in Produktion so aufgesetzt wird, dass es einen Weg zurück zur alten Version gibt. So wird der Produktionsausfall aus dem Beispiel verhindert.

  • Und schließlich sollten die Anwendungen auch ein fachliches Monitoring haben, so dass die Registrierung nicht ausfallen kann, ohne dass es jemand merkt.

Durch Continuous Delivery gewinnt das Business eine schnellere Verfügbarkeit neuer Features und eine zuverlässigere IT. Die Zuverlässigkeit ist auch für die IT nützlich. Nachts oder an Wochenenden unter hohem Stress neue Releases auszurollen und Fehler zu beheben, macht eben keinen Spaß. Und es ist sicher auch für die IT besser, wenn Fehler durch Tests auffallen und nicht erst in Produktion.

Um Continuous...

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

27,99 €
inkl. 7% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters
E-Book bestellen