Application/Feature Release Planning Efficiently

Releasing a whole new application or a major feature is crucial to customers. They both have the potential to go sideways and can impact customers negatively. In order to properly deploy a change for a 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 into two categories:

1. Releasing a new application for the first time. 

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 features. 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 a controlled environment. With the help of product or other stakeholders, you can identify a certain set of end customers and provide them early access to your product. They will use the product and raise any bugs they encounter. This will reduce the impact radius and ensure the product is thoroughly tested from the 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 the 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 a 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 a wider audience.

All the above steps 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 mechanisms. There should be a clear rollback, SLA (Service Level Agreement), and issue addresal mechanism in place. This will help your team to quickly deploy a fix.

Release Planning for New Major Feature

This is the 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 the feature, the type of the product, and the user base. The intensity of going wrong in this case is high as this can impact existing customer and could bring a 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’ a 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 products/features. Documenting the impacting features of 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 helps you write clean code and could eliminate possible risks.

3. Writing integration tests: There will be an existing integration test framework; if not, implement one. Write integration tests for existing and new features thoroughly and test it.

4. Using the control switch: Preparing for the worst. Let’s say if your deployment passes all the UT, integration tests, UAT, etc., but hits some corner cases in production, which could impact key customers. It is always good to control these features 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 a 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 a wider audience, use the existing UAT/BraveHeart users or identify one. Ask them to use the feature and report any bugs.

7. Alarms and OE (Operational Excellence): Make sure you have all the key alarms and operations in place, which will let you know the 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 a 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 issues. But if your team doesn’t have one, then it’s better to do thorough dev, beta, unit, and integration testing.