68
Dev Ops for Unity Game Development DAVID CROOK – TECHNICAL EVANGELIST – MICROSOFT
Dev Ops for Unity Game DevelopmentDAVID CROOK – TECHNICAL EVANGELIST – MICROSOFT
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: [email protected]
Twitter: @DavidCrook1988
Skype: DavidCrook1234
Web Site: www.IndieDevSpot.com
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.
Bizspark and Dreamspark Bizspark is for anybody trying to make money from developing apps for windows
Dreamspark is for students.
What is Dev Ops? Development Operations
How to run an innovation organization, the right way.
Great, but what does that mean?
1. Come up with an idea – but use an agile management system
2. Build that idea – but ensure you keep track of your various versions so you can build new ideas
3. Test that idea continuously – preferably in an automated or controlled fashion
4. 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.
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.
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.
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.
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?
Sprint PlanningBacklog grooming
Any dependencies or blockers for various work items.
Special considerations
Rough Estimates (I prefer Fibonacci) for tasks
Capacity Planning
Initial assignments
Sprint Execution Standard Day:
1. Morning standup meeting (box it to 15 minutes)1. Break out to other meetings if its more than a status, but raise awareness here.
2. Execute on your tasks with your team.
3. 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.
Testing and Stabilization1. 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.
2. Always save at least 20% of your Sprint for testing and stabilization for this.
3. 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.
Delivery to Stake Holders1. This is typically a meeting with stake holders (or QA if you are so lucky).
2. Talk about what you are delivering to Stake Holders, do a few demos of each feature and PBI completed.
3. Discuss known issues and bugs.
4. 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).
Releases Rinse and repeat for each sprint you have scheduled for your sprint, and ensure you keep tabs on scope and timelines.
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”
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
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).
Project Dashboard Cool how to section.
Work clicks
Progress bar on current sprint
Pinned items
Current members for this project
Access to Team Room
Schedule and Iterations1. Create you Project schedule.
2. Your reports are based on this.
3. Your backlog is built against this.
4. Your work items display based on this.
5. The starting point for every project is deciding when you want to release
6. I really like 3 week sprints.
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.
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”.
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.
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.
Create the PBI1. Type the name of the PBI and click “Add”
2. Double click the PBI
3. Fill in the information1. Iteration!2. Initial Effort 3. Area!4. DESCRIPTION!5. ATTACHMENTS!
4. I prefer to click Save instead of Save and Close
Add any immediately known Tasks
1. Click the Create New Linked Work Item button
2. Link Type is child, Item type is Task
3. Use a very descriptive title.
Setup Capacity Capacity is dev hours per day available.
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.
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.
Q&A If you have been holding questions, this is where you should ask them regarding this section.
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.
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.
OK, so initial set up!1. Edit->Project Settings->Editor -> select Visible Meta Files in the dropdown for
Version Control.
2. Delete your Library Folder.
3. Delete your Temp Folder
4. Initial Check in (next slide)
Order of these operations is VERY important.
Connect to your project1. Open Visual Studio 2013
2. On the top tab bar, navigate to TEAM -> Connect to Team Foundation Server
3. Click the Select Team Projects… link
4. If you see your Server from the list, select it, otherwise add it.
5. Select your project collection and the project.
Set up your local workspace 1. Click Source Control Explorer
2. Select your project, and then click the “Not mapped” link next to Local Path:
3. C:\projects\Spritzer
Check In1. Create a folder called “Main” and copy your Unity Project (minus Library folder) into it.
2. Right click in Source Control Explorer and select “Add New Items”
3. Select the new main folder.
4. Click Next
5. Click Finish
6. Notice the green plus marks. This means the items are added, but not checked in yet.
7. Right click Main from Source Control and select “Check in Pending Changes”.
8. Under Comments, type “Initial Check in!” (notice you can associate work item ids).
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.
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
Always Create a lock on binary files.
1. Right click the file you wish to lock within TFS source control
2. Navigate to Advanced
3. Select Lock
4. When you finish your changes and check in, the locks will be removed automatically for you.
Revert Changes1. Right click on the section of the folder structure
you want to revert changes for or see history.
2. Select View History
3. Find the changeset you wish to roll back.
4. Right Click and select “Rollback changeset”.1. 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 .
5. Click Take Rollback Version
6. Check in your changes!
Undo Pending Changes! Right Click -> Undo Pending Changes.
Undo Changes
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.
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.
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
Sample Development 2 (Spritzer)
2 coders.
2 specializations. Windows and iOS with a target to deploy to Windows 8.1, 8 and Phone first.
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.
1. Branch names must be unique and how Unity detects scripts, folders etc
2. 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.
How to create a Branch Right Click the folder in Source Control you wish to convert to a branch, hover over: Branching and Merging, Convert to Branch.
To create your dev branches for Sample 1: Right click main for each child branch of main (all 3) ->Branching and Merging->Branch
Branch Integration Ideally: Every Morning.
Realistically: once every week.
DO NOT: go longer than a week.
How to do an integration:
ALWAYS FI before you RI!!!
Example: lets say we want to merge our work from Windows_Dev to release to the iOS and Android team to see how that works with their stuff.
Merge Main to Windows_Dev first. (this might be painful)
Then test your branch.
Then Merge to Main (this should be painless).
How To! Forward Integration:
Right Click Main -> Branching and Merging -> Merge
Select Dev_Windows for the target.
Always take latest unless you are doing something special.
Click Finish.
Resolving Conflicts You will usually run into conflicts.
Most of your code ones will be resolved automatically.
Your binary ones will be tough.
Remember you can view history (Right click view history) and do that on the files you see that are in conflict, see who made changes, pull them into a room and bang it out.
Test your Dev_Windows branch to make sure it works as expected with your changes.
Once it works, perform a check in! Always comment a merge as an FI or an RI with from and to branches
Reverse Integration This is when you are going to make changes available to the rest of the team.
Same process as with main, just in reverse.
Right click Dev_Windows -> Branching and Merging -> Merge
Resolve conflicts, test your main branch and then perform a checkin.
Excluded Changes If you have pending changes during the process for any of your branches, make sure you check those in first then perform the merge again.
Summary So that is how you do a typical Development Cycle.
Q&A before we talk about release.
Release Management1. Products don’t always work in
release.
2. You have to fix them
3. You want to integrate those fixes back into your dev cycle
4. This is facilitated through Branching and Merging
How to get your structure set up!
1. Create a new folder called “Release_1”
2. Check it in.
3. Branch from Main, name the branch Release_Main
4. Move Release_Main under the folder Release_1 (Right click Release_Main-> Move and browse for Release_1)
5. Check it in.
Release Push all of your packages out to the store from Release_Main’s build outputs. Any modifications you make here, treat this like a Dev branch for now. FI then RI until you have working releases.
NOTE: If you get all packages out to all stores with this one state, you are good with just Release_Main. If you release to Windows with this, and then start having to make modifications to get it released to iOS or Android, you need to make branches prior to making those changes.
Lets build the structure for if you run into trouble.
Right Click Release_Main -> Branching and Merging -> Branch
Name each branch appropriately.
Doing work in Release to initially get in stores
If you have a release team and a dev team, make sure you push Release_Main back up to Main, but DO NOT - DO NOT - DO NOT - DO NOT - DO NOT bring anything from Main down to Release_Main.
Treat Release_Main like Main and each Release_Windows, Release_iOS like each platform specific dev branch. THIS IS VERY IMPORTANT FOR THIS PART!
DO NOT skimp on the overhead here.
Continue your dev work as normal in Release just with the above notes.
YAY! You have your product in Stores!
Mark each branch with the released materials as read only!
RightClick the branch -> Advanced -> Security
Crap, something is busted in the iOS release
Step 1: File a bug and incorporate into sprint planning OK, so we have released to all stores, but one of the releases is getting bad reviews because it has a bug.
RightClick the branch that is not working (iOS) -> Branching and Merging -> Branch
Call this branch Release_iOS_hotfix. Do all of your work here until you have a fix ready to go.
Once your fix is ready, push to the store, and then push Release_iOS_hotfix into Release_iOS and delete Release_iOS_hotfix.
*note. If you have business requirements to track ALL releases ever, you will just have to create a new branch under Release_iOS_hotfix
Visualization
Propogating the fix to all releases.
1. Push your fix up to Release Main through the standard FI/RI cycle, we still treat this like normal dev.
2. Create your packages etc and release to the stores. Lock down the branch again.
3. Once this works, remove security from locked branches, push from Release Main down to each release that has been accepted.
4. Reset Security
Pushing the hot fix up to dev Step 1: Check to see if it hasn’t been fixed yet.
1. Only do the following steps if you are pushing out to all releases. Push to all releases first.1. If you are not pushing to all releases, then duplicate work and fix the bug in dev as part of the dev
cycle. Assign a new task to dev to implement the fix in dev as well.
2. FI/RI from Main to Release_Main.
3. The dev teams for each platform will pick up the release at their normal cadence.
Summary We covered the agile process
We covered using TFS to manage the agile process
We covered how the development cycle works for teams targeting multiple platforms
We covered how to actually implement this with TFS
We covered how release works for multiple platforms
We covered how to implement this with TFS
We covered how to fix production issues and incorporate it into the normal dev process
We covered how to propagate production bug fixes to all releases.
We covered how to propagate production bug fixes up to the dev cycle.
