Look first, then live
The team looks at a change in an environment of its own first. Only then does it go live. That way a mistake can show up before it affects the team or a client.
LiveCreated for
Automatic test environments
Every change to the platform automatically gets a test environment of its own, so the team can spot mistakes before clients are bothered by them.
What it is
Ad Your Service is an online marketing agency. The agency built a platform of its own for its marketing work and keeps building on it itself. The team works with it, but clients use the platform too. That is why the team has to test every change for bugs and other problems before it goes live. That way clients are not affected. I built a solution that automatically gives every change a test environment of its own. It has its own address and its own data. Once the change is live, that test environment disappears again.
A changeProposed by a colleagueNew filter in the overview
Its own test environmentReady to look at
Own linkOverviewExample clientPeriodChannelNew filter
What it improves
Its own data per test
Every test environment has a database of its own. A colleague can enter or change data there. It does not end up among the live platform's data.
Connections tried out first too
A connection with an advertising platform works in a test environment too. So the team can test a change to a connection first as well, instead of only on the live platform.
The problem
BEFORE
A change went live straight away
The platform had no separate place to look at a change. So the team only saw on the live platform what a change really did. That is where the data lives that the team and the clients work with every day. That way a mistake could go straight to a client.
Live platformAs a client sees itOverviewPeriodChannelNew filterThe overview could not be loaded.
Message from a clientSince this morning our overview won't load. Could you take a look?
The solution
THE ENVIRONMENT
An environment of its own per change
When a colleague proposes a change, the automation builds a separate version of the platform with that change. That version gets an address of its own. The link is posted with the change. That way everyone who reviews it can open the test environment.
New filter in the overviewTest environment readyOpen the test environment
THE DATA
A database of its own for every test
Every test environment gets a database of its own, with a sample client to test with. That database is separate from the live platform's database.
The test's databaseNew filter in the overviewExample clientSet upEntered while testingStays here
THE CONNECTIONS
Connections work in a test as well
Connections with advertising platforms such as Google or Meta work in a test environment too. So the team can also test a change to a connection before it goes live.
Test environmentGoogleConnectedMetaConnected
THE CLEAN-UP
After approval the environment disappears
Once a change has been approved or withdrawn, the automation removes the environment and its data. Nothing is left behind for someone to clean up later.
Test environments
New filter in the overviewApproved
New sign-in pageWithdrawn
New button in the menuReady
KEPT APART
A test environment has logins of its own
A colleague signs in to a test environment separately from the live platform. After signing in, they automatically land in a separate workspace for testing. That way testing stays apart from the daily work.
Test environmentNew filter in the overviewExample clientTestCampaign with new filter
Live platformClients
How it works
From a proposed change to a change on the live platform: along the way, the change passes through four places.
Team → Automation · A proposed change
A colleague proposes a change
A colleague makes a change to the platform and submits it to the team. The colleague has nothing else to do to get a test environment.
Automation → Test environment · An environment of its own
The automation builds a test environment
The automation builds a separate version of the platform with the change. That version gets an address of its own and a database of its own. A sample client is ready in it.
Test environment → Team · The link
The link is next to the change
The link to the test environment appears next to the change. If the colleague adjusts the change, the automation updates the environment. The data the team entered while testing stays.
Team · Trying it out
The team tries the change
The team opens the link and tries the change with the sample client. That also works for a change to a connection with an advertising platform.
Team → Automation · Approved
The team approves the change
Only an approved change goes live. If the change is withdrawn, the test environment disappears. Nothing goes live then.
Automation → Live platform · The approved change
The change goes live
The automation puts the change on the live platform and removes the test environment.
What it runs on
- CI/CD pipelineBuilds a test environment per change, updates it and cleans it up again.
- Database per environmentIs apart from the live platform's database and disappears with the environment.
- OAuth connections in a test environmentMakes connections with advertising platforms work in a test environment too.
- Preview link on the pull requestPuts the link to the test environment where the team discusses the change.
The payoff
Looking at a changeBeforeOnly once it was liveNowBeforehand, in a test environment of its own
The data when testingBeforeThe live platform'sNowA database of its own per change