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