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

59 lines
1.8 KiB
Org Mode

:PROPERTIES:
:ID: aa8ba7b5-d4e5-48c0-9e7a-2a5adb504d38
:END:
#+title: Cisco: Staging Environment Kick Off
#+Author: Yann Esposito
#+Date: [2023-10-03]
* 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.