Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promotable Environments (Eng) #31157

Open
dotCMS-Machine-User opened this issue Jan 17, 2025 · 0 comments
Open

Promotable Environments (Eng) #31157

dotCMS-Machine-User opened this issue Jan 17, 2025 · 0 comments

Comments

@dotCMS-Machine-User
Copy link
Collaborator

dotCMS-Machine-User commented Jan 17, 2025

Infrastructure and Config promotion

  1. A *NO-OP *change goes through the pipeline and into an environment without downtime
    1. Who’s it for
      1. As a dotCMS developer, I can be confident that my local, sandbox, qa, and production environments are consistent, so that I can separate concerns and interact with upgrade and running behaviour. 
      2. As a dotCMS customer, I want to apply a config change without downtime
    2. What does it do
      1. Allow a developer to interact with upgrades/deployments
      2. Test and interact with the init container
      3. Test that a no-op change is indeed zero downtime
      4. reproducibility between local and sandbox environments (via Helm charts)
        1. Infra config
        2. Envvars
        3. …etc  
      5. A config change should allow for restart without downtime.
    3. What does it NOT do
      1. DB and API changes would work (via init container) but with downtime
      2. It does not guarantee that something is broken beyond dotCMS server starting up 
      3. Allow for anything other than starter starter as dotCMS 
      4. Solve the need to manually update the image name/version in the values file to rollout a new version. 
    4. What is required for this to be available 
      1. Tomcat redis sessions
      2. Current -> current
    5. What sprint size things do we need to do to get there and that we can demo?
      1. Tomcat redis sessions for sandboxes
      2. dotCMS image becomes the init container 
      3. Connect helm-chart into the sandbox (sandboxes get additional functionality via helm-charts and values.yaml file)
        1. Replace scripts in sandbox tooling with helm-charts
        2. Versioning for helm charts
      4. Clean up the logs with probe where it throws exception each time it’s hit
      5. Helm charts for dotCMS cloud customers on current

Important

The end result here is that the 8 customers on current are running using the same helm charts we're using locally and in sandbox

@sfreudenthaler sfreudenthaler changed the title Infra and Config promotion (Eng) Promotable Environments (Eng) Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants