Risk Mitigation

This page provides information on how to set up source control to manage our CI and how you might be able to use it for additional CI or CD in future iterations.

• Author: Alex Wilkes <adw4236@rit.edu>

Risks Encountered

There are several risks that we encountered during our project, they are listed here in an attempt to warn future teams from encountering these risks as well.

Failing Azure Deployment

There were several times when we needed to rely on our deployment succeeding so that we could have it running when we needed to do our sprint demo. There were at least two instances where we could not get it running in time and even more where we got it running even just minutes before the meeting started.

Resolution: We needed to kick off the deployment early and have someone ready to watch it through to the end. The early deployment failures were caused by our application being too large for the free tier and had to upgrade to the DEV/QA tier and start using the $100 free student credit. Every so often we still get a deployment failure, but most of the time just re-deploying it fixes the issue.

Timezone Confusion

Early on, one of our team members was located in a different timezone than the rest of us. This caused a lot of stress about when exactly deadlines were.

Resolution: Instead of having hard time deadlines, our deadlines would be made when the last person goes to sleep. This would allow team members to work on their own schedule and only worry about a date.

Github Paywalls

There was a period during our project when we tried to move our personal GitHub repository over to an organization. This however caused us to lose access to some of the free features in git including the ability to have a wiki, add multiple members to issues or PRs, etc.

Resolution: We temporarily moved our repository back to a personal one. Our sponsor has a github account for the organization, so maybe it would be best to just keep the repository under that account as a personal one until the project is up and running. Luckily GitHub makes it very easy to transfer repositories.

Azure billing

Azure for students provides $100 in credit. This should be more than enough for one student to host the application for two semesters, however we were being billed a much higher value which led us to burn through two different student's credits before the end of the first semester. This was due to database configurations and more details are outlined in Azure Cloud Setup.

Resolution: We had to contact microsoft over break and get a deeper explanation of how the azure configurations worked. We understood how the pricing worked, but we did not have the configurations we expected to due to how we were using mongoose. Again, see the Azure Cloud Setup page for mitigation.

Requirements clarification

Near the end of the first semester we realized that our vision of the application differed from our sponsors vision. This caused us to have to completely re-scramble the schedule for the second semester. Ultimately this wasn't a big hit to our productivity, but it was a close call, and we wanted to avoid any worse outcomes.

Mitigation: By doing two-week sprints, we were able to get our sponsors feedback on issues at regular intervals. By outlining what we would work on for the course of the projects schedule, our sponsor could see what we would be working on and catch any issues in prioritization.

Resolution: We were able to completely re-do the schedule for the second semester without a big hit to our productivity, but ultimately we had to re-negotiate what our team would be able to accomplish by the end of the semester.

API Definition

A lack of communication within our team caused us to have several sprints where we needed to fix several last minute integration issues. This was because we did not have well-defined specs that everyone was working off of. Assuming we were all on the same page was a big mistake.

Resolution: We created a concrete process for requirement gathering that started with our sponsor and ended with us having an API spec we could all work off of.

Last minute code reviews

During the second semester, our natural procrastination led us to having many last minute code reviews and even scrambles to fix bugs right before our sprint deadline. This caused a lot of unneeded stress to our team.

Resolution: We looked at everyone's schedule and decided to do a code freeze two days before the end of the sprint providing plenty of time to do code reviews and fix feedback. This was a hard deadline, and we enforced the fact that if you missed it, your code would not be shown in the demo.

Risks Mitigated

These are risks that we did not necessarily encounter, but have done our best to mitigate or at least make easier for a team who may encounter them.

Feature / Scope creep

We were very worried that our conversations with the sponsor would lead to lots of new ideas and suggestions for the application. This did end up happening many times but we were able to mitigate it very well.

Mitigation: Whenever a new feature was discussed, we would write it down and discuss it as a team later on. We would make it clear that it was likely not something we could accomplish at first, and it would be a pleasant surprise if we were able to get it done.

Source Control Swap

We are very concerned about the portability of this application and as such we wanted to ensure that the code could easily be moved to many different systems.

Mitigation: Ensure our CI pipeline is well documented and nothing we have specifically relies on github without an easy way to transfer it to another service.

Cloud Platform Swap

We are very concerned about the portability of this application and as such we wanted to ensure that the code could easily be moved to many different cloud platforms.

Mitigation: Avoid dependencies on cloud specific services such as AWS Lambdas and instead leave those as enhancements that can be made when the application is fully usable.

Database Swap

Not only is this again the same portability argument as above, but we also wanted to ensure the database could be moved to SQL if needed.

Mitigation: We have encapsulated the model tier and if any change to a database is needed, that would be the only tier that would need to be modified. We also ensure our models follow a strict schema so that it could be converted to a relational database as well.

NOTE: We have not fully realized this mitigation, see Model Tier Documentation and Database Migration for more details.