MOSS kehitysympäristö – Yksinkertaisesta laajoihin projekteihin Aku Heikkerö, Vesa Juvonen Microsoft Consulting Services (MCS)

Agenda Sovelluskehitysympäristö –Team Foundation Server:n integroiminen osaksi kehitystä Visual Studio sovellusrakenteet ja suositukset Kikkoja ja ohjeita sovelluskehitykseeen

Who are we? Aku Heikkerö –Senior Consultant, Team leader, BPIO Service Line, Enterprise Services, Microsoft Finland –Member of a worldwide SharePoint Ranger team –In Microsoft since Companies before Microsoft – ICL, Fujitsu – Vesa Juvonen –Software Development Consultant, BPIO Service Line, Enterprise Services, Microsoft Finland –In Microsoft since 2006, started IT studies 1996 (graduation took a while). Companies before Microsoft – ICL, Fujitsu, BasWare working as Software Architect, Lead Software Development Engineer etc. – –Blog:

Development environments

Development environment Can be scaled from small to extra large depending on the available resources Use always some source control system to ensure that code is not lost –Draft code should be also included in source control TFS recommended, since it provides much more than just source code

Development environment Windows SharePoint Services only runs on Windows Server 2003 or later –Windows Server 2008 runs only with SP1 You can develop without it, but… You need a copy to deploy/debug Options –Make it your development OS –Run it in a Virtual PC / Virtual server –Have a standalone server at your disposal

Shared resources model Each developer has their own environments –Either in VPC or in individual computers Advantages –Individual environments don’t require that much hardware Disadvantages –You need to have access to database server to be able to develop Database server Source control

Centralized environments Virtualized environments are hosted from centralized server Advantages –Environments are managed from one place – Copy / clone etc. –Does not require much resources on individual computers Disadvantages –You need to have access to server –Requires heavy hardware to centralized server Centralize Server Virtualized MOSS environments Source control

Decentralized environments Each developer has their own environments –Either in VPC or in individual computers Advantages –Supports offline developement –Environments can be reset / cloned / copy easily Disadvantages –Requires more hardware from individual computers Source control

Continues Integration Functionalities are automatically deployed to integration server Advantages –Functionalities are automatically tested –Progress can be followed by other than developers –TFS provides much more than just compiling the code Disadvantages –Requires time and effort to setup – it’s however worth it! Team Foundation Server Development integration server

Ideal Devevelopment VPC Necessary Windows Components – IIS, SMTP, POP3 Service (AD).NET Frameworks: 2.0, 3.0, 3.5 Visual Studio 2005 Team System + Team Explorer (TFS Client) –TFS Client is needed to connect to centralized source repository Office Clients including SharePoint Designer (SP1) Software Development Kits (SDKs) –Microsoft Office SharePoint Server 2007 SDK Microsoft Office SharePoint Server 2007 Enterprise Service Pack 1 for the WSS3.0 and for MOSS 2007 SQL Server 2005 with latest service pack Additional tools to help development process: –Internet Explorer Developer Toolbar –.NET Reflector –Fiddler –U2U CAML Builder –Additional browsers – especially for Internet projects

VPC Minimum of 2 GB memory (4 GB preferred) –If 4 GB, then allocate 2 GB for the virtual machine –If you have 1GB in your computer, don’t even think about hosting MOSS / WSS Fast hard disk –If developer uses laptop, then fast external hard drive is recommended, because disk performance –Also each virtual environment can take easily 10 GB of hard disk space

Different Environments There are multiple different environments on which the developed functionalities have to be deployed –Continues testing important –Multiple deployments for the functionalities Environments –Development integration server –Quality assurance –Production Possible seperate authoring environment Development integration environment as part of the development Quality Assurance (testing) environment Production environment

BUILD AUTOMATION AND MOSS

Customer Perspective Customer just wants it to work!!!!

Build Automation is not … F5

324 1 Development environment 1) Developer with dedicated MOSS  Run it in a Virtual PC 2) Another developer with separate module responsibilities 3) Other project members  Observe project progress 4) Development Server  Ideally automated process to build daily versions based on labelled artefacts in the source control

Automating portal creation Option 1 –Create custom ms build tasks to deploy the code to MOSS portal during the building of the project Option 2 –Compile the code to drop location in the integration server using TFS build engine –Schedule custom application to deploye the solution package (wsp) to portal and recreate the hierarchies

Build Process in one large project Complete build authoring servers –DeleteSite –DeleteWebApp –CreateWebApp –AddZoneUrl –AddHostHeader –iisReset –CreateAppFormsVirtualDirectory –$(CreateKeyFiguresVDir) –Retractsolutions –DeleteSolutions –AddSolutions –DeploySolutions –CreateSite –CreateVariations –AddReusableContent –ConfigureNavigation –Install404ErrorPage –CopyConfigFiles –AddUsers –CopyWebServerExtensions –CopyFormsWebSite –$(DeployKeyFigures) –ModifyOrderableReports –RestartTimerJobs –CreateWeb –$(CreateTestDataTarget) –(Automatic testing) –BackupSite Complete build front end servers –CreateAppFormsVirtualDirectory –Retractsolutions –DeleteSolutions –AddSolutions –DeploySolutions –Install404ErrorPage –CopyConfigFiles –CopyWebServerExtensions –CopyFormsWebSite Upgrade build ValidateParameters UpgradeSolutions Execadmjobs DeactivateFeatures iisReset CopyConfigFiles CopyWebServerExtensions CopyFormsWebSite $(DeployKeyFigures) ModifyOrderableReports;BackupSite

Real Life MCS -.COM case 1.TFS builds the solution (wsp) package including also the necessary assemblies 2.Custom application is scheduled using windows timer to start after solution package has been created Removes the old portal Retracts the old solution Deploy new version Creation of the portal using portal site definition Set default anonymous / user access Configure other settings as part of the process Same tool was also used by the developers during the project to recreate the development portal to VPC’s

Visual studio project model and development process

Development Tools Microsoft SharePoint Designer does not really fall in the category of development tools but provides a design experience for SharePoint that can be leveraged by developers Visual Studio 2005 –Extended with WSS 3.0 Extensions for VS2005 v1.1 –Extended with Windows Workflow Foundation Extensions –Extended with Workflow Starter Kit Visual Studio 2008 –New Visual Studio Tools for Office version –Upcoming WSS 3.0 Extensions for Visual Studio v1.2 will support VS2008 – Expect by June 2008

Development process User interface customizations cannot be exported Due nature of SharePoint, development happen by creating bit’s and pieces –Features, Web Parts, Web Controls, Metadata files, site definitions etc.

Example module plan

Development process Tools and extensions for the SharePoint are useful, but not recommended directly to production usage –Use them to verify the functionalities and transfer the tested functinalities to official project Build up with debug project Test functionalities in individual environments Transfer the code to official project Test with the official deployment

Visual Studio Solution Create solution ready for the project and define the initial settings as first step in the project Structure / template should have seperate places for different kind of functionalities –Web parts –Feature receivers –XML metadata –Aspx files –Etc.

Utilize features and solution packages Encapsulate your customizations to features to automate the deployment from one environment to another

Resources Files Imitate the 12 hive in the resources project –Everybody in project can easily track what goes where 12 hive - C:\program files\common files\microsoft shared\web server extensions\12

Solution structure and usage

Summary There are multiple different models for the development environment –Usage depends on the project / company size and overall recommendations Use predefined solution structures as part of the development models Encapsulate your customizations to features and solutions

More information SharePoint community – SharePoint product team blog – Visual Studio structure used in demos and more guidelines (in future) –