Delivery Circle - 31st Jan 2023

Product Development Process
1

Topics

  • Update meeting time? Agreed to meet 1 hour later (8pm AEDST)

Automated tests for API v1
How do we test requests (end-to-end)?

Google Analytics in place of Matomo. Would it be a good idea to use GA for one instance?

  • Adds complexity to deployment and cost of maintaining
  • These tools may measure differently, so it would be difficult to compare between them

@dcook
Working on webhook for order cycle open event; was stuck last week but hoping to finish this week.

@filipefurtado
Adding lots of specs

Konrad not well unfortunately, so not working at the moment.
Filipe may increase his hours and Rachel will try to help too, to keep testing tasks moving.

Can we reduce the amount of manual testing work?

  • dependency updates: David suggests we don’t need all of them to be tested
  • translation updates: also don’t need testing

Decision: for any small thing that could already be covered by the Release testing, we can consider skipping manual test. (see release testing doc at top of #testing channel Template - Google Docs )

@abdellani
Enterprise fee report: do we include order co-ordinator fees? @lin_d_hop to confirm.

Deleting shipping method: blocked on questions on issue.
Is this PR blocked or can the change be another PR? Need to compl

If an order was completed, we cannot change the shipping method or cost (it’s illegal!).
When is an adjustment closed?

Gaetan
Fixing bugs,
Fighting docker in dev setup but system specs won’t work, so resorted to normal dev setup.

Haven’t heard about Vouchers starting up. @lin_d_hop is waiting for Jess to complete designs, then she will create tickets.

If devs are ready before issues are defined, what are the next priorities for Gaetan?

  • DFC
  • Tax reports, if blocked
  • start with vouchers without final designs? No – the visual and the UX / logic is still yet to be designed.
  • Backoffice UI uplift, could do one discrete issue to work on before vouchers starts. @Rachel to prepare notes to continue #8930

@maikel
From Slack:

  • Resolved a problem with background reports but there may be another production issue we need to test once the current PR is deployed.
  • Made progress on DFC but wondering about its priority amongst other things.
  • Split Checkout doesn’t have any open issue at the moment. New issues or new priority?
  • Metabase should be solved. :crossed_fingers: that performance won’t be an issue.
  • Got some minor tech debt done.
  • My favourite circle time would be one hour later. Half an hour is also fine. Everything can change at any time though, kids develop quickly.
  • What’s happening with vouchers? Gaetan and I are supposed to work on it soon but I’m waiting for a kick-off.

Meeting about Docker: yet to be organised.

1 Like
2

I’m sorry I couldn’t be at the meeting earlier. Here are some additional thoughts.

Rails discourages controller tests because the input to the controller is artificial and can differ from request specs which include routing etc. So the recommendation is request specs.

We do have that gem already. And we have a request spec using it: spec/requests/api/v1/customers_spec.rb

There are some caveats but that’s the way to go, @filipefurtado.

In instance could have Google Analytics in addition to Matomo if they want to, I guess. @Rachel

Maybe the PR author can at least stage the branch and visit the home page to make sure that there’s nothing obvious? I would love all PRs to go through staging because we had some issues only arise on deployment, especially dependency updates. @dcook Was this option 00discussed?

3

Good point @maikel, no I didn’t think to suggest that. That would be a good way to reduce work on testers.

Although these would still go through staging when the release is tested. So a failed deployment would be picked up during release testing, but it could delay a release while we fix the problem, as opposed to fixing the problem early.

So I still question whether we would need to stage small dependency updates. (For major version changes or critical gems like rails or stripe, of course I would still suggest further testing).

4

Previously, we didn’t used to deploy on staging and test small (ie. patch or minor version with green specs) updates of our dependencies.

So, I assume we decide to not change anything to our process regarding that particular point? Or may I missed something?

5

I thank @dcook for bringing this up :pray:

Previously, we didn’t used to deploy on staging and test small (ie. patch or minor version with green specs) updates of our dependencies.

Indeed this triage was already done before. The other proposal was to merge translation PRs after code review directly - I did not think of it during the meeting, but I must say sometimes there are critical issues around transations as well. So, I’m not sure.

So, I assume we decide to not change anything to our process regarding that particular point? Or may I missed something?

Following up on the discussion here I guess the only change would be @maikel’s suggestion (above):

the PR author can at least stage the branch and visit the home page to make sure that there’s nothing obvious?

I think this is up to the dev team - but I’m not sure though this brings real improvement. Sometimes there are issues around staging, servers, deployment… Unrelated to PRs. Could this become a hurdle for devs and break work productivity? Maybe we’re creating an issue to solve another, I don’t know.

I’d rather propose to hire more testers, if the current workload becomes unmanageable. I think good triage and great notes on what to test are already a great help.