Continuous Integration mit VSTS Dieter Rüetschi

Größe: px

Ab Seite anzeigen:

Download "Continuous Integration mit VSTS Dieter Rüetschi"

Bärbel Hauer
vor 5 Jahren
Abrufe

1 Continuous Integration mit VSTS Dieter Rüetschi 1

2 2 Warum ist Continuous Delivery so wichtig? Geschwindigkeit schnell auf dem Markt Unterstützung und Teil des ALM

3 3 DevOps Eine Denkweise Werte Nutzen schaffen Kein DevOps Hero, Struktur auf DevOps ausrichten Automatisierung Fail fast Kultur (Fehler machen dürfen)

4 4 Cross Plattform Tool Visual Studio Team System (TFS)

5 5 VSTS Enterprise Ready? Compliance (ISO Zertifizierung)

6 Visual Studio Markteplace 6

7 End to End DevOps 7

8 8 Hilfsmittel in VSTS Dashboard und Charts Backlogs & Kanban Boards Work Items Social Workflows Anpassbare Agile Prozesse Entwicklung und Testintegration

9 Der Ablauf 9

10 10 Impacts to Design Singleton und andere Manager Software ist nicht optimal geeignet für CI Service Oriented Patterns sind sehr gut für CI geeignet Entkoppelte Komponenten sind gut geeignet

11 Dashboard 11

12 Backlog Neu in Farbe 12

13 13 Developing und Test DevOps Traceability Cross Plattform Unit Testing (mit verschiedenen Tools) Build (für verschiedene Buildumgebung)

14 14 Continuous Integration Cross Plattform Open Source (VSTS, Git, GitHup, und viele mehr) Extensible

15 15 Unit Testing Unit Test C# Visual Basic.NET

16 16 Was ist Unit Testing? Programme werden in Module (Units) aufgeteilt. Der Modultest (engl. Unit Test) ist der Softwaretest für ein Modul Ziel: rechtzeitig Programmfehler aufdecken Tests einzelner Module sind einfacher als bei integrierten Modulen, da weniger Abhängigkeiten Agilen Softwareentwicklungsmethoden (Extreme Programming, Scrum, Crystal, ) fordern automatisierte Modultests. Nach jeder Änderung können Tests wiederholt werden Manuelle Tests sind teuer und werden in der Praxis oft vernachlässigt

17 17 Eigenschaften von Unit Tests Isoliert Unit Tests testen ein isoliertes Modul, ohne Interaktion mit anderen Modulen Externe Module/Komponenten (Datenbanken, Dateien, ) müssen simuliert werden (Mock-Objekte) Test von Fehlverhalten Nicht nur das korrekte Verhalten, sondern insbesondere auch das Fehlverhalten wird getestet. Periodische Ausführung Tests werden regelmässig (vor Einchecken, Daily Build, ) durchgeführt, damit Änderungen keine unerwünschten Nebeneffekte haben. Test der Verträge Nicht die Interna (Algorithmen), sondern die externen Auswirkungen (Ergebnisse, Zustandsänderungen, Exceptions) sollen getestet werden. Test Driven Development (TDD) Das Design der Software entsteht durch das Schreiben von Tests Pro Bug ein neuer Test

18 18 Schwierigkeiten mit Unit Tests Nicht alle Bereiche der Software sind für Unit Tests geeignet Benutzeroberflächen: Einsatz des MVC-Patterns vereinfacht das Testen Kopplung an Bibliotheken (z.b. Datenbankanbindung): nicht nur die eigene Software, sondern auch die Komponente wird getestet. Multithreading: zeitliches Verhalten kann schlecht simuliert werden Tools generieren Unit-Tests auf Basis vorhandener Bibliotheken Das ist zwar äusserst praktisch, wenn man bestehende Bibliotheken Testen möchte, widerspricht aber dem Test- Driven Development (write Test first) Bei Änderungen an der Software müssen auch die Tests angepasst werden Schnittstellen sind weniger änderungsanfällig als Algorithmen, daher sollten sich die Änderungen im Rahmen halten, wenn die Tests an der richtigen Stelle eingreifen

19 19 Aufbau eines Tests Testname beschreibt genau, was der Test prüft (=> aussagekräftige Namen) AAA-Prinzip: Arrange: Initialisierung der nötigen Objekte Act: zu testende Operation aufrufen Assert: Resultate prüfen

20 20 Mocking und Stubbing: Begriffe Stub dt. Stumpf/Stummel. Proxy (Stellvertreter) für realen Code Liefert keine Echtdaten, sondern zum Kontext passende Daten Kann auch Daten über Aufrufe aufzeichnen (zu Prüfzwecken). Verifiziert den Zustand des Objekts Mock-Objekte Fälschung / gefälschtes Objekt Implementiert Schnittstelle, über die das zu testende Objekt auf die Umgebung zugreift. Definiert Annahmen über die Art der Aufrufe. Mocks verifizieren dieses Verhalten. Quelle:

21 Praxis unser Testprojekt 21

22 Builddefinition erstellen 22

23 Die verschiedenen Einstellungsmöglichkeiten 23

24 Solution festlegen und Name bestimmen 24

25 Das Ergebnis 25

26 Vielen Dank für Ihre Aufmerksamkeit 26

Ähnliche Dokumente

Softwareentwicklung bei eevolution

Softwareentwicklung bei eevolution Darstellung der Prozesse mit dem agilen Entwicklungsansatz Jan Freitag, COMPRA GmbH Jan Freitag Studium: IMIT Bachelor: 2005-2008 IMIT Master: 2008-2010 eevolution: Mitarbeit