Our current GUI deployment cycle looks like this:
(1) Without any prior notification the devs deploy a new release on Open Ledger (our only live platform).
(2) Community members who happen to find out about the upgrade report bugs introduced with the new release.
(3) Devs fix the new bugs and if the bugs are critical they make an emergency redeployment.
IMO such workflow is unacceptable at this stage.
We are live (no longer beta) and aim to be treated seriously.
It's a very bad practice to deploy a new GUI release without several people testing it first in different configurations.
What I propose is introduce QA (Quality Assurance) in the GUI deployment process by making community testing an integral part of it.
We could implement it in these simple steps:
(1) A new GUI release is announced on the forum and then made available on a dedicated (non-public) URL.
(2) We test the upgraded GUI and give feedback about any new bugs found.
(3) Devs fix those new bugs.
(4) After all bugs are fixed and no new ones are found within the next 24 hours, the new release is deployed on Open Ledger.
And just to make it clear - I'm not upset about bugs occurring, as this is normal when code gets upgraded.
What I'm upset about is that we could easily protect normal users from being exposed to those bugs and yet we don't do it.
We definitely need to be more careful about these things.
This is the time when this GUI is being showcased in business meetings and it needs to work without any new unexpected bugs or issues.
Otherwise we risk making fools of ourselves in those crucial meetings.
Topic: QA needed in the GUI deployment process (Read 3631 times)
