Development Workflow
"The only way to go fast is to go well."
Imagine a life without a standard process.
Why use a workflow?
- To improve collaboration and avoid chaos.
- To maintain the quality of our software.
- Improve/ease automation for better quality of life.
Focus of this talk
- Gitflow Workflow
- Semantic Versioning
Gitflow Workflow
How it works?
-
Two main branches,"master" and "develop".
-
The "master" branch will reflect our production environment.
- Each merge to master has a "tag".
-
The "develop" branch will reflect our edge environment.
Feature Branches
-
Each feature should have it's own branch.
-
Branch out of "develop" instead of "master".
-
When a feature is complete merge back to "develop".
Release Branches
-
Branch out from "develop".
-
New features are not allowed, only bug fixes or release oriented tasks.
-
Once done merge both to "master" and "develop".
-
Don't forget to tag "master" once merged.
-
Hotfix Branches
- Branch out from "master".
-
Just like a release branch, merge to "master" and "develop" once done.
- Also tag "master" once merged.
Best Practice
- Unit Testing
-
Code Review for each pull/merge request.
- At least one person already approved before merging.
- When a build fails, everybody stops working to fix the build.
- Squashing Commits (?)
- Use present tense on commit messages.
Cons
- A little complex, and managing two main long-lived branches is tedious.
- Branching out from a wrong base branch is easy and may pose problems.
- Lot's of merge commits happening due to different conventions, and may lead to harder to read history.
Alternatives
Semantic Versioning
What is SemVer?
-
Versioning standard for our releases.
-
Major.Minor.Patch
- Major - for API breaking changes
- Minor - for backwards compatible changes
- Patch - for bug-fixes or hot fixes
For Discussion
- Release Candidate management and automation
- We manage git tags manually. This is more on how we tag our Docker images with our CI.
Best Practice
- Tag every merge to our "master" branch.
- Tags from our repo should also reflect tags from our Docker builds.
- Create a CHANGELOG per release/version.
Cons
- If your software is not being depended on or doesn't really break backwards-compatibility (e.g. Linux Kernel), your "Minor" and "Patch" are the only ones being bumped.
Alternatives
Questions?
Thank you!
References & Sources
Development Workflow
By Jezeniel Zapanta
Development Workflow
- 310