Releasing a new software application can be a challenging and rewarding experience for any development team. It involves many moving parts, from designing and developing the application to testing and deploying it. Despite all the hard work, the first release is always a learning experience for any team. It is a time to reflect on the development process, identify the areas that require improvement, and determine what worked well.
In this blog, I will share the learnings from our first release. I will discuss the challenges I faced during the development process, the testing and deployment phase, and what I learned from the experience. I will explore the tools and methodologies I used to develop and test our application, and what I would do differently in the future. Our aim is to provide insights and tips that can help other development teams to avoid common pitfalls and overcome the challenges of the first release.
From our first release, I learned that the development process is not just about building software, but it is also about learning, improving, and growing as a team. With that in mind, let's delve into our learnings and discover what worked well, what didn't, and how I improved for future releases.
1) Have a structured plan with step-by-step description:
- Get a Go or No Go flag from business: The first step is to ensure that the application is ready for release. This involves getting a Go or No Go decision from the business stakeholders. The stakeholders will decide if the application is meeting the required standards and whether it is ready for deployment.
Timelines: This step should ideally be completed a week before the scheduled release date to allow for any necessary adjustments.
Stakeholders/Owners: Business stakeholders, project manager, development team lead.
- Smoke test by QA team on release branches: The second step is to conduct a smoke test on the release branches to ensure that the application is functioning as expected. This involves running basic tests to check for any critical issues that might prevent the release.
Timelines: This step should ideally be completed two days before the scheduled release date.
Stakeholders/Owners: QA team lead, development team lead.
- DB cleanup: The third step involves cleaning up the database to ensure that it is free of any unwanted data. This step is necessary to optimize the performance of the application.
Timelines: This step should ideally be completed one day before the scheduled release date.
Stakeholders/Owners: DBA team lead, development team lead.
- DB deploy: The fourth step is to deploy the database changes that have been made during the development process. This step is essential to ensure that the application has access to the latest database schema.
Timelines: This step should ideally be completed on the same day as the DB cleanup.
Stakeholders/Owners: DBA team lead, development team lead.
- Deploy backend: The fifth step is to deploy the backend of the application. This involves installing the necessary components on the server to support the backend of the application.
Timelines: This step should ideally be completed on the same day as the DB deploy.
Stakeholders/Owners: Development team lead, server administrator.
- Deploy UI: The sixth step is to deploy the user interface (UI) of the application. This involves installing the necessary components on the server to support the frontend of the application.
Timelines: This step should ideally be completed on the same day as the backend deployment.
Stakeholders/Owners: Development team lead, server administrator.
- Smoke test after release on live project: The final step is to conduct a smoke test on the live project to ensure that the application is functioning correctly. This step involves running basic tests on the live server to check for any issues that might have been missed during the development process.
Timelines: This step should ideally be completed on the same day as the UI deployment.
Stakeholders/Owners: QA team lead, development team lead.
2) Prepare release branches for all repositories going live:
Create Release Branches: Create release branches for all the repositories that are going live. These branches should be created from the main development branch and should only contain the code changes that are going to be released
Code Cleanup: Before releasing the application, it is important to clean up the codebase. This involves removing any unnecessary comments, unused imports and variables, and any other code that is no longer being used.
Remove Sensitive Information: Any sensitive information that is hardcoded into the codebase, such as passwords or API keys, should be moved to environment files. This helps to protect the security of the application and prevent unauthorized access.
Review by Team Lead or Project Manager: Once the release branches are created, they should be reviewed by the team lead or project manager to ensure that all the necessary changes have been made and that the code is ready for release.
Timelines: These steps should ideally be completed a few days before the scheduled release date to allow for any necessary adjustments.
Stakeholders/Owners: Development team lead, project manager.
3) Have a detailed rollback plan (incase anything goes wrong):
Identify Potential Issues: Before the release, identify potential issues that may arise during the release process. This can include things like deployment failures, performance issues, or compatibility issues.
Determine Rollback Strategy: Once potential issues are identified, determine a strategy for rolling back the release. This can include rolling back to a previous version of the application, reverting code changes, or restoring data from a backup.
Create Rollback Plan: Create a detailed rollback plan that outlines the steps that need to be taken in the event that a rollback is required. This plan should include specific steps for each potential issue that may arise.
Take Proper Backups: Before the release, ensure that proper backups of all the relevant data and code are taken. This will make it easier to restore the application to a previous state if necessary.
Prepare Rollback Branches: Have rollback branches ready for all the repositories that are going live. These branches should be created from the latest release branch and should only contain the changes required for the rollback.
Timelines: These steps should be completed before the release and should be reviewed and updated regularly.
Stakeholders/Owners: Development team lead, project manager, server administrator.
4) Have code coverage well beyond the minimum mark to avoid low code coverage and thus deployment failure due to last minute changes:
Set Minimum Code Coverage Threshold: Define a minimum code coverage threshold for the application. This threshold should be set based on the complexity of the application, the criticality of the functionality, and the development team's experience.
Use Automated Testing Tools: Use automated testing tools to ensure that the application is well-tested and that there are no issues or bugs. Automated testing tools can help to identify bugs and ensure that the code coverage is high.
Use Unit Testing and Integration Testing: Use unit testing and integration testing to ensure that each function of the application is tested thoroughly. This helps to ensure that there are no issues with the code, and that any changes made to the code are thoroughly tested before deployment.
Perform Regular Code Reviews: Conduct regular code reviews to ensure that the code is well-written and adheres to best practices. This can help to identify potential issues or areas that require improvement.
Analyze Test Results: Analyze the results of the automated tests and review any failed tests to identify potential issues or bugs. This helps to ensure that any issues are identified and addressed before deployment.
Timelines: These steps should be completed throughout the development process to ensure that the code coverage is high and any last-minute changes are thoroughly tested.
Stakeholders/Owners: Development team lead, project manager, quality assurance team.
By following these steps, you can ensure that your application is well-tested, robust, and that any last-minute changes are thoroughly tested. This can help to avoid deployment failure and ensure that the application is running smoothly.
Top comments (0)