aspnetde/collaboration.md

## collaboration.md

      
    Raw
  

              collaboration.md
            
          
    Constraints:

Production = Google Play + Apple AppStore.
AppStore requires a manual review by Apple which can last between a couple of hours and a couple of days. It is not guaranteed to succeed, releases can be rejected.
It is not possible to put multiple releases in a queue – it is only possible to have one in review at Apple at a time.
There is no roll-back possible.
There will always be multiple release versions in use in parallel.

Goals:

Be able to set up and deploy hotfix releases at no time.
Build (integrate) every branch all the time, automatically.
Have code reviewed before it lands in "trunk".
Be able to install and test all versions of all branches of the app at any time on any device.

Process:

We use SemVer for version numbers.
Branches look like this:

2.0.0/trunk
2.0.0/feature/ticketid-description
2.0.0/bug/ticketid-description
1.9.1/trunk
1.9.1/bug/ticketid-description


Here 2.0.0 would be a regularily planned release, 1.9.1 would be a hotfix release for the last planned release that is already in production.
Features/bugs are either small enough to be done in 0-2 days, or are split up in sub-tasks by developers if they are more complex.
After a task is done, a PR is opened.
Reviewers, which are devs, check the code and do a functional test (they install and execute the app, testing the feature/bugfix).
Every PR is being reviewed asap, usually on the same day.
When everything is OK, the PR is merged into the trunk of the target version.
When a complex feature is split up into multiple sub-tasks, we usually put that behind a feature toggle which we will only remove after the full feature has been completed. Often, QA and PM will also only want to see and test the whole feature, so the toggle stays disabled until dev is finished.
Now QA and PM (literally the customer) do their final examination and either reject or accept the change.
At the end of a cycle, the trunk is being shipped to production, a Git tag is being created for the last commit, and the branch is being deleted.
Let's say 2.0.0 is now the latest production release:

We now create 2.1.0/trunk based on that and continue to work here.
When a criticial bug in production appears, we create 2.0.1/trunk based on 2.0.0, not 2.1.0.


Results:

We build and ship internally (to AppCenter) all the time, for every single branch.
Planned releases ship roughly once a month to Google and Apple.
Hotfix releases can be shipped within an hour or so, when necessary.
Every change is reviewed, which happens quite quickly.
Branches rarely live longer than a couple of hours to 1-2 days.
Merge conflicts happen, but they are very rare in our setup.
Downside: Manual code reviews require a second person to be available. This sometimes is a bottleneck during vaction time, where branches and PRs might pile up.

Disclaimer:
This is not the one single source of truth, it is what works best for us as a distributed team that works at different places, at different times. We also use different models for other project and team setups, e.g. at the moment full trunk-based development without formal code reviews, as people mostly work in pairs on the code which is not in production yet.