Release Goals Rationale
For our first release, the team decided that the best approach would be to fully form our user interface for the Frontend. We came to this conclusion after we realized that the document given to us by our shareholder was still somewhat volatile as after being given the initial document, there were a couple revisions made in the following weeks. Due to this, we made the decision to deal with what we knew would not change about the project, that being how to display the information provided to us. That being said, we created the documentation necessary for the project in the earlier iterations. Once completed with the documentation, the mockup for the UI Mockup was created. With this document finalized, we were able to delegate the UI component tasks among various team members.
We were successful in being able to create the UI components necessary for this project. All the components we created are dynamic, so when we create the backend endpoints all we need is to load the data in the frontend which won't create any unnecessary overhead. Our UI is a simple overlay over a world map. Having the application as one page where the user can access everything makes it much easier to navigate. It also puts focus on the important part of the application, that being the map itself. We are able to close these overlay tabs as well, as to not to pollute the user's screen with menus. These are some screenshots of the application as it stands for release 1 (Note the world map is being rendered using OpenLayers, it is not a static image):
We were also able to get most of our CI/CD pipeline functional. We have two workflows created, one for running tests/linting and another one for containerizing the project into an image that gets sent to Docker Hub. The CI/CD still does have some tweaks that we want to make such as adding code coverage for the backend and such, however seeing as we were not able to start on the backend before this release, this will be taken care of in the next iteration. We do still have static code analysis using SonarCloud which appears in every pull request, but we would like to use SonarQube in the future throughout the CI/CD cycle as it can provide in depth reports on what needs changing.
Ideally we wanted to start on our backend as well by the end of this iteration, however that wasn't feasible as it took our stakeholder until the week of release 1 before he was able to provide a valid data set. As we are dealing with data that contains a huge amount of parameters, we wanted to get an example before we started implementing any actual backend code to ensure when we start writing it, we have the final version of the data in hand. Had we implemented a version of it beforehand, then received the final data and had to go back and modify, it could create some confusion and overhead for the project. So as it stands, we have the boilerplate code setup and are ready to implement our backend endpoints starting in the next iteration.
For our second release, the team decided to focus on both the backend and frontend components of the project. Our goal was to establish a solid infrastructure for data handling and visualization. We realized that to provide a comprehensive wildfire visualization platform, it was essential to ensure our backend was capable of efficiently processing and serving large datasets.
We prioritized configuring a multi-environment deployment setup and addressing missing tests and refactoring tasks from previous iterations. This included adding endpoint modification prompts in settings, creating a load dataset button with a loading screen, and standardizing the frontend for consistent design. We also aimed to establish a connection with GeoServer and design the database schema for wildfire and geospatial data.
We focused on initializing the database and dockerizing the PostgreSQL instance. This involved creating data pullers and converters to handle STAC data, ensuring that we could efficiently process and store the data required for the platform. We also aimed to create endpoints to reset data and pull map data, which were crucial for the frontend to interact with the backend.
We continued working on backend component tasks and added a toggle control for filtering datasets by region. This was essential for enhancing the platform's usability and ensuring that users could easily navigate and filter the data based on their needs.
By the end of Release 2, we achieved significant progress in establishing a robust backend infrastructure and integrating it with the frontend. We created dynamic UI components that could easily interact with the backend endpoints, ensuring a seamless user experience. We also made strides in our CI/CD pipeline, containerizing the project and setting up workflows for testing and deployment.
For our third release, the team aimed to build on the foundation established in Release 2 by enhancing both the backend and frontend capabilities of the platform. Our focus was on improving data visualization, refining user interactions, and addressing any remaining technical debt.
We tackled several critical tasks, including ensuring that the factory reset functionality worked correctly, saving application settings, and updating configuration management. We also created a data converter for STAC data and added endpoints for filtered datasets. These tasks were essential for improving the platform's stability and ensuring that users could easily manage their data.
We addressed specific bugs and improved the user interface by ensuring that metadata containers stayed open after factory resets and that notification prompts were displayed correctly. These enhancements were crucial for providing a consistent and user-friendly experience.
We continued to refine the platform by removing mock and unused methods, displaying STAC items on the frontend map, and avoiding logging entire SQL queries. We also focused on refactoring the MapContext and adding wildfire synthetic controls and timelapse animations. These tasks aimed to enhance the platform's performance and provide users with a more immersive experience.
We made key improvements, including displaying dataset timestamps, enhancing dataset filtering, and running the application with a single command. We also focused on improving exception handling, adding missing translations, and integrating synthetic wildfire assets. These tasks were critical for ensuring the platform's reliability and usability.
In the final iteration, we considered using Spring Data instead of JDBC Template and created YAML contracts to generate DTOs. These tasks aimed at reducing technical debt and improving the maintainability of the codebase.
By the end of Release 3, we successfully enhanced the platform's capabilities, improved the user experience, and addressed technical debt. We focused on creating a stable and scalable platform that could handle large datasets and provide users with valuable insights into wildfire data.
