Automatic Build and Deploy using Team Foundation Server
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,755 views
This document discusses how to automatically build and deploy SharePoint solutions using Team Foundation Server (TFS). It describes the components involved in a TFS build system including build controllers, agents, and definitions. It provides steps for configuring a build controller and agent for SharePoint. The document also covers creating build definitions, triggering builds, and using build process templates to customize the build workflow.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Automatic Build and Deploy using Team Foundation Server
Ähnlich wie Automatic Build and Deploy using Team Foundation Server (20)
Automatic Build and Deploy using Team Foundation Server
- 1. Automatic Build and Deploy using Team Foundation Server Travis Lingenfelder Senior Lead Consultant, Catapult Systems
- 2. THANK YOU FOR BEING A PART OF SHAREPOINT SATURDAY AUSTIN! • Please turn off all electronic devices or set them to vibrate • If you must take a phone call, please do so in the hall • Wi-Fi is available, you will need your Guest ID/password (at registration desk) • Feel free to tweet and blog during sessions. Remember to follow @SPSATX and tag #SPSATX in your tweets! SharePoint Saturday Austin is hosted by the Austin SharePoint User Group (@AustinSPUG) 2 | SharePoint Saturday Austin 2013
- 3. DEFINITIONS • Build Controller – A Windows service that creates the name of the build, version control label, logging, and monitors status of the build. Manages a pool of build agents. • Build Agent – Performs the processor-intensive work (compiling code, running tests, provisioning the workspace) for a build. • Drop Folder – The location where compiled project output is saved. • Build Definition – Instructions for what to compile and how to process • Build Process Template – The workflow process for managing the workspace and actions performed during the build process. 3 | SharePoint Saturday Austin 2013
- 4. SETUP OF THE BUILD SYSTEM
- 5. BUILD CONTROLLERS & AGENTS • A build controller is associated with a team project collection • A team project collection can have multiple build controllers • A build controller uses 1 or more build agents 5 | SharePoint Saturday Austin 2013
- 6. BUILD SYSTEM FOR SHAREPOINT Team Foundation Application Tier Server Triggers Build Can all be on a single server Build Controller Triggers Build Save Build Output Build Agent Build Server SharePoint PowerShell Deployment File Target Server Drop Folder Server SharePoint 6 | SharePoint Saturday Austin 2013
- 7. SHAREPOINT BUILD SERVER REQUIREMENTS • TFS Team Build Service • .NET Framework 4 • Windows SDK • Domain-Specific Language (DSL) • SharePoint Assemblies • Visual Studio or Tool Assemblies • MS script - http://go.microsoft.com/fwlink/?LinkId=188064 - OR – • TFS Team Build Service • Visual Studio • SharePoint 7 | SharePoint Saturday Austin 2013
- 8. CONFIGURE A SHAREPOINT BUILD CONTROLLER 8 | SharePoint Saturday Austin 2013
- 9. CONFIGURE A SHAREPOINT BUILD AGENT 9 | SharePoint Saturday Austin 2013
- 10. CONFIGURE A SHAREPOINT BUILD AGENT • Make sure the service account for the build agent is granted the following rights on the build server: • Local Administrator • SharePoint Farm Administrators • Add-SPShellAdmin • Full Control Web Application Policy 10 | SharePoint Saturday Austin 2013
- 11. CREATE A BUILD DEFINITION
- 12. CREATE A BUILD DEFINITION 12 | SharePoint Saturday Austin 2013
- 13. CREATE A BUILD DEFINITION 13 | SharePoint Saturday Austin 2013
- 14. CREATE A BUILD DEFINITION 14 | SharePoint Saturday Austin 2013
- 15. CREATE A BUILD DEFINITION 15 | SharePoint Saturday Austin 2013
- 16. CREATE A BUILD DEFINITION 16 | SharePoint Saturday Austin 2013
- 17. CREATE A BUILD DEFINITION 17 | SharePoint Saturday Austin 2013
- 18. BUILD THE WSP 18 | SharePoint Saturday Austin 2013
- 19. CREATE A BUILD DEFINITION 19 | SharePoint Saturday Austin 2013
- 20. WORKING WITH A BUILD PROCESS TEMPLATE AND CUSTOM WORKFLOW ACTIONS
- 21. CREATING WORKFLOW ACTIVITIES • Add project references to the following assemblies: – Microsoft.TeamFoundation.Build.Client – Microsoft.TeamFoundation.Build.Workflow 21 | SharePoint Saturday Austin 2013
- 22. ABOUT ASSEMBLY VERSIONS • Assembly Version – used as part of the assembly identifier (strong name) – Do not change between builds <%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> • File Version – informational version not used by the runtime – Use this for build information 22 | SharePoint Saturday Austin 2013
- 23. EDITING A BUILD PROCESS TEMPLATE Logic for all actions (tasks) that will be taken during the build • Windows Workflow Foundation • Found in the BuildProcessTemplates folder of a team project • Edit using the workflow designer • Add custom workflow actions Tip: be sure to register the version control path for custom assemblies • Make copies of default templates before editing 23 | SharePoint Saturday Austin 2013
- 24. BUILD PROCESS PARAMETERS (ARGUMENTS) 24 | SharePoint Saturday Austin 2013
- 25. BUILD PROCESS TEMPLATE PROJECT • Create a Visual Studio .NET Framework 4 class library project to edit the workflow when using custom build workflow activities. • Add the XAML process template to the project. • Add project references to custom activities project(s) • Add a reference to the following assemblies: – C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEReferenceAssembliesv2.0 • Microsoft.TeamFoundation.Build.Client.dll – C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEReferenceAssembliesv2.0 • Microsoft.TeamFoundation.Build.Client.dll • Microsoft.TeamFoundation.VersionControl.Client.dll • Microsoft.TeamFoundation.WorkItemTracking.Client.dll – C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies • Microsoft.TeamFoundation.Build.Workflow.dll • Microsoft.TeamFoundation.TestImpact.BuildIntegration.dll – C:WindowsassemblyGAC_MSILMicrosoft.TeamFoundation.TestImpact.Client10.0.0.0__b03f5f7f 11d50a3a • Microsoft.TeamFoundation.TestImpact.Client.dll – System.Activities – System.Drawing – System.ServiceModel – System.ServiceModel.Activities – System.Xaml 25 | SharePoint Saturday Austin 2013
- 26. DEMO
- 27. 64-BIT POWERSHELL • SharePoint PowerShell add-in is 64-bit only • Visual Studio is a 32-bit application • TFS Build Service can be 32-bit or 64-bit • %SystemRoot%System32 64-bit • %SystemRoot%SysWOW64 32-bit (virtualized as System32) How do I launch a 64-bit version of PowerShell from a 32-bit Process? • %SystemRoot%sysnative • %SystemRoot%sysnativeWindowsPowerShellv1.0powershel l.exe 27 | SharePoint Saturday Austin 2013
- 28. APPLICATION LIFECYCLE CODE BRANCHES AND DEPLOYMENT
- 29. CODE DEPLOYMENT PATH At different times in the application development lifecycle we will want to deploy to different environments. Local Development Quality Assurance User Acceptance Testing Production 29 | SharePoint Saturday Austin 2013
- 30. SCHEDULED CURRENT RELEASE ITEMS Main Development Branch • vNext Release Items Daily or Weekly Builds QA Environment 30 | SharePoint Saturday Austin 2013
- 31. CODE COMPLETE: TIME TO BRANCH Main Development Branch • vNext Release Items Daily or Weekly Builds Create Code Complete Branch Deployed to Production QA Environment Branch Becomes Next Release Branch Production Support Branch • Bug fixes • Hotfixes UAT/Pre-Production Pre-Production & Production Environments 31 | SharePoint Saturday Austin 2013
- 32. CODE BRANCHES AND DEPLOYMENT Deploy to Production Before Deployment After Deployment Main Development Branch Main Development Branch • 1.2 • 1.2 Production Support Branch Archived Branch • 1.0 • 1.0 Next Release Branch Production Support Branch • 1.1 • 1.1 32 | SharePoint Saturday Austin 2013
- 33. HOTFIX ITEMS Main Development Branch • vNext Items QA Environment Production Support Branch • Hotfixes Pre-Production & Production Access Granted Environments Deployed to Production 33 | SharePoint Saturday Austin 2013
- 34. REFERENCES • How to Build SharePoint Projects with TFS Team Build http://msdn.microsoft.com/en-us/library/ff622991.aspx • SharePoint/TFS Continuous Integration Starter Pack http://sharepointci.codeplex.com/ • TFS 2010 & Sharepoint 2010: automated build and deploy (remotely) http://www.rightpoint.com/community/blogs/viewpoint/archive/ 2011/06/19/tfs-2010-amp-sharepoint-2010-automated-build- and-deploy-remotely.aspx • Create a Custom WF Activity to Sync Version and Build Numbers http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to- create-a-custom-workflow-activity-for-tfs-build-2010.aspx • Ewald Hofman - Customzie Team Build 2010 Parts 1 – 16 http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team- Build-2010-e28093-Part-1-Introduction.aspx 35 | SharePoint Saturday Austin 2013
- 35. PLEASE FILL OUT SESSION EVALUATIONS AND THANK YOU FOR ATTENDING!
- 36. THANKS TO OUR SPONSORS! 37 | SharePoint Saturday Austin 2013
Hinweis der Redaktion
- Create a folder in source control in which custom build process workflow activities will be placed.Each build controller can only reference a single location.
- Create a project for editing the workflow process when using custom actions.Visual Studio will need to know how to open the assembly that contains the custom actions and does not know how to get the assembly from the source control folder specified for the build controller. Assembly could be added to the GAC or the referenceAssemblies folder but it will need to be kept up to date.Creating a project will allow the workflow designer and toolbox to always use the current version of the assembly. Just make sure that is the version copied into the source control folder for the build controller or the build process may not work properly.
- All work that is scheduled as part of the full release cycle is performed in the Main Development Branch.Code from this branch is built and deployed to the Testing Environment (QA) on a daily or weekly basis.
- Once the “Code Complete” milestone is reached:The code will be branched in TFSThe new branch will be read-onlyThe new branch will be compiled and deployed to the Pre-Production & Production EnvironmentsOnly bug fixes for the next release are allowedNo more deployments or code changes in the current Production Support Branch
- ALM currently in UAT stage while Release 1.0 currently deployed to production.Business is performing UAT on release 1.1 while developers are starting work on release 1.2Once deployed, the previous Production Support Branch becomes obsolete and is kept for archival purposes. The Next Release Branch becomes the new Production Support Branch.
- To work on items in the current support branch (Hotfixes, Quick Release), permission must be granted from the team project administrator.