The document outlines the DevOps process for Office 365 and SharePoint, presenting a detailed agenda that includes tools and practices like Visual Studio Team Services and Azure, automated builds, and testing methodologies. It emphasizes the importance of managing technical debt and maintaining quality through continuous integration and deployment. The session aims to provide developers with a modern toolchain and best practices to enhance their productivity and software quality.

1. Set Up your DevOps
Process for Office
365/SharePoint
Or the path to dev awesomeness
Vincent Biret
@baywet
#SPSMonaco

2. #SPSMonaco

3. Vincent Biret
@baywet
bit.ly/vince365
MVP Office Servers and Services
Azure and Office 365 developer @ 2ToLead

4. Who’s this session for?

5. Agenda
•The new stack for SharePoint Framework
•Intro to Software lifecycle + devops
•Intro to VSTS/Azure
•The build system + deploy
•Unit tests with SPFX
•Intro to tech debt management
•Conclusion

6. Ready?

7. Modern toolchain for SharePoint/Office 365 developers at last
The new stack

8. IIS Express
Project Templates
Server side tool comparison

12. Bill is awesome!

13. Please tweet!
@williambaer is awesome! #spfx CC @baywet

14. The webpart project
Demo

15. Where it all begins
Software lifecycle

16. Software lifecycle : devops
Plan
Dev
Test
Production
Idea/Need Business Plan
Marketing Sales
Market
Feedback
Agile/CMMI/…
Architecture
Source Control
IDE
Build
xTests

17. Let’s talk about tooling
Visual Studio Team Services and Azure

18. You’ve probably heard about it
Azure
•Microsoft’s Cloud platform
•IaaS, PaaS, SaaS
•Literaly tons of services

19. Visual Studio Team Services
• TFS as a service
• Updated more frequently
• Pay per user/build
• Everything except
• SharePoint Integration
• Process Template Customization**
• Data Warehouse

20. Code as a team, not a guy in a cave
Branch management

21. Git + git flow
• Git is a decentralized source control technology
• Branches are cheap
• Merging is not a nightmare
• Cross platform
• Lot of tools
• Git flow is a process model for branch management
• Focused work
• Easy context switching
• Standard and no thinking required
• Semver…

22. Let’s increase the quality of releases
Build

23. Automated builds
•Predictable result
•Constant quality
•Time saving

24. Build 2015
•JSON definition
•Web edition
•Lot of third parties integrations
•Tasks on github! (see notes)
•Agent auto updates!

25. Agents
•Hosted Agents
•BaaS
•Installed Agents
•Azure, or anywhere else

26. Build section, build agents 2015
Demo

27. Automate all the things!
Deploy

28. Pick and choose!
Different schools
• Source promotion
• We promote to next level a certain state of source
• Rebuild if needed
• Build promotion
• Exact same binaries are promoted

29. VSTS – Release Management
•Same technology as the build 2015
•Notion of environments
•Approvals

30. Office 365 CDN
1. Configure Office 365 CDN to replicate site assets
2. Configure Urls in configuration files
3. Bundle files
4. Bundle app package
5. Upload js/json to sharepoint (custom task)
6. SharePoint replicates to CDN
7. Win!

31. MH and small project deployment with RM
Demo

32. Final touch to QA
Test

33. Tests levels
•Unit testing
•Load testing
•Integration testing
•System testing
•Functional/Acceptance testing

34. Tests types
•Installation
•Compatibility
•Regression
•Destructive
•Security
•L17N/I13N
•A/B
•…..

35. Test tooling
Runners Assertion libraries Emulators/Env Reporters Frameworks
Karma Chai + as promised PhantomJS Junit Mocha
MSTest MS.Test ns Node (backend) Coverage Casper
Istanbul Chrome Cobertura Jasmine
… … …
Runners: take care of running the tests and provide the infrastructure for (memory, processes…)
Asseration libraries: « ways » to write your unit tests
Emulators (or environments): context within the tests will run (server with node, browser, emulated browser…)
Reporters: take care of writing down tests results in comprenhensive format
Frameworks: provide a suite of functionnalities to help implement testing

36. Unit tests of demo webpart
Demo

37. Or how to avoid digging your own grave
Technical debt management

38. What is tech debt?
•Code we’re not comfortable with
•Preventing us from innovating
•Causing a lot of support
•Stressful for the team

39. Solutions?
•Rewrite everything every 2 years
•Pair coding
•Static analysis + linting

40. SonarQube for MH, linting for demo webpart
Demo

41. I swear, I’m going to stop talking soon and let you free
Conclusion

42. Conclusion
•Lot of time saved
•Consistent builds
•Automated tests
•Quality increased
•Money saved

43. Thanks
Vincent Biret
Office 365 and Azure Developer, 2toLead.
#SPSMonaco