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

Investigate and scope additional staging environments #952

Open
robertjmccarthy opened this issue Nov 21, 2024 · 2 comments
Open

Investigate and scope additional staging environments #952

robertjmccarthy opened this issue Nov 21, 2024 · 2 comments
Assignees

Comments

@robertjmccarthy
Copy link
Contributor

What

Investigate what and how multiple staging environments could look like.

Why

Currently we have a live and staging environment. With a single staging environment this makes it difficult to display multiple pieces of work which may be in progress. Whilst prototyping can be done on a local machine, sharing work proves difficult with a single staging environment.

Who needs to be involved

  • Developer

Done

When the team's developer has an understanding of what and how multiple staging environments could look and work like for the MoJ DS site. This work is not to undertake the actioning of multiple staging environments, but to investigate and scope what it could look like and how it could be done.

@chrispymm
Copy link
Contributor

Here is a sketch of how I think we'd want this to work

We move our current staging deploy from being tag based to branch based, and we have a dedicated "staging" branch

We then have a system similar to what we have now, where a a label can be added to a PR to trigger a deploy to a "test" site.

This would then deploy the branch out to the "test" site with a url like https://moj-frontend-{branch_name}.apps.live.cloud-platform.service.justice.gov.uk

We would also need an automated action to teardown the test container once the branch is merged.

Questions

Does everything have to go through staging?

This might create additional friction and slow things down. if the work is standalone and has been approved on test, forcing a merge to staging (and deploy) and then a merge to main might be annoying. Equally having merges from "test" branches, might make staging a bit redundant. It would only really be of benefit when we have two different things in test that we want to preview together, before deploying.

How does the domain work?

Deploying out a container with a dynamic ingress based on the branch name is relatively straightforward. How does the subdomain get connected to the ingress? Do we have to dynamically create DNS records? or do cloudflare setup a wildcard somehow?

@chrispymm chrispymm moved this from To Do to In Progress in MoJ Design System: Team planning Dec 2, 2024
@chrispymm
Copy link
Contributor

As a first investigation, I've contacted Steven Leighton, on the MOJ Forms team, as I know forms has this same test functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

2 participants