FAQ is definitely the main goal for me in the Quarter along with just genreal tone setting moving forward. Will let @niskhakova comment on the labels piece.
Open to suggestions on how it can be organised. Another option can be to create a single OKR for identified activities in gitlab-org/quality&40 (closed) and sub-OKRs for scheduled issues assigned to DRIs.
I would strongly urge not exploring that one right now. That's essentially the biggest piece of potential work for all of GET by a large margin and one of such a size that I'll need to lead the efforts on to spike and plan as to bring all of our learnings from Terraform into the design approach as well as ensure it's design works with GET overall.
We don't have the capacity right now to explore this right now. Was planning on exploring this more once we hit our maturity goals with GET as is and will be happy to bring in folks for the ride.
We've got quite a few OKRs discussed but we'll be doing these anyways yeah. Contributions will be more living document sort of deal though so maybe best to leave that out.
Yes, the replication timing would be a good second issue to pull in, adding the improvements to try and pole directly from a bucket instead of via the secondary GitLab instance.
@ksvoboda unfortunately can't predict that yet, so far building OpenShift cluster and CNH is much more involved than expected. There was another customer interest in OpenShift + Operator yesterday and they would like to evaluate it, and move within 1-3 months. Since there are 2 customers now, and they aim at Q1 - we need to test this configuration and validate production readiness. If it can be tracked as an OKR, I can create issues related to this effort if that can be helpful?
thanks @niskhakova ! I am okay with the plan you have mentioned of at least the identifying of additional scenarios being looked at in Q1
If it can be tracked as an OKR, I can create issues related to this effort if that can be helpful?
Yes, please do create issues - we can also take a look and see if this would be good to also keep track of in an epic. We should look to track in an OKR
Thanks for the clarification on this! Will be asking team on Leads meeting if there is an existing epic/issue for Operator production readiness. In the meantime, created #1616 and found few older GA related QE issues for operator that I think will be needed for this - #965 (closed), #935 (closed). Perhaps they can be tracked as Q1 OKRs?
Did you want all 4 for Q1? We can have the main OKR of: Improve test coverage and documentation for FedRamp and the 4 items listed as sub OKRs to that?
I'd like to get all 4 done, but not certain how realistic that is. We could start with #1595 (closed), #1594 (closed), and #1501 and bring in #1421 once I've finished #1595 (closed) and we've determined it's achievable or if we want to stretch, put in all 4 and see how it goes...
@ksvoboda - Looks like the team just logged gitlab-com/gl-infra/gitlab-dedicated/team#1554 as a follow-up item for BYOK. This could be a helpful place to do some hands-on experimentation and see if we can make any ground in left-shifted testing.
I think they're also having some trouble with gitlab-qa runs in their review apps, and could use a set of eyes who are more familiar with the suite, but I don't see an explicit Issue for that.
Thank you @bwilkerson13 , these are great suggestions. Few things that come to mind for Dedicated in general are:
Define testing strategy for SaaS platforms.
Any pipelines that need to be run to validate the work they are currently doing?
Identify biggest pain point Dedicated team is currently facing that we can look into.
Test gap analysis for Dedicated. This won't be the traditional test gap as I dont see them having e2e test since they dont have a UI (I believe Switchboard would be UI component) but perhaps performance testing, load testing can be incorporated.
I've created gitlab-org/quality/quality-engineering/team-tasks#1611 to track conversation for this, and I have a sibling Issue at gitlab-org/quality/quality-engineering/team-tasks#1607 for the anything specific to FedRAMP controls.
Identify biggest pain point Dedicated team is currently facing that we can look into.
I'm still building relationships and learning from the team, but I had a chat last week(?) and getting the standard smoke/reliable suites working consistently against their MR review apps was called out as something that would be a huge confidence booster for the team. Right now they have to wait until UAT to confirm and action failures.
Test gap analysis for Dedicated. This won't be the traditional test gap as I dont see them having e2e test since they dont have a UI (I believe Switchboard would be UI component) but perhaps performance testing, load testing can be incorporated.
Their infrastructure provisioning still requires some amount of E2E testing. They have static analysis that covers critical basics and safety checks, and they've devised a small suite of integration tests at least in Instrumentor, but they're expanding into configurations that have some amount of logic to them (like BYOK) so I think it's a necessary analysis. Performance and load testing is also a good call out!
Perfect, this is awesome @bwilkerson13. Thank you for creating issues to track the asks. One suggestion I have would be to have an epic to capture all Test efficiency/pipeline needs for Dedicated so it will be easier to share asynchronously our roadmap.
This MR - gitlab-com/www-gitlab-com!117917 (diffs) shows what the Dedicated team is planning for Q1 and Q2 primarily. Please review and feel free to propose action items can we take in Q1 to adequately support their roadmap.
Thank you @vincywilson! Their Q1 and Q2 goals look focused around BYOK, Switchboard, and general operations at this point. Switchboard is a UI app and we have documented practices for those already that the team can follow, so I think (with what I know now) that the most good we can do right off would be to support BYOK with the pipeline and efficiency work as mentioned.
@ksvoboda Can I suggest the two line items rolled into gitlab-org/quality&42 as the action items instead? It will be some good hands-on learning for me, I will still learn something about coverage and gaps for gitlab-org/quality/quality-engineering/team-tasks#1611 and gitlab-org/quality/quality-engineering/team-tasks#1607, and I think solving even just the MR pipeline problem would have a positive impact for the team.
I'd like to get all 4 done, but not certain how realistic that is. We could start with #1595 (closed), #1594 (closed), and #1501 and bring in #1421 once I've finished #1595 (closed) and we've determined it's achievable or if we want to stretch, put in all 4 and see how it goes...
@AndyWH - for now lets go with #1595 (closed) and #1501 - #1594 (closed) (keep up to date with findings throughout quarter and later add to HB) + #1421 we can revisit in Q2 based on findings from these 2 issues. #1421 would be good to keep in mind as we learn more on FedRamp throughout Q1.