Release Management

People Merging things to master that breaks the systems tests
making sure that anything merged into master has been tested

• i've seen changes merged to entities master branches (such as service-entities-vehicle) before the service-api-vehicle branch has been tested. is this because the current architecture requires any changes for entities-services to be in master in order for the service-apis to be tested?

Discipline everybody needs to follow the structure

Run the builds on branch

1. Enable create PR environment, puts comment on pr on where to get, no manual checks to get it running.

   1. The QA time to test will be less,

   2. more people can also review before it goes to master.

   3. Systems tests can be pointed to different environment and run against that environment

   4. Only replicate default stack in local environment

2. Stacks we use headers to instruct api's to use header in certain ways…

   1. saves time in bootup QA environments

   2. single entity touching multiple api’s

1. This solution may not be technically viable, very time consuming to setup per branch and complex to spin up the full stact.

   1. To counter this, it’s possible that rather than replicating a full dev environment, really what we need to replicate might just be local development via regulatory-platform.

Spike - investigate if the full stack can be spun up locally, incl db. then this can be replicated in any environment;

Spike - If DB is a problem, or there are resource constraints, potentially look at partial stack deploys, using headers to configure QA apis to talk to multiple dbs, or shard the db in some way.

There is no clearly defined ownership of repositories (relating to teams) resulting in inconsistent code patterns and no authority/ownership of issues/tech debt related to a repo.

Creating a RACI on teams, who owns what and etc. make doc official.

document list

@Jigar Sheth , template page

A single change (or lack of change across multiple services in a synchronised way) can cause major problems to the entire application, blocking unrelated feature releases and development.
For example

• an update to entities that does not carry over to another api can stop the Apollo build resulting in all API features not to be released.

• a client side change by one team can break the entire client regardless of the container the change was made to.

• a change in the common folder of an API which the client depends on can prevent a build and PRs being merged.

• both internal and third party dependancy upgrades must be done across multiple repos in a synchronised way to prevent breakages.

Isolating Environments,

think about integrity

What infra is required

security concerns and patterns

• then create code for services to talk to each other and identify management structure aswell

This will isolate problem to just 1 services, and identify ownership and technologies we use

might look at new tech to use and form part of the tech roadmap going forward

Will create cross dependencies.

A single query that crosses domains becomes hard

Steps to take:

1. Take to COP and get approval

2. Setup Working Group

3. Get Smokin

Forming Arch and retrofit into all dependencies etc……

Working Group looking at the options and making decisions

@Tom McQuarrie - Portal

@Alex Chan - WA

@Brett Niven - Spatial

@Jigar Sheth

@Gregor McIntosh , if QA is required

@John Barry key man

@Paul Tudman & @Emjee Dercksen for socialisation

When we come across a bug during system testing, how quickly should we deal with it?

Sometimes, we spot a bug but don't fix it right away. This can be a bit challenging, especially if we're aiming for a perfect pass rate in system testing before merging to the master branch. It can become a bigger problem if the bug is causing multiple tests to fail.

Letting these bugs linger for too long can hide other bugs, potentially causing more significant issues than the original bug.

Poor visibility when things break: system tests, build pipelines, apollo graphql builds.

builds failing inconstantly due to arbitrary things - timeouts - ip restrictions etc. where the "solution" is to retrigger the build

To effectively handle the interdependencies among various server entities (server-entities-) and utilities (utils-) that are utilized by multiple server APIs (server-api-*). The primary objective is to ensure that all server APIs consistently use the same version of the underlying entities. (JS)

Do we have enough people who have permissions to release? Thinking for both V1 & V2.

Who should be able to do a release - QA, TL, PO?

Storybook load times and refresh times are far too slow

Keeping our dependancies up to date and passing security audits across multiple repos.