Collaboration Days 2011 - Damit die Tester schneller ran können.
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Collaboration Days 2011 - Damit die Tester schneller ran können.

on

  • 775 views

 

Statistics

Views

Total Views
775
Views on SlideShare
775
Embed Views
0

Actions

Likes
1
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Erstellen eines Web TemplatesErstellen von Content Types
  • Zeigen
  • CredSSP:Security Support Provider (SSP),übergabe der Login Informationenvom Client an den Server

Collaboration Days 2011 - Damit die Tester schneller ran können. Presentation Transcript

  • 1. David SchneiderDamit die Tester schnellerran können.Daily Builds mit SharePoint
  • 2. About the SpeakerDavid Schneider: david@sharepoint.chBlog: http://blog.sharepoint.chisolutions AG: http://www.isolutions.ch
  • 3. Agenda Paketierung Team Foundation Server Automatisches Deployment Build Quality, Versionierung, Continuous Integration
  • 4. Die Vision «Jede Nacht wird der aktuelle Stand der Entwicklung auf unser Testsystem deployt. Sämtliche Daten sind vorhanden, so dass die Tester sofort mit dem Test beginnen können.»
  • 5. Herausforderung Agile Projekte, kurze Iterationen Jede Iteration muss getestet werden Die Lösung wird immer wieder deployt Deployment muss schnell und einfacherfolgen (ansonsten laufen die Kosten aus demRuder)
  • 6. Build Automation is not… F5
  • 7. SharePoint Solutions Code (Web Parts, Event Receivers) Content (Sitestruktur, Composites (SharePoint Listeninhalte, Designer, Customizations) Berechtigungen)
  • 8. Umfang des Deployments Deployment von Code Solutions «Deployment» von No-Code Customizations Erstellen der Site Struktur Einrichten der Sites Erfassen von Stammdaten Vergeben von Berechtigungen
  • 9. ZielDeployment erfordertwenige manuelle DEVSchritte PROD TEST Paketierung als WSP Manipulationen per Skript INT
  • 10. Was lässt sich als WSP deployen… DesginCode Customizations • Web Parts • Master • Content • Event Page Types Handlers • Page • Site • Coded Layouts Columns Workflows • CSS • Ribbon • JavaScript • Themes
  • 11. WSP einfach & schnell erstellen Visual Studio 2010 Projekt Features für  Master Page, Page Layouts und Ressourcen  Site Columns und Content Types Visual Studio Add In http://cksdev.codeplex.com/
  • 12. Wofür schreibt man ein Script…Struktur Funktionen Zugang • Site Collections • Features • Berechtigungen • Sites aktivieren • Navigation • Listen • Master Pages • Basisdaten setzen
  • 13. Deployment von Site Templates Site Template («Save as Template») • Nur innerhalb einer Site Collection • Import nach Visual Studio bringt viel Ballast mit Site Definition • Aufwändig, auch Microsoft rät davon ab Web Templates • Delta zu OOTB Site Definition als Feature • Elements.xml und (vereinfachtes) ONET.XML
  • 14. Deployment von SPD Customizations Workflows, BCS, Customized Forms, etc. Speichern als Sandbox Solution Deployment der Sandbox Solution mittels PowerShell Script
  • 15. Demo
  • 16. Integrationsumgebung Content Benutzer Farm Design Language Packs Patch Level Service Applications • Profiles, MySite, Search, Managed Metadata Alternate Access Mapping
  • 17. Lohnt sich der Aufwand? Produktentwicklung Mehrere Iterationen Team > 2 Entwickler Projektdauer > 2 Monate Verteilte Teams
  • 18. Gewinn Aufwand für Deployment ist gering Automatisches Deployment ist getestet Konsistente Builds
  • 19. David SchneiderTeam Foundation Server 2010
  • 20. Visual Studio Team System 2010
  • 21. Server Umgebung
  • 22. TFS Build Process Code zusammenstellen • Workflow Foundation 4.0 Kompilieren • MSBuild 4.0 Testing • Workflow Foundation 4.0 Deploying • Workflow Foundation 4.0
  • 23. David SchneiderTeam Build in SharePointProjekten
  • 24. WSP generieren…MSBuild Argument/p:IsPackaging=True
  • 25. Deployment der Lösung Keine OOTB Unterstützung WF Activity PowerShell • z.B. http://sharepointci.codeplex.com/
  • 26. Vorbereitung Integrationssystem PowerShell Remoting erlauben Enable-PSRemoting Credentialsübergabe via CredSSP einschalten Enable-WSManCredSSP –Role Server PowerShell Memory auf 1 GB Set-Item WSMan:localhostShellMaxMemoryPerShellMB 1024
  • 27. Berechtigungen Build Account LocalAdmin auf Integrationssystem Farm Administration Group Zugriff auf PowerShell Add-SPShellAdmin
  • 28. Vorbereitung Build Agent PowerShell execution policy Set-ExecutionPolicy RemoteSigned Credentialsübergabe via CredSSP Enable-WSManCredSSP -Role client - DelegateComputer “SPServer”
  • 29. Zugriff testen Build Server  Integrationsystem Enter-PSSession –ComputerName “SPServer” Enter-PSSession -ComputerName “SPServer” -Authentication CredSSP – Credential Get-Credential
  • 30. David SchneiderSharePoint/TFS ContinuousIntegration Starter Pack
  • 31. Build Prozess mit SharePoint CI
  • 32. Site ProvisioningPowerShell Script, welches die gesamte Lösung erstelltund konfiguriert.
  • 33. Site Provisioning
  • 34. Version 1.1?Herausforderung: neuer Release einerbestehenden LösungMögliche Lösung: Bei jedem Deployment Content DB löschen und neu attachen Upgrade Prozess durchlaufen
  • 35. David SchneiderBuilds versionieren
  • 36. Versionierung der AssembliesAssembly Version wird referenziert (Web Parts, WebControls, Event Handlers) und kann daher nicht geändertwerdenAlternative: Assembly File Version  Anzeige als ProductVersionhttp://tfssimpleversioning.codeplex.com/
  • 37. David SchneiderWeitereQualitätsindikatoren
  • 38. TFS ReportsBuild Quality Indicators Failed/passed Tests Code Churn Code Coverage Active BugsCode Analysis SPDisposeCheck
  • 39. Continuous Integration Build und Deploy nach jedem Check In Deployment auf eigenes Test System, welches nicht von den Tester verwendet wird Automated UI Tests ausführen
  • 40. Zusammenfassung Paketierung von SharePoint Solutions Build mit TFS Deployment mit PowerShell Scripts
  • 41. KontaktdatenDavid Schneider: david@sharepoint.chBlog: http://blog.sharepoint.chisolutions AG: http://www.isolutions.ch