Backlog and item prioritization
When a person, user, partner or collaborator (from Rentbrella) has an idea for our app, this suggestion is forwarded to a list called "Backlog". At this stage the product area goes into action: it prioritizes this list together with our founders and defines the next steps to be worked on. This creates prioritized items that go through a specification step. Here, all impact points of the functionality are listed and prototypes are built.
Source code and development pillars
With these specifications in hand, the ball passes to the Technology team. One or more people take responsibility for developing the source code change packages for the functionality, and this usually involves changes to various components of the solution (not just the application). Also needing to be adjusted are: elements that run on the servers and internal tools used by various parts of the company.
Transparent planning is necessary
However, even if the specification of the functionality has been done with quality, it is not possible to predict all the impacts, nor to develop the source code without introducing defects. And it is in this context that the need to ensure recurrent quality in the delivery of application updates arises.
Step by step for evolution delivery
To solve this challenge our IT team developed a rigorous process that can be summarized in a few steps:
Creating an automated test suite
Once a package of code changes is delivered, an automated test suite (with hundreds and hundreds of items) is run. All this within minutes - so it is guaranteed that the solutions behave as expected. At this point, if any item fails, the responsible party is notified and the package does not move on to the next step;
Inclusion of a teammate for review and testing
With the positive signaling of test execution, the change package is passed to another team member - this person reviews the tests carefully and tries to find/solve simple flaws. This process is effective not only for solutions, but also to ensure that the knowledge of the code is not restricted to one person;
Test in a virtual environment
After the review the package is deployed in a specific environment for testing. Virtually, this execution is equivalent to an "official deployment". This allows us to identify flaws in the deployment process, before they occur on D-day;
Collective approval and input
In this environment, everyone involved - from the person who suggested the idea, to the product sector, to other individuals who became interested in the project along the way - can validate the effectiveness of the solution and whether it met expectations;
Tools that support the process
By the time we get to this stage there are already several tools that assist the process. For example, BrowserStack, which allows you to run tests on the most diverse mobile devices;
Distribution of improvements through app updates
After the approval of all involved in the previous step, a window is opened so that the change can be distributed to users (through an app update). In these windows there doesn't necessarily need to be a single feature; there can be a number of them.
Contingency procedures
Even with all this care, problems can eventually go unnoticed and reach users. If this happens, the technology team has the power to configure the app and server components to return to their previous version. After this contingency action, there is a diagnosis, problem resolution, and a new implementation. The rollback process takes at most a few minutes and is possible due to the small size of the packages that are deployed. For this reason, there is an incentive to release packages on a weekly basis - this facilitates the rollback process when it eventually becomes necessary.
Measurement and improvement of updates
The work does not end when the functionality is deployed. After a successful implementation, we have the habit and tools to monitor the usage and identify problems or patterns of usage that are not expected. Inspired by this result, we continue to develop new evolutions, until we reach a status where the functionality is considered stable.
Simultaneous project management
The steps in this cycle are chronological, but they happen at the same time and for solving many different problems. It is an organic flow where ideas emerge, are analyzed, discarded, or prioritized.