Release process and git strategies draft
========================================

## Context

### Given a Product Roadmap

v3.0 Due date 31-04-2020
 feat: full MOD4 support
 feat: apply different theme for Cupra vehicles

v2.1 Due date 29-02-2020
 fix: correct MOD3 wrong chart for fuel range
 fix: allow to transfer ownership of MOD3 vehicles

v2.0 Due date 31-01-2020
 feat(*): MOD3 support
 fix(analytics): update analytics config
 fix(speed alerts): show proper error message on failing activation

### Given a CI/CD approach

We have the following live environments:

+ live: production environment (to be launched on week 10 2020)
+ users: real users
+ desired to be stable as a rock
+ e2e tests executed before deploy
+ Stress tests executed before deploy
+ Performance tests executed before deploy
+ approval: staging environment (https://approval-11.aws.my.seat/portal) CAN WE REMOVE THE 11 from the domain?
+ users: QA team, alpha users, SEAT managers
+ desired to be as stable as possible
+ e2e tests executed before deploy
+ Unit tests executed before deploy
+ develop: development environment (https://develop.aws.my.seat/portal/)
+ users: developers, eventually a Product owner to clarify an spec NOT TO REPORT A BUG
+ can be unstable as developers use it for integrating features
+ e2e tests executed before deploy?
+ Unit tests executed before deploy

## Proposal

## Development process

### git strategy: Standard git flow

#### Branching model

**hotfixes** (bugs found in production stages)
_TBD accept change requests and chores here?_

- current live version
- checkout from master
- PR to master (squashed) by "merge strategy ff"
- backport to develop by "merge strategy no-ff"

**features/bugfixes/chores** (bugs found in approval/develop stages)

- future version
- checkout from develop
- PR to develop (squashed) by "merge strategy ff"

#### Promote develop to master
- test particular develop commit in a stage
- tag commit & version (ie package.json, pom.xml)
- merge develop to master

### Promote release/x.x to master
- create release/x.x
- polish works
- tag commit & version (ie package.json, pom.xml)
- merge release/x.x to master
- merge release/x.x to develop
- remove release/x.x

### CD release process WIP

+ production: manual deploy, based on a tag and master branch
+ approval: automated deploy, based on a tag and develop branch
+ develop: automated deploy, based on (last?) commit and develop branch(!)

Example deploy bamboo deploy job based on tag

# pull latest master
git pull origin master
# checkout to latest tag in master
git ckeckout $(git describe --tags)
# build based on tag
create docker image (involves build.sh/test)
deploy image

The latest commit of master is not deployed if not tagged

**Note WIP**
We encourage production deploys to be "manual". Even if fully automated needed to be triggered
by some human with some button rather than just git pushes/merges/etc

### CI test process WIP

+ Unit tests
+ Integration tests (do we have them?)
+ e2e tests (Cypress + Sukti's)

### TODO team actions WIP

+ Delete deprecated branches
+ Create documentation
+ Define responsibles of releases
+ responsible of merge from develop to master
+ responsible of merge from master to develop (backport/automatic?)
+ If release branch
+ responsible of merge release-x.x to master
+ responsible of merge release-x.x to develop (backport/automatic?)