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](mailto: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](https://github.com/FiTRSkills/ForkInTheCode/wiki/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](https://github.com/FiTRSkills/ForkInTheCode/wiki/Model-Tier-Documentation)
and
[Database Migration](https://github.com/FiTRSkills/ForkInTheCode/wiki/Database-Migration-Plan)
for more details.