Page MenuHomePhabricator

investigate setting up a staging version of payments wiki
Closed, ResolvedPublic

Description

As an Advancement designer I would like a staging version of payments wiki so that I can test specific donor flows. What will it take to set this up and maintain it? Do we need another server?

Design Decisions

  • Do we need another server? Nope, payments1004 is available.
  • Determine whether staff users will ssh tunnel or we will expose the frontend on a public IP and add client cert authentication. [client cert auth]
  • Determine what hostname staff users will use to reach the frontend. Proposed: payments.frdev.wikimedia.org [payments-staging.wikimedia.org, payments.wikimedia.org]
  • Determine how payments-staging works in terms of the queue. Separate payment ID? Separate queues? [no queue separation to start]
  • Determine how payments-staging works in terms of payment providers. [payments-staging.wikimedia.org and dedicated IP will have to be added to provider allow-lists]
  • Determine who will need access to make wiki changes. [same as production wiki content to start]
  • Is there any reason we would need to change how code deployment works from the current model where only fr-tech developers can deploy changes via FR Deploy? [no change needed]
  • How will we review and deploy staging database changes to production? [same as production]
  • How will we review and deploy staging code changes to production?

Configuration Changes

  • Detach payments1004 mysql instance, configure it read/write locally
  • Adjust routing/NAT for payments1004 to isolate from payments, and possibly make it accessible without tunneling
  • Adjust firewall configuration (payments1004 will remain in PCI scope)
  • Remove LVS configuration from payments1004
  • Establish separate payments-staging role in puppet
  • Reestablish 'staging' project localsettings and puppet payments-wiki configurations
  • Reestablish separate 'staging' project in FRDeploy tools
    • read/write to local-staging mysql instance instead of payments cluster mysql
    • staging queues
    • local-only staging memcache
    • switch to development payment provider APIs
  • Make sure the new payments-staging IP is whitelisted at each payment provider
  • Adjust payments-staging logging and log collection to separate from payments logging [not separated]
  • Adjust monitoring for payments1004
  • Configure backups as needed. [no special backups needed]
  • Develop a pseudo queue consumer to at least clear the staging queues periodically

Related Objects

StatusSubtypeAssignedTask
ResolvedJgreen
ResolvedJgreen

Event Timeline

Mostly from today's fr-tech/fr-tech-ops meeting, how we architect this really depends on what we need in terms of backend and endpoint handling.

Host on frdev1001

  • this is more of a 'testing' approach
  • good if we don't need accept/process payments
  • we'd keep it behind client cert authentication
  • we'd either turn off message queueing or inject to a local redis instance
  • frdev1001 may need to make outbound API requests to payment providers
  • since the ccard numbers are fake and it's all dev APIs, it wouldn't be in PCI scope
  • avoiding PCI scopes is more flexible in terms of code and UI testing

Host on payments1004 or the inactive datacenter

  • this is more of a 'staging' approach
  • only makes sense if we need to handle real payments
  • already configured for outbound request to provider APIs
  • it would probably be in PCI scope, constraining code/UI testing
  • would probably require SSH tunneling

Notes with stakeholders April 7th.

  • Reasons we haven’t done a staging environment yet
    • Dstrine hasn’t seen a payments staging environment work exactly like production
    • Some sandboxes have fake cards, but there will always be slight differences between fake experience and actual donor experience
  • Payments Wiki UI, copy changes, etc. could be tested on a staging environment
  • Staging environment transactions would not show up in civi, so no content (like TY emails, 2nd TY email for convert) would be triggered by civi
  • Difference in production and dev environment are why fr-tech hasn’t actually set up their own staging environment

Tasks fr-creative is interested in working on

  • Add payment logos to the form variant that just includes a Continue button
  • Add a tooltip to the PAN field for dLOCAL
  • Test monthly convert designs / copy
Jgreen updated the task description. (Show Details)

Moving from FR-Ops back into Triage because afaict this is not blocked on fr-tech-ops, we'll need design decisions about how we want queues and payment-providers to work to proceed.

Jgreen claimed this task.
Jgreen triaged this task as Medium priority.
Jgreen moved this task from Watching to Done on the fundraising-tech-ops board.