Dev Ops for Unity Game Development

1. Dev Ops for Unity Game Development David Crook – Technical Evangelist – Microsoft

2. David Crook • Technical Evangelist for Microsoft • Focus on Game and App Development Communities • Background in Enterprise Consulting and Game Development • Hobbies: Brewing Beer, Brazilian Jiu Jitsu • Email: dacrook@Microsoft.com • Twitter: @DavidCrook1988 • Skype: DavidCrook1234 • Web Site: www.IndieDevSpot.com

3. Agenda • Current Promotions • Dev Ops • The agile process • Using TFS to manage the agile process • How the development cycle works for teams targeting multiple platforms • How to actually implement this with TFS • How release works for multiple platforms • How to implement this with TFS • How to fix production issues and incorporate it into the normal dev process • How to propagate production bug fixes to all releases. • How to propagate production bug fixes up to the dev cycle.

4. www.dvlup.com

5. www.buildforwindows.com

8. Bizspark and Dreamspark • Bizspark is for anybody trying to make money from developing apps for windows • Dreamspark is for students.

9. What is Dev Ops? • Development Operations How to run an innovation organization, the right way.

10. Great, but what does that mean? • Come up with an idea – but use an agile management system • Build that idea – but ensure you keep track of your various versions so you can build new ideas • Test that idea continuously – preferably in an automated or controlled fashion • Ship that idea – but know how it does in the wild and maintain it and innovate future versions based on that. Development Operations is the same as normal development, but with a lot more focus on release management and product insight.

11. So what about Unity Game Dev? • Agile Process: This is the same as most. Using TFS process management, this is easy and the industry standard. • Versioned Items: Models, Animations, Mechanim, Scenes, Prefabs, Code, Particles, Materials, Shaders and MANY MANY Others! • Testing: There appears to be a gap on good guidance here. Unit testing at the moment appears to need to happen at the platform level and is difficult to implement. Visual testing using debug.log, TFS CodedUI tests an a test environment may be do-able but heavy to maintain. Server side testing is still easy. Looks like primarily manual testing so far. • Release Management: Multiple branches for various releases and maintenance. • Live Inspection: Server side is easy with AppInsights, otherwise it looks like standard client side error logging.

12. Why Agile Process Management • Self Tuning System. Deep insight into progress. Deep insight into what works and does not work for each team and project. Great for showing to stake holders. Really helps keep projects on track. I have consulted on this for several years and the largest factor for success or failure is the process management not the team’s engineering prowess.

13. What does the Agile Process Look Like? • Come up with a product idea (or incorporate that into your backlog) • Determine your Schedule. • Iterate and tune your process daily and sprintly.

14. What does a Sprint Look like? • Sprints are broken down into three sections. • 1. Sprint Planning (10%) • 2. Sprint Execution (60%) • 3. Testing and Stabilization (20%) • 4. Delivery to stake holders (10%) • The first day of a sprint is a kick off meeting discussing key meetings process changes for this sprint, goals etc. • The last day of a sprint is a retrospective on the entire sprint. What went well, what could be improved on?

15. Sprint Planning Backlog grooming Any dependencies or blockers for various work items. Special considerations Rough Estimates (I prefer Fibonacci) for tasks Capacity Planning Initial assignments

16. Sprint Execution • Standard Day: • Morning standup meeting (box it to 15 minutes) • Break out to other meetings if its more than a status, but raise awareness here. • Execute on your tasks with your team. • Make sure you update your progress on your work items BEFORE the end of the day. This includes, changing its state, as well as hours completed against it.

17. Testing and Stabilization • So you should always be testing, but when working with a team on several different parts, integration between your various tasks and PBIs can cause issues. • Always save at least 20% of your Sprint for testing and stabilization for this. • If you are an Ace Team and complete this ahead of schedule, spend extra time testing, preparing for future sprints, but more likely you should add really awesome documentation and check for coding standards, do code reviews with your team and cross training.

18. Delivery to Stake Holders • This is typically a meeting with stake holders (or QA if you are so lucky). • Talk about what you are delivering to Stake Holders, do a few demos of each feature and PBI completed. • Discuss known issues and bugs. • Take in any feedback or concerns from stake holders and add that to your sprint planning for the next sprint. (Perhaps they found several bugs in features you delivered during the previous sprint).

19. Releases • Rinse and repeat for each sprint you have scheduled for your sprint, and ensure you keep tabs on scope and timelines.

20. So how do we actually implement a good process? • TFS Online - www.visualstudio.com • Free for teams under 5 and also for BizSpark members. • When you sign up, come up with an account name, probably something like “yourcompanyname”

21. Your Dashboard • See your current projects • Create new Projects • Browse all projects • See all the users in your projects • See basic licenses you have given • See all Team Rooms

22. Create a new Project • I always use Scrum. I find it extremely effective. • I like TFS Version Control over GIT. • 1. Centrally controlled. • 2. Easier to conceptualize the full cycle (for me).

23. Project Dashboard • Cool how to section. • Work clicks • Progress bar on current sprint • Pinned items • Current members for this project • Access to Team Room

24. Schedule and Iterations • Create you Project schedule. • Your reports are based on this. • Your backlog is built against this. • Your work items display based on this. • The starting point for every project is deciding when you want to release • I really like 3 week sprints.

25. Releases and Sprints • Release: • A deployable product. Release 1 for project spritzer is a simple game framework with only 3 characters in a single arena but contains most of the framework required for expansion. • Sprint: • Should encompass an entire deliverable piece of work. Examples: A completed Character or Networking for 5 users. Sprints contain Epics, Product Backlog Items and Tasks.

26. Epics, Product Backlog Items, Tasks • Epic: Typically spans multiple sprints, but should fit in an entire release. Epics are made up of PBIs. An example might be complete networking. • Product Backlog Items: Next breakdown level from an Epic. PBIs are composed of tasks. PBIs should be complete-able within a single sprint. Using the example above, you could break it down into a few PBIs: Setup Initial Infrastructure, Create Auto-Scaling Scripts, Write Code for Networking in Game. • Tasks: Should be no longer than 8 hours including testing time. An example of a task would be: Write Restful Service for “RequestJoinSession()” or “Create Group Policy for data center servers”.

27. Design, Documentation, Optimization • These can all be incorporated into the plan. That’s the beauty of the Process. An entire sprint could be the epic: Come up with an idea and initial plan we could potentially execute on.

28. Add new PBIs • Navigate to Work • Then select Backlog. • Make sure the main window has backlog selected and not board. • Click the little plus button Secret button! Note that if this is anything except Backlog items, you can’t add new ones.

29. Create the PBI • Type the name of the PBI and click “Add” • Double click the PBI • Fill in the information • Iteration! • Initial Effort • Area! • DESCRIPTION! • ATTACHMENTS! • I prefer to click Save instead of Save and Close

30. Add any immediately known Tasks • Click the Create New Linked Work Item button • Link Type is child, Item type is Task • Use a very descriptive title.

31. Setup Capacity • Capacity is dev hours per day available.

32. Team Stats - Workload • This says that our team is only assigned 39 hours out of a total capacity of 75 • Dave Voyles is only assigned 11 of 30 hours he has available for Sprint 1 • David Crook is only assigned 28 of 45 hours he has available for Sprint 1. • 16 hours is dedicated to Development activities while 23 are unspecified. • FANTASTIC for determining if you are within scope or not. Also good to see who needs additional work as well as who is over assigned.

33. The Burn Down And Board • Every standup should start here! • You can see both by navigating to Board under Work. • Clicking the chart in the top right shows the burn down. • Burndown: How your actual trend towards completion looks against the ideal trend • Board: Shows completed tasks, in progress tasks, remaining hours, who they are assigned to etc. • Only the first level up from a task shows up in the board, so if you are following Epic, PBI, Task, only PBIs and Tasks will show up. Here you can see 3 PBIs with 3 Tasks each.

34. Q&A • If you have been holding questions, this is where you should ask them regarding this section.

35. Version Control • This is how you will have a server copy of all your work that can be shared with and versioned with team mates across the world. If you mess up, just revert to an older change set. • You MUST have Unity Pro or Unity Team. • Unity Team will allow you to utilize the Unity version control systems, pro will allow you to use any version control system. I prefer tried and true version control personally and decided to go with pro. • Why…? Unity’s internal format, however, can add extra functionality like this to any asset type. All metadata for assets is stored in the Library folder.

36. More on why – this slide is just for reference. Before checking your project in, you have to tell Unity to modify the project structure slightly to make it compatible with storing assets in an external version control system. This is done by selecting Edit->Project Settings->Editor in the application menu and enabling External Version Control support by selecting Visible Meta Files in the dropdown for Version Control. This will show a text file for every asset in the Assets directory containing the necessary bookkeeping information required by Unity. The files will have a .meta file extension with the first part being the full file name of the asset it is associated with. Moving and renaming assets within Unity should also update the relevant .meta files. However, if you move or rename assets from an external tool, make sure to syncronize the relevant .meta files as well.

37. OK, so initial set up! • Edit->Project Settings->Editor -> select Visible Meta Files in the dropdown for Version Control. • Delete your Library Folder. • Delete your Temp Folder • Initial Check in (next slide) • Order of these operations is VERY important.

38. Connect to your project • Open Visual Studio 2013 • On the top tab bar, navigate to TEAM -> Connect to Team Foundation Server • Click the Select Team Projects… link • If you see your Server from the list, select it, otherwise add it. • Select your project collection and the project.

39. Set up your local workspace • Click Source Control Explorer • Select your project, and then click the “Not mapped” link next to Local Path: • C:\projects\Spritzer

40. Check In • Create a folder called “Main” and copy your Unity Project (minus Library folder) into it. • Right click in Source Control Explorer and select “Add New Items” • Select the new main folder. • Click Next • Click Finish • Notice the green plus marks. This means the items are added, but not checked in yet. • Right click Main from Source Control and select “Check in Pending Changes”. • Under Comments, type “Initial Check in!” (notice you can associate work item ids).

41. Managing your code • Understand what files your modifications are editing and how it might do it and if those are mergeable. • Example: Binary files are not mergable. If two people work on a scene at the same time, that may be difficult to merge. You should lock that file. • If you muck something up, you can revert your changes. Or roll back to another version.

42. Always get Latest Changes First! • Rightclick the folder structure you wish to get latest from (Main or subfolders). Select “Get Latest Version”. • Alternatively you can get a specific version. This is done by rightclick->Advanced->Get Specific Version

43. Always Create a lock on binary files. • Right click the file you wish to lock within TFS source control • Navigate to Advanced • Select Lock • When you finish your changes and check in, the locks will be removed automatically for you.

44. Revert Changes • Right click on the section of the folder structure you want to revert changes for or see history. • Select View History • Find the changeset you wish to roll back. • Right Click and select “Rollback changeset”. • Understand the gravity of your changes and changesets that came after (Luckily it tells you). On the plus side you can always roll these changes back too . • Click Take Rollback Version • Check in your changes!

45. Undo Pending Changes! • Right Click -> Undo Pending Changes. • Undo Changes

46. Release Management • Development + Release for multiple platforms. • Hotfixes to Production • Integration back into the development cycle • Facilitated with Branching and Merging • *No silver bullet here, do what works based on your team dynamic, experience and goals. Realize that this changes over time.

47. Terminology • Branch: Separate set of code that can be worked on that should be kept in constant sync with your other branches. Naming and use of them changes and we will talk about this. • Merging: Integration between two branches to synchronize them. • Release Branch: Read only branch that is a snapshot in time of a release that has been published to the public. • Development Branch: Branch in which work happens.

48. Sample Development 1 • Team of 5 • 2 artists 3 coders. • Each coder has their own platform they specialize in (Windows, iOS and Android). • This team’s goal is to release to all platforms simulateously

49. Sample Development 2 (Spritzer) • 2 coders. • 2 specializations. Windows and iOS with a target to deploy to Windows 8.1, 8 and Phone first.

50. What to Branch and why? • Ideally you would create a parent branch Main and then branches underneath for each scripts folder to minimize the amount of data stored on the server. Unfortunately this does not work due to a few reasons. • Branch names must be unique and how Unity detects scripts, folders etc • You cant have a branch contained within a branch. Branches are all branches of a set of items. Branching/Merging is for just that, having a branch within a branch and attempting a merge of those two is a bit silly. • You HAVE to branch at the top level, where we created main.