## ADR #0007: The Canary release deployment strategy should be used for SmartHut

1. **What did you decide?**

    The Canary release deployment strategy shall be the deployment strategy used 
    to release the SmartHut system to users and hobbyists.

2. **What was the context for your decision?**

    The chosen deployment strategy shall be effective at maximizing user satisfaction
    with the SmartHut project, while exploiting the open-source and open-contribution
    nature of the project, which will make a "move fast - break things" approach desirable
    to power users and contributors for the sake of new features and improvements.

    This environment is thus ripe of users which are willing to trade some instability for 
    getting to be at the bleeding edge, or simply act as volunteering user acceptance /
    quality asssurance testers. The deployment strategy shall exploit this fact as an 
    economical way to give the _green light_ to widespread adoption of each release. 

3. **What is the problem you are trying to solve?**

    Which is the most suitable and cost-effective deployment strategy for an hobbyist-oriented project?

4. **Which alternative options did you consider?**

   - Big Bang <!-- No need to be able to undo the release. -->
   - Blue/Green <!-- All client at the same time go forward and can also go back (if necessary) -->
   - Shadow <!-- Release undocumented features. -->
   - Pilot <!-- Selected clients would like to evaluate the new release. -->
   - Gradual Phase-in <!-- The new version is released to an initially small but growing subset of users. The old version is retired after all old users have switched to the new one. Depending on the user population size and the time window, an arbitrary number of versions can be in use at the same time. -->
   - Canary <!-- A gradual phase-in release with very few initial users who do not mind dealing with failures -->
   - A/B testing <!-- Different clients can use different versions so we can learn which works best. -->

5. **Which one did you choose?**

    - Canary

6. **What is the main reason for that?**

    Given the presence of users who are willing to play the role of quality assurance, Gradual phase-in 
    releases with very few initial users who do not mind dealing with failures seem appropriate as these
    users are willing to tolerate failures.   

    Pros:
    - Integrates well with a cost-effective UAT strategy
    - Appropriate for an open-contribution environment
    - Allows to "move fast and break things".

    Cons:
    - A degreee of instability is to be expected in new releases
    - The quality of widespread releases depends on the quality of the quality assurance performed by volunteers.