---
# System prepended metadata

title: Release process and git strategies draft

---

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?)
