# Product workflow How to be a production ready team

Summary

- #### Git workflow - #### Semantic versioning - #### Commit semantic - #### In practice

Git workflow

#### develop and master * Master branch is the release history. Every commit is tagged. * Develop branch is the integration branch of features.

#### develop and master 

#### feature branch * feature branch should be created from develop * feature branch should be merged into develop * feature branch MUST not interact with master * feature branch should be named feature/ID-FEATURE Example: feature/12-my-feature

#### feature branch 

#### bugfix branch A bugfix is the correction of a bug present in develop and not in master * bugfix branch should be created from develop * bugfix branch should be merged into develop * bugfix branch MUST not interact with master * bugfix branch should be named bugfix/ID-BUG Example: bugfix/13-my-bugfix

#### release branch - release branch should not accept new features once created - release branch MUST be merged into master - release branch MUST be merged into develop - release branch branch should be named release/VERSION Example: release/1.0.1

#### release branch 

#### hotfix branch A hotfix is the correction of a bug present in master - hotfix branch should be created from master - hotfix branch MUST be merged into master - hotfix branch MUST be merged into develop - hotfix branch should be named hotfix/ID-BUG Example: hotfix/14-my-hotfix

#### Synthesis 

Semantic versioning

#### [Semver](https://semver.org/) It is a convention that describes how product/package versioning should be done * 1.0.0 => 1.0.1 : patch version (only fixes) * 1.0.1 => 1.1.0 : minor version (fixes and features) * 1.1.0 => 2.0.0 : major version (breaking changes)

#### Breaking changes What is a breaking change ? > A change in one part of a software system that potentially causes other components to fail Examples - changes in injection data API - changes in generated API contract - non upgradable changes in database - changes in app removing a feature

Conventional commits

It is a [convention](https://www.conventionalcommits.org) that describes some rules for writing commit ``` <type>[optional scope]: <description> [optional body] [optional footer] ``` Example : Commit with body and issue link in footer ``` fix: minor typos in code see the issue for details on the typos fixed fixes issue #12 ```

##### type * feat, fix : tracked and used for changelogs * chore, docs, style, refactor, perf, test : can be used, not tracked ##### scope The scope is the perimeter of the commit * -engine => worker, engine, docs, dqapi... * -api => api, consumer,...

#### Examples Simple commit ``` docs: correct spelling of CHANGELOG ``` Simple commit, with scope ``` feat(lang): added polish language ``` <!-- Commit with body and issue link in footer ``` fix: minor typos in code see the issue for details on the typos fixed fixes issue #12 ``` --> Commit with breaking changes ``` feat: allow provided config object to extend other configs BREAKING CHANGE: `extends` key in config file is now used for extending other config files ```

#### Why * Consistency * Readability * Complementary with [Semantic versioning](https://semver.org/) * Allows automatic generation of changelogs * Allows easier writing of upgrade documentation


In practice

#### Branches - Respect branch naming - Branch across multiple repos for a same feature must have the same name, and be linked to the same issue - One branch = One feature OR fix - While doing a feature, if I see a bug/codestyle unrelated, I must do it on another branch

#### Merge request - Merge request will be fast-forwarded, and can be squashed - Branch to merge, if not squashed, MUST have clean commit (`git rebase -i`) - Merge request must have 2 reviewers - Reviewer must enforce several things - Code style (no copy-paste, readability, no useless variables, or assignement...) - Feature (content, limit case handling, unit test, ...) - Linting (branch naming + commit style)

#### Automation - Git hooks will enforce these behaviours, both for learning and consistency purposes - locally - on CI - Release task will be automated - One task for multiple repositories - Separated and aggregated changelog - Gitlab release

#### Example : Add ensembling to monitor (1/3) - Create feature branch (linked to issue if possible) - `git fetch --prune` - `git checkout -b feature/42-add-ensembling-monitor origin/develop` - `git push --set-upstream origin feature/42-add-ensembling-monitor` - Create Merge Request in WIP (Work In Progess) with title `feat(monitor): adding ensembling (fixes #42)`

#### Example : Add ensembling to monitor (2/3) - Do some work - `git commit -m "feat(monitor): adding ensembling"` - `git commit -m "refactor(monitor): cleaning up code"` - `git push` - Rebase regularly on `develop` - `git fetch --prune` - `git rebase origin/develop` - `git push --force-with-lease`

#### Example : Add ensembling to monitor (3/3) - Ask for review when ready and remove WIP - Two options - Squash commits using option in MR options (commit message will be MR title) - Clean up your commits and do a fast-forward merge - `git rebase -i HEAD~5` ou `git rebase -i origin/develop` - `git push --force-with-lease`

#### Example : Hotfix queue name (breaking training) Same as feature, except - Branch must be checkout from `master` - Two MR must be created, one for `develop`, one for `master` - Branch must be named `hotfix/43-fixing-queue-name` - MR title should be `fix(engine): fixing queue names (fixes #43)` - Commit type should be fix `fix(engine): restoring old queue names`

Questions ?

### Sources - [Atlassian Git Tutorials](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) - [Conventional Commits](https://www.conventionalcommits.org) - [SemVer](https://semver.org/)

Thank you for your attention !