After several months of work and the involvement of the entire team, the time has come to plan and execute the release . For many, this may be an exciting moment, but from a technical perspective, it is often accompanied by stress . So how can the entire process be planned so that next time, when asked, 'How's the release going?' you can respond, ' Don't worry; it's real ease .'
In ideal circumstances, deploying an application for the first time can be relatively stress-free. We start with a 'clean slate' - we don’t have to worry about users who might encounter a bug because there simply aren't any yet. Of course, such a release still needs to be planned, but the team has significantly more room to make mistakes or test something in the target environment.
In our scenario, the situation was more complicated. For a long time, we have been working together on an existing platform for teachers in Germany to facilitate collaboration among them to best support students' development. The application was growing very intensively, continuously delivering new solutions and responding efficiently to the needs of its users. It turned out that this was not the end. The application fulfilled its purpose and facilitated teachers' work but needed more student elements. The next step was creating a smaller platform for students to observe their progress, track their goals, and earn rewards. At this point, we decided to expand and split the development team slightly to get to work. Team A was to continue the daily work on the teacher platform, while Team B was to start implementing the new student platform.
Thus, as we entered the final phase and began planning the release, we found ourselves in a rather unusual and difficult situation. Here are our conclusions about the steps that need to be taken to maximise the chances of a successful release.
Organisational Planning Phase
Release Date
First and foremost, the planned release date must be established. Sometimes, this date is dictated by the client or managers, but usually, it will be a time frame rather than a specific day. As the project nears completion, the team should be able to pinpoint a particular day for the official release. At this point, adding at least one extra day to the planned date is advisable to provide a buffer for any potential complications.
In our case, setting this date was more complex because while Team B was finishing the implementation of the new platform, Team A was continuously working on new features and conducting their releases. Therefore, we had to gather both teams and jointly decide on a moment that would allow Team A to complete and test the current phase of their work while also allowing Team B to deploy their module without blocking either side.
Responsible Persons
If you have yet to assign individuals for specific tasks permanently, this is also a good time to designate responsible persons. Our situation required significantly more coordination and inter-team communication, so outlining specific tasks and assigning individuals to them was crucial for the process to run as smoothly as possible. However, creating a task list will be helpful even in less complicated scenarios.
Remember that projects often include less experienced members. An organisation like this will clarify them and offer valuable learning opportunities.
Attention to Details
It's worth remembering to write down even the most minor things that come to mind because as the planned release date approaches, more things will demand our attention, causing us to forget details that seemed evident during the planning stage. Keep in mind the detailed documentation related to the deployment process, such as:
-
Creating or updating the README file,
-
Updating user documentation: FAQs, release notes, instructions, and guides,
-
Ensuring all licenses, cookies, and legal information are up to date
Technical To-Do:
Before initiating the deployment of your application, it's crucial to address several technical tasks to ensure a smooth and successful release. These steps help minimise the risk of disruptions and ensure your application functions as expected in the production environment. Here’s a comprehensive checklist of technical tasks to complete:
Data Backup
Data backup is a critical step in the deployment process, as it ensures that you have a reliable way to recover your application and its associated data in case something goes wrong.
This is especially important when deploying an application that automatically performs database schema migrations at the time of deployment.
Ensuring All Dependencies Are in Place
Our application may be another piece of the puzzle in more complex systems that are dependent on other services. These may sometimes include a database, a queue system, or a data encryption service. We must ensure that all configuration variables are correctly set and that these systems can seamlessly integrate with our application.
Create a Staging Environment
It's crucial to thoroughly test the entire configuration in an environment that closely mirrors our production environment. This allows us to catch critical errors during internal testing stages.
Deploy to Production Early
When creating a new system, we can sometimes deploy our application to production ahead of the official release date. This was precisely the case for us. We deployed the new services a week earlier and tested their full functionality. Meanwhile, the integration parts in existing services were hidden using a feature flag. Nothing changed from the users' perspective, but this allowed us to begin testing in production by enabling the feature flag for specific users. Thus, the final release was simply disabling the feature flag for everyone.
Conduct Alpha and Beta Testing
Alpha tests are internal tests, while beta tests are conducted externally with a limited group of users. This approach not only helps us catch bugs but also allows us to gauge what our target users like or dislike. It also enables us to identify logical errors and verify our assumptions.
Monitoring
It is very important to maintain the health and performance of your application. Effective monitoring helps identify and address issues before they impact users or lead to significant downtime.
-
Set up tools to monitor the performance of the application and servers.
-
Establish alert thresholds to respond quickly to issues.
Contingency Plan
A contingency plan is a crucial component of your deployment strategy, designed to ensure that you can respond effectively to unexpected issues and minimise disruption if things don’t go as planned.
-
Prepare a plan to revert the deployment in case of critical issues.
-
Team on Stand-by: Ensure key personnel are available and ready to act in case of an emergency.
In our case, this was an essential part. We needed the best contingency plan as our release affected real users. Any issues that might have happened during the release needed to be easily reverted or at least quickly hidden.
Conclusion
Successfully planning and executing a release requires careful consideration and thorough preparation. By addressing both organisational and technical aspects, you can significantly reduce the risk of complications and ensure a smoother transition to production.
In our case, the complexity of deploying a new student platform alongside ongoing work on an existing teacher platform highlighted the importance of detailed planning. Establishing a clear release date, designating responsible individuals, and paying attention to every detail were crucial steps. Moreover, implementing data backup procedures, effective monitoring, and a comprehensive contingency plan were key to managing potential issues and ensuring a successful release.
Ultimately, a well-executed release meets project goals and sets the stage for future success. By learning from each release and refining your processes, you can continue to improve and achieve greater ease in future deployments. With the proper preparation and mindset, you’ll be well-equipped to handle the challenges of any release and turn potential stress into a seamless experience.