Skip to content
Snippets Groups Projects

Mark Delivery FY20Q2 OKRs

Merged Mark Delivery FY20Q2 OKRs
mj/delivery-q2-fy20-okrs into master
Merged Marin Jankovski requested to merge mj/delivery-q2-fy20-okrs into master

@gitlab-org/delivery @mayra-cabrera @nolith I've added provisional numbers for our FY20Q2 OKRs.

From each team member I expect to hear:

  • GOOD - what went well
  • BAD - what went poorly
  • TRY - what we should try as a team and as individuals in the team.

For your convenience, copy the following into your comment and fill with details on whether you agree/disagree with the numbers (for the OKR's applicable to your work):


### Delivery FY20Q2 OKR results

* Streamline GitLab deployments on GitLab.com and self-managed releases => 100%
  * 
* Migrate GitLab.com registry to K8s and have it autodeployed as part of release process => 50%
  * 
* Complete GitLab codebase merge => 70%
  * 
* Implement storage limits => 50%
  * 
* Implement single object storage => 0%
  * 

### Delivery FY20Q2 Comments

* GOOD
  1.
  1.
* BAD
  1.
  1.
* TRY
  1.
  1.

Deadline for review is EOD 2019-07-25.

Edited by Marin Jankovski

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Marin Jankovski added OKR label

    added OKR label

  • Marin Jankovski changed the description

    changed the description

    • John Jarvis
      John Jarvis @jarv
      Maintainer
      Resolved by Marin Jankovski

      Delivery FY20Q2 OKR results

      • Streamline GitLab deployments on GitLab.com and self-managed releases => 100%

        • Releases feel much more streamlined and we increased the number of deployments in all stages considerably so I think 100% is correct.

      • Migrate GitLab.com registry to K8s and have it autodeployed as part of release process => 50%

        • I would score this a bit higher, 60%? We have registry running in kubernetes on staging, working on the readiness review for production and I don't expect a full quarter of work to get it over the line.

      Delivery FY20Q2 Comments

      • GOOD
        1. Reducing release toil be streamlining deployments
        2. Kubernetes demos were late in the quarter but what we have been doing so far has been helpful
        3. Considering the disruptive process changes that came with auto-deploy it went surprisingly well
      • BAD
        1. We were very late to understand the importance of dog-fooding and we dithered a bit on decisions like using helm
      • TRY
        1. Spend more time improving process and try sprint style retrospectives, I think this will help us manage priorities a bit better if we put more attention on unplanned work
        2. We spent more time on release auto-deploy related work than anticipated, perhaps we should be less aggressive with our goals?
      Edited by John Jarvis
    • Yorick Peterse
      Yorick Peterse @yorickpeterse
      Contributor
      Resolved by Marin Jankovski

      Delivery FY20Q2 OKR results

      Streamline GitLab deployments on GitLab.com and self-managed releases => 100%

      I think this went quite well, and we went from deploying maybe a few times per month to deploying a bunch of times per week (at least to staging and canary). I also liked the various handbook changes to clarify that work is not done until the code is running on GitLab.com, something we probably should have done much earlier.

      Migrate GitLab.com registry to K8s and have it autodeployed as part of release process => 50%

      I was not involved in this, so I can't comment on the matter.

      Complete GitLab codebase merge => 70%

      I think we made a lot of progress, though the goal of May 22nd was too optimistic. I recall we did have some issues early on with other teams not prioritising their share of the work, even though it had been made clear that this was high priority work.

      One big challenge for me was the large number of unknowns. Since we are merging two big many-years-old projects, there are a lot of issues you may discover along the way. Some were easy to deal with, others took days of even weeks.

      Implement storage limits => 50%

      Not involved, so can't comment.

      Implement single object storage => 0%

      Not involved, so can't comment.

      Delivery FY20Q2 Comments

      • GOOD
        1. Single codebase work advanded nicely
        2. The auto deployer is working well so far
      • BAD
        1. Not as much progress was made with the single codebase project as hoped for
        2. Not all teams prioritised the single codebase work as well as they should have (at least early on)
  • Yorick Peterse unassigned @yorickpeterse

    unassigned @yorickpeterse

  • John Jarvis unassigned @jarv

    unassigned @jarv

    • Alessio Caiazza
      Alessio Caiazza @nolith
      Maintainer
      Resolved by Marin Jankovski

      Delivery FY20Q2 OKR results

      • Implement storage limits => 50%
        • I think here we were in a very uncomfortable spot. From the Engineering perspective, we found so much tech debt that we had to slow down and fix problems. Also this ended up as a multi-product-categories kind of feature, and many of the things to implement where Product/UX decision, but we have only backend engineers and a shared frontend engineer in our team
      • Implement single object storage => 0%

      Delivery FY20Q2 Comments

      • GOOD
        1. we shed light on differences in storage limits across the codebase
        2. we addressed a DB performance issue
      • BAD
        1. we ended up blocking each other because of the underlying tech debts
      • TRY
        1. Maybe we need a PM for gitlab.com :thinking:

      edit: added my thoughts on Implement single object storage

      Edited by Alessio Caiazza
    • John Skarbek
      John Skarbek @skarbek
      Maintainer
      Resolved by Marin Jankovski

      Delivery FY20Q2 OKR results

      • Streamline GitLab deployments on GitLab.com and self-managed releases => 100%
        • Was a security release part of this process? I'm not entirely sure this is a solid 100% due to such. Otherwise, yes. It's been great to see this change come to fruition.
      • Migrate GitLab.com registry to K8s and have it autodeployed as part of release process => 50%
        • I think this is fair. Our last demo showed a few remaining missing pieces that we still need to sort out, we still need to work on the migration strategy for production, and there are aspects of deployment methods that we've not yet discussed.

      Delivery FY20Q2 Comments

      • GOOD
        1. Our automation has improved tremendously for the release task process throughout the month. It's been a joy to see this come together.
      • BAD
        1. The Kubernetes work is not happening as fast as I'd like, but we are making progress. I have a positive outlook that we can complete this work nicely in the next few months.
        2. Some aspects of auto-deploy have caused a few pain points with Product in determining how/when to advertise the completion of features.
        3. The ability to follow along with the auto-deploy/release process is tricky, and will be difficult to teach anyone new coming in. There's a lot of tooling in a variety of projects, many many pipelines and triggers to follow, and 3 total GitLab instances all involved to make things work properly, it's a tad mind boggling.
      • TRY
        1. Provide feedback for Product. There are places where we utilize the product well, and other places where we could potentially abuse the product to force it to do something interesting that may be a benefit to others.
        2. May be planning better? Prime example is the Kubernetes work. Between moving quickly and running into road blocks late and creating something that we didn't fully think through, has lead us in directions that were not entirely anticipated or planned for and provides the appearance of us moving slower than we'd like.
        3. We should demo more often for every major project. This is a time to celebrate the success and provide a way to show off to others the improvements being made over time.
  • John Skarbek unassigned @skarbek

    unassigned @skarbek

    • Robert Speicher
      Robert Speicher @rspeicher
      Contributor
      Resolved by Marin Jankovski

      Delivery FY20Q2 OKR results

      • Streamline GitLab deployments on GitLab.com and self-managed releases => 100%
        • :thumbsup: Agree with Skarbek though, without a security process improvement I don't know that we're at 100% quite yet, but it's damn close.
      • Complete GitLab codebase merge => 70%
        • :thumbsup: we're pretty close.

      Delivery FY20Q2 Comments

      • GOOD
        1. Huge improvements to the release process. We've practically eliminated preparation MRs and cherry-picking (for pre-release), while deploying more often and with greater confidence.
      • BAD
        1. Security releases are still delicate and require human toil.
        2. Broken master is still a huge issue, albeit one we're not directly responsible for. Many of these are due to CE changes breaking EE unexpectedly and will be resolved by single codebase.
      • TRY
        1. In retrospect we punted some dog-fooding opportunities because the product wasn't viable for what we wanted yet, and wouldn't be in the timeframe we thought we were trying to hit. We could have moved slower up front in order to improve the product for everyone.
  • Mayra Cabrera unassigned @mayra-cabrera

    unassigned @mayra-cabrera

  • Alessio Caiazza
    Alessio Caiazza @nolith
    Maintainer

    added my thoughts on Implement single object storage on !26287 (comment 194427880)

  • Alessio Caiazza unassigned @nolith

    unassigned @nolith

  • Robert Speicher unassigned @rspeicher

    unassigned @rspeicher

  • Marin Jankovski added 2442 commits

    added 2442 commits

    Compare with previous version

  • Marin Jankovski resolved all threads

    resolved all threads

  • Marin Jankovski merged

    merged

  • Marin Jankovski
    Marin Jankovski @marin
    Author Owner

    @glopezfernandez FYI.

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply