For product development teams, there are a set of useful tips which can be treated as a checklist to follow, which will help to release a product successfully and effortlessly. Preparation is key in doing so; being ready for mishaps, and having means of communication in place which will help ensure transparency throughout the release activities.
Step 1: Release planning
Releasing a new product, or a new version of an existing product, needs to involve numerous people with different skillsets who will then be able to address all steps required for the release.
Planned release activities should be captured in one place and communicated with all those involved, ensuring each activity has an owner and the progress is tracked on a regular basis.
On the day of a release, a good idea is to have a dedicated line for ad-hoc communications that helps things run smoothly, taking care of issues as and when they crop up. The team should arrange checkpoints, too, to check the agreed timelines are being met.
Step 2: Setting criteria for production
Release criteria can help the team to make informed decisions about how to release a high-quality software. The criteria may vary based on the solution, depending on the details of such. The criteria that must be considered are:
— Code Coverage target by unit-tests should be met.
— Pass rate for release candidate in terms of manual and automated tests should be set and followed
— No blockers and high priority issues
— No issues preventing main user flow execution
— All known issues are tracked, reviewed by PO and prioritized
The solution should meet the security standards agreed, security rating should be monitored
Ensure the application is functioning according to the required performance level based on Production environment capacity
User acceptance testing is performed against release candidate and results are approved as satisfactory for going live
Step 3: Communication plan
Communication is a crucial element for the successful release deployment, so it’s imperative that the relevant level of communications is established within all involved parties.
Firstly, the release date and time should be set up in advance and agreed by authorised members of business, before being communicated to relevant people. Following this, the upcoming release and planned periods of downtime are scheduled.
To coincide with this, release documents will include information about the release: a brief overview, how to operate the new features, and a list of the known inconsistencies. Depending on the product changes, you may need to arrange intense training sessions to get everyone up to speed.
Step 4: Confirm environment readiness
Before we get the release signed-off, we must ensure the production environment is properly set up and all components are functioning correctly. However, production environment readiness is not just about configuration and infrastructure, this term is much vaster than you may consider.
To start with, CI-CD pipelines must be configured properly, in line with the selected delivery approach.
Secondly, there must be a backup process in place, so data can be restored and recovered quickly in the rare case it is lost.
Additionally, successful product release isn’t just about successful product deployment, but ensuring the product is functioning properly. For this purpose, monitoring strategy is essential in ensuring the product is functioning as it should be. This should include:
— Monitoring metrics definition
— Approach around logs tracking and aggregation
— Setting up alerting rules, consumers, priorities & threshold
As the value of the cloud is being recognised at an increasing rate, it’s easy for costs to spin out of control due to unnecessary cloud resources left running, as well as the poor alignment of the different types of cloud services which can be used, and the workloads these cause. Consequently, a cost management plan should be in place when preparing for the release of a product. This plan should continuously be reviewed and executed whilst the project is ongoing, to help ensure optimization, maximizing ROI for the client.
Step 5: Product maintenance & support.
Once the product has been launched to the end user, it’s important to have a well-defined and efficient model for product maintenance and support.
There are two different situations which may arise:
1. Something has suddenly gone wrong and the service is no longer working (or no longer working at the acceptable level). This is caused by infrastructure issues and should be managed by the operations team, who maintain the application infrastructure.
2. A customer observes an issue while using the product. To resolve this, the product support team will need to be involved.
Regardless of the issue a clear approach for live incidents management and SLA agreement must be defined:
— Levels of support available throughout the project: user support (L1), technical support (L2), software engineers (L3)
— Roles & responsibilities of each team member
— How incidents should be managed
— How to prioritise incidents and how they should be resolved
— Support time
Step 6: Testing in pre-production and production
One important criterion for success is testing — the product should be well tested before and while being released. You need to make sure that an appropriate & optimal test approach is built and followed in terms of manual and automated tests.
In addition to functional, regression and user acceptance testing security and performance testing should be done at the appropriate level based on the product purpose. The and the safest approach is to run them on pre-production environment if it’s similar to production one to avoid affecting real data.
Deployment to production should be followed by testing at least of the main end-to-end user flows and even deeper testing. The production testing depth depends on many factors:
Most of all testing either manual or automated can be done on pre-production environment if it’s a production mimic and has the same capacity and similar configuration.
If pre-production differs from production and it’s possible in the given circumstances, the majority of either manual or automated tests including performance and security ones could be executed on production within a regression testing stage before the application is tied to the real user data and product becomes available for end-users.
Regardless of any scenarios described above you must agree the approach, to conduct the minimal required testing after deployment on Production. It’s better to emulate behavior in terms of all main user flows, by conducting end-to-end tests. It allows to get a quick confirmation that all product modules and application components are functioning as expected from technical and business point of view.
Step 7: Rollback process and hot-fix workflows are defined and established
If something doesn’t go to plan when releasing a new product, we must either revert to the previous working version or provide an immediate ‘hot fix’ to resolve the issue.
When the decision is taken to rollback you need to revert the change and go back to running the previous version of the product. To make this process simple, quick and safe rollback strategy must be implemented, tested and understood. There should also be ‘rollback strategy’ documents, which entail the steps for running the process, what to check, and what to do in situations where problems arise.
In those scenarios we are requested to roll out a hot fix as quickly as possible the team should follow the process established:
— Clear identification of issue priority & authority
— Clear and documented processes
— Sufficient branch strategy
— Relevant level of testing including automated tests and manual sanity checks
Step 8: Deployment plan
Similar to preparing for a release, it’s useful to have a checklist to follow during the release. This provides a real-time picture of the system, outlining when each stage of production should have been completed. It can consist of some logical sub-sections and include the following information:
— Step-by-step description to specify exactly what needs to be done
— An owner who is responsible for the supervision of each step
— Outlines of time scales, if required, to map each step on the deployment timeline
— Status to show whether the action has been already done
Checklists also allow deployment history to be tracked, to find out if any requirements have missed.
Step 9: Release retrospective
Once the release is live, it should then be reviewed to assess its success, and what changes could be made to further the success, in time for the next release.
This session should have the same outline as with the sprint retrospectives which are run throughout the entirety of the release, with a focus on the bigger picture. An expanded list of participants should be invited to join, as people from different expertise has involved into release activities and may provide their view on the release process.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.