Updated Gitaly OKRs

controller ➞ service. This terminology fits better.

features ➞ migrations. We will work on other features (for example logging) but our goal is to deliver a large number of migrations.

Also, the Gitaly team's focus is moving from controllers to endpoints.

Why?

• Controllers can share endpoints, but the effort is spent building endpoints, so there is not a one-to-one relationship between controllers and effort, whereas there is between endpoint and effort.
• Our feature toggles, dashboards and alerting are all built around endpoints, not controllers.

So far we have built 15 endpoints, so building another 25 is ambitious. However:

• Our process is now working well
• Our tech stack is maturing, meaning we can focus on migrations instead of setup features (eg logging)
• Our understanding of new tech, like grpc, has improved

However, 25 endpoints is just slightly more than one endpoint per iteration per developer (although the actual effort will be parallelised) so I think we can do it.

You made it 24 though ;-)

@ernstvn

Oops! Yes. I've fixed this. I used a back-of-the-envelope calculation of 4 developers x 6 iterations x 1 endpoint per developer per iteration = 24 endpoints (that's not how development works, but good-enough)

Updated to 25 again.

Already merged... it's fine.

Why? Unfortunately, I predict that a large number of migrations will be not be completed on their first GitLab release.

What we're seeing is that there is a huge variety of edge-cases in production (for example, odd repos, corrupt repos, unusual requests). As we're finding, the first time we deliver a migration into production, we discover these edge-cases and need to need to perform rework in order to handle them.

However for many migrations, this means that we will need to wait for a second GitLab release before we can deliver our fixes, hence updating the goal to two releases.

(Obviously, while we're somewhat limited on our throughput by monthly release cycles, we can make up for this by increasing our bandwidth by maximising the number of migrations we're performing in parallel)

Aside: Once we have the ability to do true canary deploys, we'll be able to speed this up a great deal and change the goal to a number of days.

Works for me.

assigned to @ernstvn

unmarked as a Work In Progress

merged

mentioned in commit 90c0494a