---
tags:
  - devops
  - company
  - management
  - note/literature
  - to-review
relates-to: "[[Starting my own game company]]"
---
# [[DevOps]]
Operating principles that accelerate iteration and deployment cycles to deliver a better product while keeping the team happy and well communicating.

## [[The three ways]]

### [[The first way: Managing the flow of work]]
Work should flow in one direction -> pipeline
Eliminate waste
Make work visible
Deliver work in small batches, frequently
Prevent defects from moving downstream
Align team towards global goals

### Waste
Waste is "not making games" -> things that do not provide value
Waste create more waste -> self perpetuating

#### Waste types
- Motion -> moving information between people or departements
	- Create self service systems
	- Make people autonomous
- Task switching
	- Batch work by type
- Defect -> something produced is unusable by someone downstream
	- Fix problems at the source
	- *Make people responsible of their own defects, correcting them in place, autonomously*
- Waiting
	- Deliver work in small batches
- Unfinished projects -> any task that has waited for too long -> context around it changes
	- Small and frequent batch delivery
- Manual processes
	- automate them
- Extra processes -> doing something you probably don't need to
	- "Can we not ?"
- Extra feature -> a feature that doesn't add value
	- Cut it
- Heroics -> crunch
	- all systems have failed, will create more of all kinds of wastes
	- worst symptom of all that everything failed

### Solutions
*Making the work visible*

Twice-weelky production meeting to populate the kanban.

Kanban structure to guide the flow of work:
- Inbox (backlog)
- To-Do
- Doing (sprint)
- Testing
- Done

- Rule 1: new tasks go into inbox, not todo as not to get derailed (focus on current work in sprint)
- Rule 2: Time is a constraint, any more work than time makes available is crunch therefore impossible
- Rule3: All work goes through the whole flow, *including tests* meaning defects are found by the people causing them, at the source, early and can be fixed before going downstream.

This structure also works for onboarding by describing the learning process as work like any other work.

#### Example
An artist sending assets to a programmer for integration should check them before sending them for errors, automatically. If anything is wrong, it can be fixed on the spot. The process for art creation can be improved because the person causing the error is also the one fixing it therefore having to deal with the consequences. This improves the workflow of that person, reduces defect and motion.
With less errors, the programmer can implement them without extra work, making them more efficient as well. If the programmer is the production bottleneck, then any work taken off their shoulder is time gained for the whole production pipeline, while time gained elsewhere may still be bottlenecked by the programmer in that case.

### Deployments
If a process is painful do it more, not less.
Confront the process to learn about it and make it better.

Continuous deployment of the game. Every change is delivered as a full deployment all the way to every target platform.
- Detect problems immediately
- Fewer catastrophic failures for a given build
- If there's one, it's easier to find it
- Quickly fix issues with deployments

*One doesn't need a perfect solution, one needs some solution and start working with it right away, improving it over time*
Any devops pipeline is better than no pipeline.

- Build automation
	- No time lost compiling builds on dev computers
	- no manual work means less defects and task switching
	- environment is taken care of by the pipeline since it always happen on the build machine 
- Patch notes made from commit messages and issue titles automatically, which remove manual work and defects (forgetting a change)
- These patch notes can be converted into checklists for the QA to track what they should test and make a feedback accordingly

## [[The second way: amplify feedback loops]]
Feedback is what allows the team to catch problems, improve processes and build quality
For QA tests, what to test should be an automated checklist depending on the patch notes. This lets one track which tests have been made, on which platforms and issues should be reported in a way that the problem is reviewed once and then automatically creates new tasks to fix the stuff.

Better feedback faster -> defects seen sooner, less waste

Systems should be made to facilitate good feedback, making it easily available to the dev team.

Some issues can be automatically tracked and created through tools like Sentry.

## [[The third way: continuous learning]]
Making work visible could help track whatever anyone is doing at anytime which should provide markers to improve where people are spending time on waste.

Bi-weekly meetings lets users only focus on too specific matters. Monthly to quarterly meetings to discuss whole pipeline issues fits well. Questionnaires can help to gather inputs and use this to help improve the processes.

Everyone has the right to experiment -> culture of psychological safety to let people try and learn new things

*The work culture is a result of the structures and processes you use -> people are only as good as the systems they work and develop themselves in.*

Make the culture about learning.

---
# References
- https://www.youtube.com/watch?v=t9HRzE7_2Xc&ab_channel=GDC