deft/notes/cisco_staging_environment_kick_off.org
Yann Esposito (Yogsototh) 0110eee062
save
2024-02-01 15:16:14 +01:00

1.8 KiB

Cisco: Staging Environment Kick Off

Staging

As I understand. Exactly the same as TEST, but with the same ops machine than prod. Main issue is that TEST/PROD have different configuration. With this strategy of STAGING, this does not solve this issue. Because by construction STAGING will also be different from PROD.

Differences with PROD:

  • content of the DB

    • URL of all integrations
    • OAuth2 Clients
    • Specific Technical Orgs
    • Customers Data (Orgs, Users, objects)
  • configuration of the API

    • URL of all integrations
    • OAuth2 Clients What does it take to re-configure a new environment?

It took many years of work from many different teams, where most point of contact have disappeared now.

So an undefined amount of work not only from Ops, but mostly from IROH + every other team that integrated with IROH (SecureX / XDR). If possible it will take a non trivial amount of time from every team involved.

Instead a proposal: Canary release

Create a Proxy that will redirect some predefined users to the new deployed nodes.

So QA users will use v2 while customers are still using v1.

Once QA is successful, take 10% of users and move them to v2. Once charge is verified and ok, move 100% of users and move them to v2. Deployment finished, test made in real PROD by QA.

Not only this is a lot better for QA, but this looks possible while initializing a new Staging does not appear doable at all if we want to achieve the goals of improving releases quality.

Requirements

@Anthony_Brandelli

  • cross-integration environment (test - prod / int - test)

Not looking for big scaled prod env for staging.

Concerns

What is IROH the backend that makes XDR/SecureX possible. This is a platform.