Deploying changes to your web-based application, even multiple times per day, is shown to be helping teams immensely in creating better products faster but it is not always that easy. One common problems teams start to get when they have 5+ developers working on the same product is that they may occasionally be blocked by others when deploying to the same staging environment.
The staging environment, which is similar to the production environment, is an important component to deploying often in order to verify that the changes work and to validate that they solve the main problem. It allows developers to create a preview of how it will work in production without releasing something that may not be ready.
The way continuous deployment systems work today is that they listen for new changes on a specific branch in the version control system such as GIT and then trigger a new deployment. Developers create pull requests to merge their changes to this common branch that is used to deploy to their staging environment. Once their changes are merged, other developers changes need to be applied on top of the changes the previous developer has made. This is where the problems start to appear.
Regardless of how detailed the feature specification was, it often happens that when the developer feels confident that the work is done, the changes are merged to the staging branch and deployed to the staging environment for final validation testing. The product manager, QA tester, and others can now easily test the changes. However, they may realise that it is not working correctly in some cases the developers missed, the UI designer sees a problem in the design that might not even have been the developers fault but could not have easily been foreseen until now. This is completely normal and nobody is to blame for this. However, now, the developer who might already be busy working on other things, need to make some additional changes before it can go to production. Meanwhile, multiple other developers have made some changes that did not need iteration and should preferably go to production right away. To great annoyance, these changes can not be deployed because they are blocked by the changes that were previously merged before that were not ready.
The solution to this – to still allow teams to fail fast, collaborate, learn and iterate – is to have separate staging environments to preview changes in isolated environments. Only once validation testing is complete are the changes merged into the common staging environment where you can make additional testing together with other changes or directly deploying to production.
Setting up a new staging environment for every change you make manually is infeasible if you want to move fast. For this, you need to invest in an automated solution for it that can integrate with the version control system for your code, automate the deployment for changes to new pull requests, share a link to where your colleagues can test the changes and then finally removing the staging environment when it is no longer needed.
As we all know about working with software development, it often requires many iteration to get it right. The faster we can iterate, the faster we can get it right and deliver a better solution for our users, which is paramount to continuously learn and create value for our business.
Valist enables your team to automate the deployment of previews for every new change you make to your application or website and distribute a link to where the preview can be tested.