Planning For Application/Feature Release

https://bigwater.consulting/wp-content/uploads/2019/04/SDLC_BWC.png

Releasing a whole new application or a major feature is crucial to customers. They both have potential to go sideways and can impact customers negatively. In order to properly deploy a change for better customer experience and avoid issues, proper planning is necessary. In this article I’ll discuss the mechanism I use to develop and deploy these kind of changes. I will divide this article in 2 categories:

1. Releasing a new application for the first time and
2. Deploying incremental changes for an existing product

Release planning for a new application

Releasing a new application is a bigger task comparatively. It needs complete SDLC from scratch. The end customer will be new who’ll be expecting the application for the very first time. It is really important for the developers, product managers and other stakeholders to align on the MVP (P0, Priority 0) features. These P0 are the bare-bone features and will lay the foundation for the product. Once the application development is completed, I follow:

1. Dev testing: Very crucial and important phase. This will ensure all the aspect of the product is tested thoroughly from a development perspective. Most of the issues are identified during this phase and fixed.
2. Beta Testing: You can identify few beta customers who can use your product from a customer endpoint and test them. They’ll not have much knowledge of the internal code of your product and can test the product from a third party perspective.
3. Integration Tests: Very much important to test the functionality with various components interacting together. This will also ensure any future change will not break existing feature. You can use the framework of your choice to implement this.
4. Braveheart users or UAT: These are the identified real customers, who will use the product as end customers. These users will be using the product in controlled environment. With help of product or other stakeholders, you can identify certain set of end customers and provide them early access to your product. They will use the product and raise any bug they encounter. This will reduce the impact radius and ensure the product is thoroughly tested from customer endpoint and most bugs are resolved before it reaches to wider end customer.
5. Alarms and OE (Operational Excellence): Make sure you have all the key alarms and operations in place which will let you know on priority in case of any failures. These alarms should be pinging to right audience who can understand and fix the issue.
6. End customer deployment: Usually for any new product/major feature, It’ll be great to roll out in phases. This can be controlled by access control, group control, geographical control etc. to identify certain set of users and then provide access to them only. This will reduce the impact radius and improve the confidence in the product. By using the OE monitors, you can monitor the usage/traffic pattern and based on that you can make decision to open the access to wider audience.
7. Final rollout: Once all the above phases are completed, The confidence in the product will be high and can be rolled out to wider audience.

All the above step should be well documented and an alignment should be completed with all the stakeholders before implementation. Identified Beta, UAT and end customers should be clearly documented along-with all the different control mechanism. There should be clear rollback, SLA (Service Level Agreement), issue addresal mechanism in place. This will help your team to quickly deploy a fix.

Release planning for new major feature

This is most common scenario where a product is already in place and serving end users. In this scenario, integration tests, beta testing, unit testing etc. will already be in place. The release process complexity in this case will depend on the size/impact of feature, type of the product and user base. The intensity of going wrong in this case is high as this can impact existing customer and could bring negative impact to the product. Planning a release is very crucial to make sure existing customers should not be impacted. We should always plan for the worst while code for the best. There are ’n’ number of factors which could go wrong knowingly or unknowingly. In this scenario, I usually:

1. Identify the impact of change: This is very crucial to identify the change and impact this could have on existing product/feature. Documenting the impacting features, all the existing modules it interact is useful. A low level design is always preferred
2. Writing unit tests: Whatever you write, write with TDD (Test Driven Development) approach. This really help you write clean code and could eliminate possible risks.
3. Writing integration tests: There will be existing integration test framework, If not implement one. Write integration tests for existing and new features thoroughly and test it.
4. Using control switch: Preparing for worst. Let’s say if your deployment pass all the UT, integration tests, UAT etc. but hit some corner case in production which could impact key customers. It is always good to control these feature using some remote configuration or switch. This will enable you to disable the feature remotely without deploying any code set. In case of any failures, you can easily disable and debug without impacting wider customer base.
5. Dev and Beta Testing: Again, by dev testing and beta testing you could eliminate most of the possible bugs. Identify new beta customers (If it doesn’t exist) and provide them the feature to test.
6. UAT/BraveHeart users: Before deploying your change to wider audience, use the existing UAT/BraveHeart users or identify one. Ask them to use the feature and report any bug.
7. Alarms and OE (Operational Excellence): Make sure you have all the key alarms and operations in place which will let you know on priority in case of any failures.
8. Final rollout: Once all the above phases are completed, The confidence in the product will be high and can be rolled out to wider audience.

You might have noticed, I haven’t mentioned QA in any of the steps. While working with many companies, I have experienced in most of the teams there are no QA. If you’ve QA then it is always better to review the test plan and test strategy with them before development. This will help you in guarding one more level to avoid any issue. But if your team don’t have one, then it’s better to do thoroughly dev, beta, unit, integration testing.

Feel free to comment any more information that you’ve observed/followed.

You can connect with me on Linkedin and Medium