I come from a high availability and low tolerance for bugs world: HR Payroll.
Normally we work with no less than a 3 system landscape. One for developers, one for QA and one for Production. Sometimes we even have a 4 system with Regression environment and I’ve seen even 5 systems landscapes.
Even though 4 and 5 might be just way too much for Bubble. I do see an improvement in adding an additional layer in bubble.
For some applications I do have the client or internal QA teams performing tests in the same environment as I’m developing in. This is version-test.
Wouldn’t it make sense to add a third system so that tests and new developments do not mix? It’s kind of embarrassing to be bug fixing or adding new functionality while the client or QA teams are testing.
I would be very happy to see a version-dev, version-test and version-live in bubble. It would improve the QA overall of what we are delivering.
That would mean that I have to deploy the changes that I want tested to the live version thus defeating the purpose of having them tested before deploying
Not sure I follow. You have 1.0 live and make a copy of this version.
Now you have 1.0 Live copy and 1.0 Live plus the dev veersion of Live.
You could choose to publish the copy to live as well so you can test both in dev and live (in copy). When you publish to Live 1.1 you repeat the process and refresh QA (the copy)
Let’s say I have Blue Test and Blue Live.
You are saying that I should copy Blue Live to Red and use Red as the development system.
Once I’m ready to release changes from Red I should copy Red to Blue Test.
I think it’s all very confusing and prone to deployment errors. I can understand how using several apps I could more or less achieve what I’m suggesting, but they are all workarounds that wouldn’t increase the QA but increase the complexity of deployments and add more regression bugs.
I still believe that an out-of-the-box 3 system landscape would be better.
We used to work in a similar 3-version system in Salesforce. QA was not connected to dev so a new feature needed to be built out again in the ‘blue’ version.
This i much safer than copy from red to blue. Its more work, but you want the extra layer of security. Keeping the red app completely disconnected from blue is the safest option here. So three levels:
Blue live
Blue dev (changes made here will affect blue live when pushed)
red dev/live (a copy of blue live where you can safely test new features, once approved, ready to be built in blue dev before pushed to blue live)
